为什么Go语言不允许获取map值的地址？

嘿，这个问题确实问到了Go语言设计的核心细节，之前那句“切片由底层数组支持，而映射则不然”太笼统，我给你拆解清楚本质原因！

先看slice：取元素地址是安全的 #

• slice本质是个包含底层数组指针、长度、容量的结构体，当你写&s[i]时，其实是直接获取底层数组对应索引位置元素的内存地址。
• 底层数组的内存是连续且稳定的——除非slice触发扩容（比如append后长度超过容量），但扩容后会生成新的底层数组，而你在扩容前取的地址，在当时的slice上下文里是完全有效的，后续操作不会出现野指针问题。
• 而且slice的元素不会被Go自动移动位置，只要你持有当前slice，这个地址就一直指向有效的内存区域，所以Go放心让你取。

再看map：取成员地址会埋下安全隐患 #

这才是问题的核心，map的底层是哈希表，有几个天生的特性导致取地址不安全：

• 哈希表会自动rehash/扩容：当map里的元素数量达到阈值，Go会悄悄进行扩容或者重新哈希，这时候所有元素的内存位置都会被移动到新的桶里。如果允许你取map成员的地址，rehash之后这个地址就变成了无效的野指针，后续通过指针操作会直接引发内存错误，这是Go绝对要避免的。
• 零值的特殊性：当你访问m[key]如果key不存在，返回的是对应类型的零值，但这个零值是临时生成的，根本不是map里存储的元素（因为元素本身就不存在）。如果允许取这个零值的地址，你会误以为它指向map里的实际元素，但修改它对map完全没有影响，反而容易造成逻辑bug。
• 并发安全的隐性防护：虽然map本身不是并发安全的，但禁止取地址也避免了更隐蔽的数据竞争——比如多个goroutine通过指针直接修改同一个map元素，这种操作比直接赋值更难排查问题，Go从源头堵上了这个口子。

总结一下设计意图 #

Go的设计哲学就是尽可能避免不安全的操作：

• slice的元素地址是可控、稳定的，所以允许获取；
• map的元素内存位置随时可能变动，取地址会带来野指针、逻辑bug等风险，所以直接禁止。

说白了，这不是技术上做不到，而是Go为了语言的安全性和简洁性，主动做出的设计选择。

内容的提问来源于stack exchange，提问作者user13097