解读

面试官抛出此题，并非想听你背“官方还没做”，而是考察三点：

1. 对 Go 类型系统 的底层理解——const 属于 “无类型”或“基础类型” 的编译期常量，而泛型类型参数（T any）是 运行时才能实例化的“类型占位符”；
2. 对 Go 设计哲学 的认同——“少即是多”，不为了炫技而引入可能破坏可读性或编译速度的 feature；
3. 对 工程落地痛点 的体感——国内一线大厂（字节、阿里、腾讯）在 1.18-1.22 泛型灰度中，90% 的泛型代码集中在容器、算法、中间件，几乎未出现“const 泛型”刚需，说明需求优先级不高。

知识点

1. const 的 Go 语义：必须是 编译期可求值 的 基本类型（bool、string、整数、浮点、复数、nil），且 类型不可参数化；
2. 泛型实例化时机：编译器在 包级别 做 类型替换（monomorphization），而 const 在 更早的常量表达式求值阶段 就必须完成，两者时间轴冲突；
3. 类型集（type set）限制：即使允许 const T = 10，T 也可能是 float64、int、甚至用户自定义的 新类型 MyInt，常量值 10 的默认类型 int 无法隐式适配所有类型集，违背 Go 显式转换 原则；
4. 国内工程实践：在 Kubernetes、etcd、Docker 等云原生核心项目里，泛型主要用于 type-safe 的容器/函数，而 const 仍通过 code generation 或 go generate 解决，证明“无此 feature 也能交付”；

答案

“Go1.22 仍不允许 const 与泛型类型参数混用，根本原因是 编译期常量求值 与 泛型实例化 发生在 不同阶段，且 Go 的常量必须是 基本类型 并 立即确定类型。泛型类型参数 T 在编译期只是 占位符，无法为 const 提供 具体基础类型，因此编译器无法验证常量表达式。此外，Go 团队坚持 显式、简单、快速编译 的哲学，目前社区（包括国内大厂）的泛型使用场景尚未证明‘const 泛型’能带来 足够 ROI，所以优先级排在 性能优化、模块化、工具链 之后。”

拓展思考

1. 如果未来 Go 引入 “const 泛型”，必须解决 默认类型推导 与 类型集冲突 两大难题，可能走向 C++ 的 constexpr 或 Rust 的 const generic 的简化版，但 语法噪声 与 编译速度 是红线；
2. 国内面试常追问：“不用 const 泛型，你如何保证编译期常量与泛型算法联动？” 标准答案是：用 go generate 生成 类型专属常量文件，或把 常量作为函数参数 让编译器 内联优化；
3. 高阶场景：在 金融级支付网关 中，手续费精度常量 需要与 decimal 泛型算法 联动，目前通过 单测 + 代码审查 保证，若未来 Go 支持 const 泛型，可进一步 消除魔法数，但 Go 团队仍会以“显式优于隐式”权衡，不会照搬 C++ 模板元编程的复杂度。