Go中指针不能作为map键，因语言规范明确排除其可比较性；安全替代方案是使用唯一ID或uintptr配合reflect.ValueOf.Pointer()。
Go 中不能用指针做 map 的键，map[&T]V 直接报错
Go 编译器明确禁止将指针类型作为 map 的键——不是运行时报错，是编译不过。invalid map key type *T。这是因为 map 的键必须可比较（comparable），而指针虽支持 == 和 !=，但其可比较性仅限于同一变量的地址或 nil，且 Go 语言规范中**显式将指针排除在 comparable 类型之外**（除 unsafe.Pointer 外）。哪怕你手动取地址、确保不逃逸，map[*int]int 依然非法。
常见错误现象：cannot use &x as map key (pointer type *int is not comparable)；有人误以为加了 unsafe.Pointer 就能绕过，但那是另一套规则，且极度危险，不解决本质问题。
- 别试图用
map[*struct{...}]或map[*string]—— 语法上就过不去 - 如果真需要“按对象身份”索引，得换思路：用
uintptr手动存地址（需配合unsafe，且必须确保对象不被 GC 移动） - 更稳妥的做法是引入唯一 ID 字段（如
id int64），用map[int64]V
想靠 fmt.Sprintf("%p", ptr) 生成字符串当 key？别这么做
有人用 fmt.Sprintf("%p", &x) 得到类似 0xc000010230 的字符串，再塞进 map[string]V。表面能跑，但隐患极深：
- GC 可能移动对象（尤其当变量逃逸到堆上），下次取地址时
%p输出不同值，导致 key 失效 -
fmt.Sprintf开销大，频繁调用会拖慢性能，且字符串分配带来 GC 压力 - 不同平台或 Go 版本下，
%p格式可能变化（比如加前缀、十六进制大小写） - 若对象被回收后内存重用，旧字符串 key 可能意外命中新对象（极难调试）
这不是边界情况——只要程序运行时间够长、分配足够多，就会暴露。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
真正安全的替代方案：用 reflect.ValueOf(ptr).Pointer() + map[uintptr]V
如果必须基于地址做唯一标识（比如实现对象级缓存、弱引用映射），可用 reflect.ValueOf 提取底层地址，并转为 uintptr。它比 fmt.Sprintf 稳定，也比裸 unsafe.Pointer 更可控。
示例：
func ptrKey(ptr interface{}) uintptr {
return reflect.ValueOf(ptr).Pointer()
}
m := make(map[uintptr]string)
x := 42
m[ptrKey(&x)] = "value for x"
- 必须保证
ptr是指针类型，否则.Pointer()返回 0（即 nil 地址） - 该地址仍可能因 GC 移动失效——所以只适用于栈上短期存活的对象，或配合
runtime.KeepAlive延长生命周期 - 若对象在堆上且生命周期长，建议改用
sync.Map+ 自增 ID 或unsafe.State（Go 1.22+）等更现代机制
为什么 unsafe.Pointer 也不推荐直接当 map key？
虽然 unsafe.Pointer 是 comparable 类型，允许写 map[unsafe.Pointer]V，但这只是“语法合法”，不代表逻辑安全：
-
unsafe.Pointer本身不携带所有权或生命周期信息，map 持有它不会阻止 GC 回收目标对象 - 一旦原对象被回收，该指针变成悬垂指针（dangling pointer），后续读取触发 undefined behavior（崩溃或静默错误）
- 无法判断 key 对应的内存是否还有效，也无法自动清理失效项
- 代码可读性和维护性差，其他开发者很难意识到这个 map 实际依赖内存布局稳定性
地址比较这件事，在 Go 里从来就不是“拿来即用”的功能。它要么被语言层挡住（指针不可作 key），要么得自己扛住 GC、逃逸、并发读写所有责任——稍有疏忽，就是夜间报警的根源。
