Go原生map并发写会panic，因运行时主动检测并中止；sync.Map适用于读多写少、键生命周期长场景，不适用于高频增删或需遍历/有序迭代的场景。
为什么直接并发写 map 会 panic
Go 的原生 map 不是并发安全的，只要两个 goroutine 同时对同一个 map 做写操作（包括 delete），运行时就会触发 fatal error：「fatal error: concurrent map writes」。这不是偶发 bug，而是 Go 运行时主动检测并中止程序——它不给你留机会去“碰运气”。
常见诱因包括：
- 没加锁就启动多个 goroutine 往同一
map写数据（比如缓存预热、日志聚合） - 误以为读多写少就能绕过问题（哪怕只有一处写，其他全是读，也必须同步）
- 用
sync.RWMutex保护了读，但忘了写操作仍可能重入或漏锁
sync.Map 适合什么场景，不适合什么
sync.Map 是为「读多写少 + 键生命周期长」设计的，不是通用 map 替代品。它用空间换并发安全，内部维护两层结构（read + dirty），写入新键时先尝试无锁路径，失败再加锁升级。
适用场景：
立即学习“go语言免费学习笔记（深入）”；
- 配置项、连接池、长周期元数据缓存（比如
user_id → *User映射） - 键集合基本稳定，新增少、删除极少（
sync.Map的Delete不真正释放内存） - 无法提前预估 key 数量，又不想自己管锁粒度
不适用场景：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 高频增删（比如每秒万级写入）、键快速轮转（如短时任务 ID 缓存）——性能反而比带锁普通 map 差
- 需要遍历全部键值对（
Range是快照语义，期间新增/修改不可见） - 依赖 map 的确定性迭代顺序（
sync.Map不保证顺序）
用 sync.Map 时最容易踩的坑
它看起来像 map，但行为差异极大。很多 panic 或逻辑错误都源于把 sync.Map 当普通 map 用。
-
Load返回两个值：value, ok，必须检查ok，不能直接解引用（nil value 不等于 key 不存在） -
Store和LoadOrStore都是复制值，如果存的是指针或 struct，修改其字段不会自动同步到 map 外部引用 -
Range回调函数里不能调用sync.Map的任何方法（包括Load），否则可能死锁——文档明确禁止 - 没有
len，也没有clear；要清空只能新建一个实例（或用Range+Delete，但不实时）
示例错例：
var m sync.Map
m.Store("key", &User{Name: "A"})
u, _ := m.Load("key")
u.(*User).Name = "B" // 看似改了，但其他 goroutine Load 到的仍是旧值（除非你 Store 回去）
什么时候该放弃 sync.Map，改用普通 map + sync.RWMutex
当你的场景出现这些信号，sync.Map 就成了负优化：
- 写操作占比超过 10%～20%（比如定时刷新 + 实时上报混合）
- 需要精确控制锁范围（例如只锁某几个 key，而不是整个 map）
- 必须支持
for range迭代，或依赖len(m)获取实时大小 - 已用
sync.Pool或对象复用，想避免sync.Map内部额外的接口转换开销
此时更稳的方案是封装一层：
type SafeMap struct {
mu sync.RWMutex
m map[string]*User
}
func (s *SafeMap) Get(k string) (*User, bool) {
s.mu.RLock()
defer s.mu.RUnlock()
v, ok := s.m[k]
return v, ok
}
注意：初始化 m 必须在首次写前完成（比如构造函数里 s.m = make(map[string]*User)），否则 RWMutex 也救不了 nil map panic。
真正难的不是选哪个工具，而是确认「写频率」和「键稳定性」这两个数字——它们决定了底层数据结构是否匹配你的实际负载。测不出来，就先用带锁普通 map，别迷信 sync.Map 的名字。
