解读

国内一线/二线厂面试中，这道题常被用作“语法糖背后的实现细节”过滤器。
面试官想确认两点：

1. 候选人是否知道 map 的扩容与重哈希机制会导致旧桶指针失效；
2. 能否给出工程级的替代写法，而不是停留在“map 不能 &v”这一句话。
   答出“扩容”与“*struct 值”两个关键词，基本能拿到 80% 分；若能补充零拷贝更新与并发安全细节，可冲 90%+。

知识点

1. 哈希表分裂与再哈希：Go runtime 在装载因子 > 6.5 或溢出桶过多时触发翻倍扩容，旧桶数据逐步搬迁到新桶，原地址内容随时失效。
2. 语言层保护：编译器对 &m[key] 直接报错 “cannot take the address of m[key]”，防止程序员持有悬空指针。
3. 值语义与指针语义：map 存储的是值拷贝，即使存放的是指针类型，也只是拷贝指针本身，而非指针指向的数据。
4. 绕过手段：把 value 类型设计成 *struct，对外暴露的仍是“值拷贝”，但拷贝的是指针，因此可以通过二次解引用安全地修改原对象，而不依赖 map 内部地址。
5. GC 约束：由于 map 桶里可能包含指针，Go 1.19+ 在标记阶段会扫描整个桶数组，减少指针数量可降低 GC 压力，这也是官方推荐“map 里放 *struct 而不是 struct”的隐藏原因。

答案

“map 元素不可取地址”是语言级强制策略，根因是 map 在扩容时会把键值对从旧桶搬迁到新桶，旧桶内存会被回收。如果允许 p := &m[key]，那么 p 在扩容后就变成悬空指针，破坏内存安全。
绕过办法：把 value 类型声明为指针结构体 *User，示例：

type User struct{ Name string }

m := make(map[int]*User)
m[1] = &User{Name: "Alice"}

// 安全更新，无需取 map 内部地址
m[1].Name = "Bob"

由于 map 里保存的是 *User 的指针副本，扩容时只搬迁指针本身，指针指向的 User 对象在堆上地址不变，因此通过“二次解引用”可以零拷贝地修改原对象，既规避了取地址限制，又保证了并发读写时数据一致性（需额外加锁或 sync.Map）。

拓展思考

1. 零拷贝更新 vs 替换指针：如果业务需要原子级替换整个对象，应直接 m[1] = &newUser，而不是逐字段修改，避免中间状态被并发读脏。
2. GC 友好性：map 里存 *User 比存 User 能减少桶内指针数量，降低 GC 扫描成本，在高并发缓存场景（如百万级连接网关）能显著减少 STW 时间。
3. 并发安全：官方 sync.Map 的 LoadOrStore 同样返回的是 interface{} 的值拷贝，若存放的是 *struct，逻辑与普通 map 一致，仍需注意指针指向的数据竞态。
4. 未来演进：Go 团队曾在 1.20 的 dev 分支尝试过冻结桶的“可寻址 map”实验，但因性能回退被废弃，短期内不会放开 &m[key] 的限制，工程上仍需依赖“*struct”模式。