Go中map传参是header副本传递，可修改内容但不能使原map变nil或换底层数组；需改nil或替换底层数组时必须传*map；并发读写必加锁，否则panic。
Go 中 map 传参不是真正的引用传递
直接说结论：map 类型作为函数参数时，看起来能修改原 map 的内容，但本质上传的是 map header 的副本——它包含指针、长度和容量三个字段。所以你能改值、增删键，但无法让外部的 map 变量指向新底层数组或变成 nil。
常见错误现象：func clearMap(m map[string]int) { m = make(map[string]int) } 调用后原 map 毫无变化；或者在函数里对 m 做 delete 或 m["k"] = v 却发现外部可见——这容易让人误以为是“引用”，其实是 header 里的指针字段被复制了，指向同一块底层 hmap 结构。
- 真正想清空 map，请用
for k := range m { delete(m, k) }，而不是重新赋值m = ... - 如果需要让调用方的 map 变成
nil，必须传 ***map**（即指向 map 的指针） -
map底层结构hmap是非导出的，不能直接操作，所有行为都受限于 runtime 对 header 副本的处理逻辑
什么时候必须传 *map
只有两种典型场景绕不开指针：一是要在函数内把 map 变成 nil，二是要完全替换底层数组（比如扩容后重建、或从 nil map 安全初始化）。
使用场景举例：封装一个带懒加载的配置 map，首次访问才初始化，且希望初始化后让外部变量不再为 nil：
立即学习“go语言免费学习笔记（深入）”；
func initConfig(m *map[string]string) {
if *m == nil {
*m = make(map[string]string)
}
(*m)["env"] = "prod"
}
如果不加 *，make 后只改了局部 header，外部仍为 nil，后续 panic。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 传
*map会多一次内存解引用，性能影响极小，但语义更明确 - Go 标准库几乎不用
*map，因为多数情况只需读写已有 key，header 复制已够用 - 注意：
*map不是“更高级的引用”，只是普通指针——它指向的是 map header 的地址，不是底层数组
map 和 slice 传参行为对比
两者常被一起误解，但机制不同：slice 传参也是 header 副本（含指针、len、cap），但它能通过 append 触发扩容，从而让 header 指针指向新数组——此时外部 slice 仍指向旧数组，修改不可见；而 map 的 make 或重赋值不会影响外部 header 的指针字段。
关键差异点：
-
append(s, x)可能改变s的底层数组，但不会改变调用方的 slice header —— 所以必须接收返回值：s = append(s, x) -
m["k"] = v不会改变m的 header，只修改底层hmap数据，所以无需返回值 - 两者都不能靠赋值
=让外部变量变nil或换底层数组，除非用指针
并发读写 map 的坑比传参更致命
传参行为再绕，也比不上并发读写导致的 panic：fatal error: concurrent map read and map write。这个错误不看传参方式，只看是否多个 goroutine 同时触发 map 的写操作（包括 delete、clear、赋值）。
常见错误现象：一个 goroutine 在遍历 for range m，另一个在写 m[k] = v，程序立刻崩溃。
- 不要依赖“只读 goroutine 安全”——Go runtime 不区分读写，只要有一个写，其他所有并发访问都不安全
-
sync.Map是为高频读+低频写优化的，但接口不兼容原生map，且零值可用，别滥用 - 最稳妥的方式仍是
sync.RWMutex包裹原生map，尤其当你需要原子性地完成“查-改-删”组合操作时
传参那点绕弯子的事，真到线上出问题，九成九是这里没锁住。
