解读

国内一线/二线公司在面试中抛出此题，并非单纯考察“能不能取地址”，而是想验证候选人对 Go 值语义与常量系统的理解深度。很多候选人会脱口而出“const 就是不能取地址”，但说不清底层原因，也无法给出工程级替代方案，导致印象分大打折扣。把“不可寻址”和“常量折叠”这两个关键点讲透，再给出零成本抽象的替代写法，才能拿到高分。

知识点

1. Go 的 const 属于编译期常量，在 AST 阶段就完成常量折叠，最终可能以立即数形式嵌入指令，运行时根本不存在内存对象，因此无地址可取。
2. 数组/切片字面量若直接赋给 const，会被视为**“非地址able 的纯值”**；编译器拒绝 & 操作，防止程序员误以为能拿到稳定内存。
3. **可寻址（addressable）**的 Go 规范定义：只有变量、切片/数组索引、指针解引用、组合字面值在变量基础上构建等场景才满足；const 不在其中。
4. 替代思路：用var 声明只读数组 + 封装只读接口，或者使用go:linkname把常量抽到头文件（云原生项目常用），既保证性能，又避免魔法数扩散。

答案

“const 数组/切片不可寻址”根本原因是 Go 的 const 体系是编译期常量，编译器在常量折叠阶段就把它们替换成立即数或内联值，运行时没有分配可稳定访问的内存，因此不满足 Go 规范中 addressable 的定义。既然对象不存在，自然无法对其取地址。

工程替代方案分三层：

1. 包级私有的 var 只读数组，外部通过只读接口访问：

   var _internal = [4]byte{0x20, 0x21, 0x22, 0x23}
   func MagicBytes() []byte { return _internal[:] }
   

   包外调用方拿到的切片底层数组只读，且零拷贝，性能与常量无异。
2. 若常量较大且跨仓库共享，维护一个codegen 脚本把数组生成到 zz_generated.go，配合 //go:embed 直接嵌入二进制，编译期锁定内容，运行时同样不可改。
3. 在 Kubernetes、Docker 等云原生代码库里，常见做法是把CRC 表或魔数放到 internal/constants 包，用 go:linkname 限制可见性，既避免复制，又符合**“常量不可改”**的语义。

拓展思考

1. 如果未来 Go 引入 “不可变类型”（immutable type），const 数组/切片可能变成真正的只读对象并支持寻址，届时需要重新评估逃逸分析与缓存友好性。
2. 在热路径中，把只读数组声明为 var 而非 func 内字面量，可让CPU 缓存复用同一块内存，避免每次函数调用重新初始化，提高高并发网关的吞吐。
3. 面试加分项：主动提到 go vet 会对“误用 & 取 const 地址”给出编译错误，并说明团队通过 CI 阶段加 -gcflags=-m 检查常量折叠情况，体现工程化思维。