go中map是引用类型，直接传递即可共享底层hmap；*map[string]int极少使用，仅适用于原子替换整个map实例的特殊场景。
Go 里 map 是引用类型，但不是指针类型
直接声明 map[string]int 变量后，它本身就是一个引用——底层指向 hmap 结构体。你不需要、也不该用 *map[string]int 来“手动取地址”传递或修改 map。
常见错误现象：cannot use &m (type *map[string]int) as type map[string]int in assignment，或者函数内增删元素后原 map 没变化（其实是传了 *map 却没解引用）。
- 所有 map 操作（
make、赋值、delete、遍历）都作用于同一底层结构，只要没重新赋值给变量本身（比如m = make(map[string]int)），就共享状态 -
*map[string]int是一个指向 map 头部的指针，极其罕见需要——仅当你要在函数中替换整个 map 实例（比如原子替换）且必须避免拷贝头部时才考虑 - 性能上，传
map[string]int和传*map[string]int几乎没差别（都是 8 字节指针大小），但后者语义混乱、易出错
什么时候真得用 *map？基本不用
绝大多数场景下，所谓“需要指针”的需求，其实只是没理解 map 的引用行为。比如想让函数修改 map 内容，直接传 map 就行；想清空，用 for k := range m { delete(m, k) } 或重置为 nil 后再 make。
唯一合理使用 *map[string]int 的场景：你需要在函数中完全替换 map 变量所指向的底层结构，并让调用方看到这个“换地图”的动作（比如配置热更新、并发安全 map 替换）。但这本质是“交换指针”，不是“操作 map 内容”。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
func bad(p *map[string]int) { *p = make(map[string]int); (*p)["x"] = 1 }—— 调用方需传&m，冗余且反直觉 - 正确写法：
func good(m map[string]int) { for k := range m { delete(m, k) }; m["x"] = 1 }—— 直接操作，简洁清晰 - 若真要原子替换，用
sync/atomic.Value存map更安全，而不是裸指针
map 为 nil 时的行为和 panic 风险
未初始化的 map 变量值为 nil，此时读、写、len、range 都不会 panic，但写入键值对会 panic：panic: assignment to entry in nil map。
这和 slice 不同：slice 为 nil 时 append 仍可工作，而 map 必须显式 make 才能写。
- 常见坑：结构体字段声明为
map[string]string，但忘记在new或构造函数里make，后续一写就崩 - 检查是否为 nil：用
m == nil判断，但注意len(m)对 nil map 返回 0，不能靠 len 判空 - 初始化建议：在 struct 初始化时统一
make，或用工厂函数封装，避免零值误用
并发写 map 导致的 fatal error
Go 运行时会在检测到多个 goroutine 同时写同一个 map 时直接 crash：fatal error: concurrent map writes。这不是 panic，无法 recover，进程立即退出。
原因在于 map 的扩容和哈希桶迁移不是原子操作，多线程写必然破坏内部状态。
- 最简单方案：用
sync.RWMutex包裹读写，读多写少时效率尚可 - 高频写场景：改用
sync.Map，但它只适合“读多写少 + key 类型固定 + 不需要遍历全部元素”的情况，API 更受限（无泛型支持，value 是 interface{} - 更现代做法：用
golang.org/x/sync/singleflight配合普通 map 做读写分离，或用 channel 序列化写操作
别试图靠“只读不写”或“写前加锁判断”来绕过，runtime 的检测非常激进，一次未同步的写就足够触发 fatal。
