在Golang的编程规范中，const关键字用于定义常量，这类值在编译阶段就已经确定且不可修改。不少开发者在尝试对常量执行取地址操作时，会发现代码无法通过编译，这背后和Golang常量的设计逻辑以及内存管理机制密切相关。
Golang常量的基本特性
Golang的常量分为类型常量和无类型常量两种，它们的共同特点是值在编译期就确定，且整个生命周期内不可被修改。常量的定义不需要显式指定类型，编译器会根据上下文自动推导，比如下面的代码：
package main
import "fmt"
func main() {
const a = 10 // 无类型常量
const b int = 20 // 类型常量
fmt.Println(a, b)
}
常量的不可修改性是核心特性，一旦定义后，任何尝试修改常量值的操作都会直接触发编译错误。
尝试对常量取地址的报错情况
如果我们尝试对const定义的常量执行取地址操作，比如使用&运算符，代码会直接编译失败，示例如下：
package main
func main() {
const num = 100
// 下面这行代码会编译报错：cannot take the address of num
ptr := &num
}
这个报错直接说明了Golang不允许对常量取地址，背后的原因可以从常量的存储方式和内存分配规则来分析。
常量不能取地址的核心原因
1. 常量可能不存在实际内存地址
Golang的常量在编译阶段就会被直接替换为对应的值，尤其是无类型常量，很多时候会被直接嵌入到指令中，不会在内存中分配独立的存储空间。既然没有实际的内存分配，自然也就不存在可以被获取的地址。
比如我们定义const x = 5，在编译后的代码中，所有使用x的地方都会被直接替换成5这个字面量，不会为x单独开辟一块内存来存放，因此取地址操作没有对应的内存实体支撑。
2. 常量的不可修改性不需要地址支撑
变量的地址存在的意义之一是为了支持后续对变量值的修改，而常量本身是不可修改的，设计上就不需要通过地址来操作它的值。如果允许对常量取地址，就可能出现通过指针间接修改常量值的风险，这和常量的不可修改特性是冲突的。
3. 编译期常量的优化逻辑
Golang编译器会对常量做大量优化，比如常量折叠、常量传播等，这些优化都建立在常量没有独立内存地址的基础上。如果允许常量取地址，就会限制编译器的优化空间，影响程序的运行效率。
常量和变量的取地址对比
和常量不同，Golang的变量一定会在内存中分配空间，因此可以对变量正常取地址，两者的区别可以通过下面的表格清晰看到：
| 对比项 | 常量(const) | 变量(var) |
|---|---|---|
| 值确定时间 | 编译期 | 运行期（部分编译期可确定） |
| 内存分配 | 可能不分配独立内存 | 一定分配独立内存 |
| 是否可修改 | 不可修改 | 可修改 |
| 是否可取地址 | 不可以 | 可以 |
如果需要常量的地址该怎么办
如果实际开发中确实需要获取一个不可修改值的地址，可以先把常量的值赋给一个变量，再对变量取地址，示例如下：
package main
import "fmt"
func main() {
const num = 100
// 把常量值赋给变量
var tmp = num
// 对变量取地址
ptr := &tmp
fmt.Println(ptr) // 可以正常输出变量的地址
}
这种方式既保留了常量不可修改的特性，又能满足获取地址的需求，是日常开发中的常用解决方案。
总结
Golang的const常量不能取地址，本质是因为常量在编译期就可能不分配独立内存，且常量的不可修改特性不需要地址支撑，同时允许取地址会限制编译器的优化空间。理解这一特性可以帮助开发者更合理地使用常量，避免不必要的编译错误，也能更深入理解Golang的内存管理设计逻辑。