问题的历史。 Go 的 map 被实现为具有可增长桶的哈希表。当负载因子超过阈值时，运行时会启动增长阶段，在此阶段, 条目被重新哈希并重新分配到新的、更大的桶数组中。
问题。 如果语言允许像 &m["key"] 这样的表达式，结果指针将引用哈希桶内的特定内存位置。在 map 增长期间，条目被复制到新的桶中，旧的桶被释放，从而使任何现有的指针悬空并且不安全。
解决方案。 Go 规范明确禁止获取 map 索引表达式的地址。编译器将 &m[k] 视为无效操作，确保没有程序可以持有指向 map 内部的指针。这使得运行时可以在增长或缩小时自由地重新定位条目，而无需管理指针更新或失效。
问题描述。 在一个高吞吐量的遥测服务中，工程师需要更新存储在内存缓存 map 中的大配置结构中的计数器字段。最初的尝试使用 cfg := &configMap[deviceID]; cfg.Counter++，但由于出现 "cannot take address of map element" 的错误而无法编译。这个模式在团队迁移的 C++ 代码库中很常见，其中 std::map 迭代器保持稳定。
解决方案 1：在 map 中存储指针。 将 map 类型从 map[string]Config 更改为 map[string]*Config。这使得可以直接检索指针并修改底层结构，而无需重新分配。优点包括允许直接修改并避免结构复制，而缺点包括堆分配增加、缓存局部性降低以及需要进行 nil 检查。
解决方案 2：复制-修改-重新赋值。 将值检索到局部变量中，进行修改后，通过 cfg := configMap[deviceID]; cfg.Counter++; configMap[deviceID] = cfg 写回。优点包括与值类型一起工作且没有额外分配，而缺点则包括在每次更新时复制大型结构体的性能开销。
解决方案 3：使用 sync.RWMutex 和结构体包装。 用互斥锁保护 map，以允许在并发环境中安全读取-修改-写入循环。优点包括为并发访问提供明确同步，而缺点包括潜在的锁竞争以及继续需要重新赋值。
选择的解决方案及结果。 对于小型结构体（<64 字节），由于其简单性和零分配特性，采用了解决方案 2。对于大型、频繁更新的结构体，使用了解决方案 1，并采用池分配以减轻 GC 压力。系统在不依赖不安全指针技巧的情况下实现了稳定的性能。
为什么可以获取切片元素的地址，但不能获取 map 元素的地址？
获取切片元素的地址 &s[i] 是有效的，因为切片的后备数组具有稳定的内存地址，除非切片被重新分配（例如，通过 append 超过容量）。只要底层数组没有重新分配，指针就是有效的。相比之下，map 桶在增长操作期间会定期重新定位。如果允许 map 元素的地址，它们在重新哈希后将成为悬空指针，从而违反内存安全。
使用指针的 map 是否允许在不重新赋值的情况下修改存储的数据？
虽然你不能获取指针槽本身的地址（&m[key] 在 map[K]*V 中也是无效的），但你可以取出指针值并解引用它：p := m[key]; p.Field = newVal。这是有效的，因为你是通过指针的副本来修改堆分配的结构，而不是 map 的内部存储。这个区别很微妙：map 存储指针值（一个地址），虽然这个地址值不能直接获取，但它可以被读取并用于访问堆对象。
如果允许元素的地址，map 增长将如何工作？
如果语言允许 &m[key]，运行时需要确保在桶迁移期间指针的稳定性。这将需要间接（在桶中存储指向条目的指针，增加指针开销）、不释放旧桶（内存泄漏）或在重新定位期间实现读取屏障以更新指针（显著性能成本）。当前的设计通过牺牲获取元素地址的能力来优化 map 操作的常见情况，避免了这些开销。