Go 的 map 并发写会 panic，因运行时检测到 concurrent map writes；sync.Map 适用于读多写少场景，而 sync.RWMutex+泛型 map 更灵活高效。
为什么map在 goroutine 里一并发写就 panic？
Go 的 map 不是并发安全的，运行时检测到多个 goroutine 同时调用 map 的写操作（比如 m[key] = value 或 delete(m, key)），会直接触发 fatal error: concurrent map writes 并崩溃。这不是概率问题，只要发生就是必现——因为 Go 在 runtime 层做了写冲突检测，不是靠锁竞争失败来提示。
常见错误场景包括：
- 启动多个 goroutine 循环往同一个全局
map写入数据（比如统计、缓存填充） - 没意识到
range遍历中修改map也算写操作（哪怕只改值不增删键） - 把
map作为结构体字段暴露给多个 goroutine，又没加同步控制
用 sync.Map 替代普通 map 的适用边界
sync.Map 是标准库提供的并发安全映射，但它不是万能替代品。它的设计目标是「读多写少」场景，内部用了分片 + 延迟初始化 + 读写分离等策略，写性能比加锁的普通 map 差不少。
适合用 sync.Map 的情况：
立即学习“go语言免费学习笔记（深入）”；
- 键集合相对固定，大部分操作是
Load和LoadOrStore - 写操作频率低（比如配置热更新、连接池元信息维护）
- 不想自己管理锁，且能接受接口风格（
interface{}键值，无泛型支持）
不适合的情况：
- 需要遍历全部键值对（
Range是快照式，期间写入不可见） - 频繁删除或批量初始化（
sync.Map没有Clear，也没法像普通map那样make(map[K]V, n)预分配） - Go 1.21+ 项目且键值类型明确——这时更推荐用
sync.RWMutex+ 泛型map
用 sync.RWMutex + 普通 map 的实操要点
这是最灵活、性能可控、也最常用的做法。核心是：读用 RLock，写用 Lock，且锁粒度必须包住整个 map 操作（不能只锁赋值那行）。
典型结构：
type SafeMap struct {
mu sync.RWMutex
m map[string]int
}
func (s *SafeMap) Get(key string) (int, bool) {
s.mu.RLock()
defer s.mu.RUnlock()
v, ok := s.m[key]
return v, ok
}
func (s *SafeMap) Set(key string, value int) {
s.mu.Lock()
defer s.mu.Unlock()
s.m[key] = value
}
容易踩的坑：
- 忘记在
Get后加defer s.mu.RUnlock()—— 会导致后续所有读被阻塞 - 在
Range遍历时写入：即使用了RWMutex，也不能在Range回调里调Set，否则可能死锁或 panic（因为Range内部已持读锁） - 把
map直接暴露出去（如返回s.m）—— 外部绕过锁直接操作，锁就失效了
Go 1.21+ 推荐：泛型封装 + sync.RWMutex
新版本可以直接用泛型写类型安全的并发 map，避免 interface{} 强转和反射开销。关键点是：泛型参数要约束为可比较类型（comparable），且锁必须是结构体字段，不能是局部变量。
最小可用示例：
type ConcurrentMap[K comparable, V any] struct {
mu sync.RWMutex
m map[K]V
}
func NewConcurrentMap[K comparable, V any]() *ConcurrentMap[K, V] {
return &ConcurrentMap[K, V]{m: make(map[K]V)}
}
func (c *ConcurrentMap[K, V]) Load(key K) (V, bool) {
c.mu.RLock()
defer c.mu.RUnlock()
v, ok := c.m[key]
return v, ok
}
注意：
- 不要在
NewConcurrentMap里传初始容量——make(map[K]V, n)可以加，但别漏掉map[K]V类型声明 - 如果需要深拷贝或序列化，得自己实现，
sync.RWMutex不支持导出 - 并发写崩溃不会因为用了泛型就消失；锁没加对、或漏加，照样 panic
真正难的从来不是选 sync.Map 还是 RWMutex，而是判断哪些操作必须串行、哪些可以并行，以及锁的生命周期有没有意外延长。很多崩溃，其实发生在你以为“只是读”的地方——比如 len(m) 虽然不改数据，但 runtime 仍需检查 map 状态，某些旧版 Go 里它会触发写屏障检测。所以，宁可多锁一行，别省那一毫秒。
