解读

国内面试中，这道题常被用来区分“只会用泛型”与“真正理解编译器行为”的候选人。
面试官想听你回答三点：

1. 泛型在 Go 里是怎么落地的（字典+单态化）
2. 内联决策发生在编译前端还是链接阶段
3. 跨包时函数体不可见导致内联预算无法估算，因而被保守放弃

答不到“字典”“单态化”“链接阶段可见性”这三个关键词，基本会被追问到哑口无言。

知识点

1. 单态化（Monomorphization）：编译器为每个实际使用的类型参数组合生成一份专门的机器码，称为“实例”。
2. 字典（Dict）：若实例化发生在包外，编译器在当前包只能生成一份“泛型形状”，真正的类型字典在链接期才补齐，因此函数体里出现字典访问，前端无法确定其副作用。
3. 内联预算：Go 的 SSA 前端做内联时，需要看到完整函数体并计算 cost；跨包场景下，导出信息只有签名，没有 SSA 中间码，预算无法计算。
4. 链接期可见性：即使使用 -l=4 强制内联，编译器在链接阶段再次看到函数体时，实例已经带字典调用，内联收益低且可能膨胀代码，遂放弃。
5. 国内工程规范：大型微服务普遍开 -l=2 或默认，跨包泛型代码几乎不进内联，因此热点路径的泛型函数建议放在同包内或手动提供 //go:noinline 反向标记，避免误判。

答案

Go 的泛型实现采用“单态化+字典”混合策略：

1. 在本包内使用时，编译器直接生成具体类型的实例，函数体对 SSA 前端完全可见，满足内联预算即可被内联。
2. 当泛型函数被跨包引用时，调用端只能看到泛型形状，真正的类型字典要在链接阶段才补齐；此时前端缺少完整 SSA，无法估算副作用与成本，内联预算计算失败。
3. 即使开到 -l=4，链接期再次看到函数体，实例代码已包含字典访问与接口转换，内联收益低且会放大二进制，编译器出于代码体积与性能平衡保守放弃。
   因此，跨包场景下泛型实例化后的代码默认不会被内联；若必须内联，需把泛型函数与调用方放在同一包，或使用代码生成规避。

拓展思考

1. 性能调优：在网关或中间件项目里，把高频泛型工具函数集中到 internal/xxx 同包内，可让编译器重新获得内联机会，CPU 利用率提升 5%～8%。
2. 二进制体积：强制内联泛型实例可能造成重复机器码爆炸，国内云原生镜像对大小敏感，建议用 go build -ldflags="-s -w" 配合 bloaty 检查，权衡内联与体积。
3. 向后兼容：Go 团队已在 1.22 实验“跨包中间码导出”，未来可能把 SSA 写进 .x 索引文件，让前端在跨包时也能算预算；落地后此限制会放松，面试时可主动提及，展示对语言演进的跟踪能力。