在 Go 开发里，map 几乎随处可见，但它并不等同于“可随意拿到元素地址的容器”。很多人第一次写出 &m["a"] 时，都会被编译器直接拦下。要真正理解这条限制，关键不在语法记忆，而在于搞清楚 map 元素为什么不能被当作稳定内存来引用，以及不同业务场景下该选哪种改法才更合适。
这篇文章就围绕三个常见问题展开：为什么不能取地址、不能取地址时如何修改值、遍历时又有哪些容易踩中的坑。看完后，你可以根据结构体大小、修改频率和是否需要长期持有引用，判断该用值类型 map，还是直接改成指针类型 map。
为什么不能直接对 map 元素取地址
先看一个最直接的例子：
m := map[string]int{"a": 1}
ptr := &m["a"] // 编译错误：cannot take the address of m["a"]这段代码无法通过编译，原因不是 Go 少提供了一个语法能力，而是语言设计明确禁止这样做。
map 在 Go 中是引用类型，底层实现依赖哈希表。当 map 扩容、搬迁桶，或者发生重新哈希时，元素所在的位置可能变化。也就是说，某个键当前对应值的存放地址，并不是一个可以长期依赖的固定地址。
如果语言允许直接写 &m["a"]，那么程序拿到的这个指针，后续就可能因为 map 内部重排而失效，最终变成悬空指针。Go 干脆在编译阶段把这类写法禁止掉，用一个更强硬的规则换取更稳定的内存安全。
可以把结论记成一句话：不是元素没有地址，而是这个地址不具备稳定可引用的前提，所以 Go 不允许你直接获取它。
不能取地址时，如何正确修改 map 中的值
既然不能直接拿到元素地址，修改 map 中的数据就要换一种方式。常见做法有两类，适用场景并不相同。
方法一：取出、修改、再存回
当 map 的值是普通值类型，尤其是结构体时，最稳妥的写法是先取出副本，修改后再写回：
m := map[string]User{"a": {Name: "Tom"}}
// 1. 取出元素到临时变量
user := m["a"]
// 2. 修改临时变量
user.Name = "Jerry"
// 3. 将修改后的值存回map
m["a"] = user这套模式的优点是行为清晰、没有额外引用关系，也更符合 Go 对值语义的处理方式。对于体积不大的结构体，或者修改次数不高的场景，这通常已经足够。
它的代价也很明确：会发生值拷贝。如果结构体较大、字段较多，或者更新操作非常频繁，反复取出和写回会带来额外开销。
方法二：让 map 直接保存指针
如果你本来就希望长期修改同一批对象，更常见的方式是把 map 的值改成指针类型：
m := map[string]*User{"a": {Name: "Tom"}}
// 可以直接修改，无需"存回"操作
m["a"].Name = "Jerry"这样做的关键变化在于：map 里保存的不再是整个结构体副本，而是一个指向结构体的指针。map 内部即使重排，变化的也是键值对在哈希表中的存放位置，而不是你指针指向的那块对象内存本身。
这种写法更适合两类场景：一是结构体比较大，值拷贝成本高；二是业务上需要频繁原地更新对象状态。但同时也要接受指针共享带来的约束，比如对象可能被多处同时引用，代码可变性更强，并发访问时也更容易出现数据竞争。
遍历 map 时，更容易踩中的取地址陷阱
比“不能对 m[key] 取地址”更隐蔽的坑，是在 for...range 里对循环变量取地址。
来看这段代码：
m := map[string]Result{
"server1": {ID: 1, Port: 6379},
"server2": {ID: 2, Port: 6380},
}
var results []*Result
for key, res := range m {
results = append(results, &res) // 错误：所有指针指向同一个地址
}问题不在 map 元素本身，而在循环变量 res。在 range 过程中，这个变量会被重复使用，每次迭代只是把新值赋给同一个变量。因此你追加进切片的，其实一直是同一个地址，最后拿到的多个指针都会指向同一个循环变量。
这类问题在排查时尤其麻烦，因为代码表面上看起来像是在“给每个元素都取一个地址”，实际上保存的是同一个中间变量。
正确写法通常有两种：
// 方法1：创建新变量
for key, res := range m {
temp := res // 创建副本
results = append(results, &temp)
}
// 方法2：直接使用指针类型的map
mPtr := map[string]*Result{
"server1": {ID: 1, Port: 6379},
"server2": {ID: 2, Port: 6380},
}
for key, resPtr := range mPtr {
results = append(results, resPtr) // resPtr已经是指针
}第一种方式适合临时处理已有的值类型 map；第二种方式则更适合一开始就明确要持有元素引用的设计。
实际开发中该怎么选
回到工程实践，关键不是背下“不能取地址”这条规则，而是根据数据特征做出合适的建模。
- 小结构体、修改不频繁：优先使用值类型
map，配合“取出-修改-存回”模式，逻辑简单，副作用少。 - 大结构体、更新频繁：考虑使用指针类型
map，减少值拷贝，更适合持续修改同一对象。 - 需要长期持有元素引用：不要试图从值类型
map中取地址，直接使用指针类型，或者单独拷贝出一份稳定对象。 - 存在并发访问：无论值类型还是指针类型，都不能忽略并发安全问题。需要使用
sync.RWMutex保护共享map，或者根据场景考虑sync.Map。
尤其要注意，指针类型 map 解决的是“方便修改”和“减少拷贝”问题，并不会自动解决并发读写问题。多个 goroutine 同时读写同一个对象时，锁和同步策略依旧是必须单独设计的。
这条限制背后的核心判断
Go 禁止直接对 map 元素取地址，本质上是在避免开发者依赖一个不稳定的内存位置。只要记住 map 元素可能因扩容和重排而迁移，很多相关限制就都能顺着理解下来。
因此，遇到需要修改元素内容的情况，可以直接套用一个判断逻辑：如果只是偶尔改动，用“取出-修改-存回”；如果对象大、修改多、还要长期引用，就把值设计成指针类型。再往前一步，凡是写到 range 取地址的地方，都应该额外检查一下取到的到底是元素副本，还是循环变量本身。
把这些边界想清楚后，map 相关代码通常会更稳定，也更接近 Go 提倡的那种明确、可预期的写法。
