Go中map的key不能直接用指针，因指针比较地址而非内容，对象修改后查找失效，GC可能移动对象，且无法序列化；应改用uintptr（需KeepAlive）或可比较struct。
Go 中 map 的 key 不能直接用指针
Go 的 map 要求 key 类型必须是「可比较的」（comparable），而指针类型本身满足这个条件——但问题出在「语义上」：两个指向不同地址的指针，即使所指内容完全相同，== 结果也是 false；更关键的是，一旦指针指向的对象被修改，key 的哈希值不会自动更新，map 查找就失效了。
常见错误现象：map[*MyStruct]int 看似能编译，但插入后用另一个指向等值对象的指针去查，查不到；或者结构体字段改了，原 key 对应的 value 就“丢了”。
- 指针作为 key 本质是比较内存地址，不是比较内容
- GC 可能移动对象（如切片底层数组重分配），导致指针失效（虽不常见，但非零概率）
- 无法序列化/跨进程共享：指针地址毫无意义
替代方案：用 uintptr 或 struct 字段组合做 key
如果真需要“基于对象身份”的映射（比如缓存某个实例的状态），优先用 uintptr 包裹指针地址——它可比较、不可寻址、不参与 GC，且 hash 行为稳定。
但注意：uintptr 不是真正的指针类型，不能解引用；你得确保该对象在整个 map 生命周期内不会被 GC 回收（例如全局变量、长生命周期结构体字段、或显式调用 runtime.KeepAlive）。
立即学习“go语言免费学习笔记（深入）”；
type Cache struct {
m map[uintptr]int
}
func (c *Cache) Set(p *MyStruct) {
c.m[uintptr(unsafe.Pointer(p))] = 42
runtime.KeepAlive(p) // 防止 p 提前被回收
}
- 别用
unsafe.Pointer直接当 key：它不可比较，编译报错 -
uintptr方案只适用于「对象生命周期可控」的场景，比如对象是全局注册表里的单例 - 若对象可能被复制（如结构体赋值）、或需按内容查，就该换用结构体字段组合（如
struct{ID int; Name string}）
为什么 struct 比指针更安全？
大多数你以为“要用指针做 key”的场景，其实真正要的是“唯一标识某个逻辑实体”，而这个标识通常来自字段值（如 ID、Name、Version），不是内存地址。用 struct 做 key，天然支持内容比较、可预测哈希、可序列化、无 GC 风险。
例如缓存用户数据：map[UserKey]Data，其中 UserKey 是 struct{ID int; TenantID string}，比 *User 更清晰、更可靠。
- struct 字段必须全为 comparable 类型（不能含 slice/map/func/chan/unsafe.Pointer）
- 嵌套 struct 没问题，但要注意字段顺序和命名一致，否则等效内容可能生成不同 hash
- 性能上，小 struct（≤ 2–3 字段）拷贝开销极低，远小于指针误用带来的逻辑 bug 成本
调试时怎么快速发现 key 失效？
当你发现 map 查不到值，先确认是否用了指针 key，再检查三点：
- 插入和查找用的是不是同一个指针变量（而不是两个指向等值对象的不同指针）
- 插入后是否修改了指针所指对象的字段（影响 hash 吗？不影响，但语义已变）
- 用
fmt.Printf("%p", p)打印地址，对比插入和查找时的输出是否一致
一个简单验证方式：len(m) == 0 却能 for range 遍历出元素？说明 key 比较逻辑异常——大概率是用了未初始化指针或 nil 指针混入。
指针作 key 的坑不在语法，而在它悄悄把「对象身份」和「内存地址」绑死，而 Go 的内存模型并不保证后者稳定或有意义。越早意识到这点，越少在 runtime 里抓耳挠腮。
