go 1.21+ 禁止指针类型作 map key，编译报错；旧版本虽可编译但存在地址复用、gc 悬空、查找失效等严重隐患；应改用可比较的逻辑标识（如 id 或结构体字段组合）替代。
Go 语言中指针类型可以作为 map 的 key，但编译器是否允许，取决于你用的是哪个 Go 版本、是否触发了规范限制——而更关键的是，即使能编译通过，行为也极可能违背你的直觉。
map[*T]V 在 Go 1.21+ 直接编译失败
从 Go 1.21 开始，语言规范进一步收紧：指针类型（如 *int、*User）被明确排除在「可比较类型」之外，用于 map key 时会报错：
invalid map key type *T
这不是运行时 panic，是编译期硬性拒绝。常见错误现象包括：
- 写
map[*string]int→ 编译失败，提示invalid map key type *string - 误以为加了
unsafe.Pointer就能绕过 → 实际上unsafe.Pointer本身不可比较，也不能直接作 key - 在旧版本（如 Go 1.19）能跑的代码，升级后突然编译不过
为什么早期版本看似“能用”，实则危险
某些 Go 1.20 及更早版本中，map[*T]V 可能侥幸通过编译，但背后全是陷阱：
-
&v在循环中反复取地址 → 所有 key 实际指向同一栈变量地址，最终只保留最后一次赋值（for _, v := range list { m[&v] = v.ID }） - 两个内容完全相同的结构体，
&u1和&u2是不同 key → 无法按值查，违背多数业务预期 - 指针指向的对象若被 GC 回收（比如局部变量逃逸失败），map 中残留的 key 成为悬空引用，后续读写行为未定义
- 对象若被内存移动（如 runtime 对堆对象重排），地址变更，但 map 不感知，查找失效
uintptr(unsafe.Pointer(p)) 不是解药，只是换种踩坑方式
有人尝试用 uintptr 包裹指针来绕过编译限制，例如：
func (c *Cache) Set(p *MyStruct) {
c.m[uintptr(unsafe.Pointer(p))] = 42
runtime.KeepAlive(p)
}
这确实能编译，但引入新问题：
-
uintptr不是真正的指针，不能解引用，必须靠runtime.KeepAlive人工续命，漏掉就 GC - 如果对象被复制（如结构体赋值）、或跨 goroutine 共享，地址不再唯一，key 失效
- 无法序列化、无法调试、无法打印有意义的 key 值，日志和排查成本陡增
- 一旦 p 是栈变量（哪怕逃逸分析没判准），
uintptr记录的是无效地址
真正该用什么替代指针做 key
95% 的场景下，“想用指针当 key”其实真正需要的是「逻辑唯一标识」，而不是内存地址。推荐方案：
- 用结构体字段组合：如
struct{ID int; TenantID string}—— 可比较、可预测、可序列化、无 GC 风险 - 用 ID 字段单独作 key：如
map[int]*User，value 存指针，key 用稳定 ID - 若结构体含不可比较字段（如
map[string]int），先抽离出可比较的 identity 字段，不要试图用指针“作弊” - 避免嵌套指针 key：如
map[*struct{X *int}]，多一层间接就多一重不确定性
最易被忽略的一点：map 的 key 类型一旦选定，就锁死了语义。用指针，等于把生命周期管理、内存布局、GC 行为全部暴露给业务逻辑——这不是简化，是移交复杂度。
