原生map并发读写会panic，因扩容时无锁保护；sync.Map适用于读多写少场景；自封装RWMutex+map更可控；高竞争时可考虑分片map。
为什么原生 map 在并发读写时会 panic
Go 的原生 map 不是并发安全的，只要同时有 goroutine 在写（insert、delete）或写+读，运行时大概率触发 fatal error: concurrent map writes 或 concurrent map read and map write。这不是概率问题，而是设计使然：底层哈希表在扩容、迁移桶时会修改指针和状态，没有加锁保护。
sync.Map 适合什么场景
sync.Map 是标准库提供的并发安全 map，但它不是通用替代品。它专为「读多写少」且 key 生命周期较长的场景优化，比如配置缓存、连接池元数据管理。
- 写操作（
Store、Delete）比原生 map 慢约 2–5 倍，因为要处理 dirty map 提升、entry 状态标记等逻辑 - 读操作（
Load）在命中 read map 时接近原子读性能；未命中则需加锁查 dirty map - 不支持遍历（
range）、不保证迭代一致性，Range方法是快照式回调，期间增删不影响当前遍历 - 值类型必须是可比较的（满足
==），但 value 本身不会被拷贝 —— 存的是指针，所以注意别让外部修改影响内部状态
自己封装 sync.RWMutex + map 更可控
多数业务场景下，显式加锁比 sync.Map 更清晰、更易测试、性能更可预测，尤其当写操作不频繁或能批量聚合时。
type SafeMap struct {
mu sync.RWMutex
m map[string]int
}
func (sm *SafeMap) Load(key string) (int, bool) {
sm.mu.RLock()
defer sm.mu.RUnlock()
v, ok := sm.m[key]
return v, ok
}
func (sm *SafeMap) Store(key string, value int) {
sm.mu.Lock()
defer sm.mu.Unlock()
if sm.m == nil {
sm.m = make(map[string]int)
}
sm.m[key] = value
}
注意点：
立即学习“go语言免费学习笔记（深入）”；
- 读用
RWMutex.RLock()，避免读写互斥；写必须用Lock() - 初始化
map要在写锁内完成，否则可能 panic（nil map 写） - 如果 key 类型不是
string，需确保其可比较；若要用结构体作 key，字段必须全可比较且不含 slice/map/func - 不要在持有锁时调用可能阻塞或调用本 map 方法的外部函数，以防死锁
什么时候该考虑 sharded map（分片 map）
当写竞争非常激烈（比如每秒数万次独立 key 更新），且 sync.RWMutex 成为瓶颈时，可以按 key 哈希分片，把一个 map 拆成 N 个带独立锁的小 map。
典型做法：
- 固定分片数（如 32 或 64），用
hash(key) & (N-1)定位 shard - 每个 shard 是
*sync.RWMutex+map[K]V - 读写都只锁对应 shard，大幅降低锁争用
- 缺点：内存占用略高、不支持全局 size 统计（只能近似）、遍历需合并所有 shard
已有成熟实现如 github.com/orcaman/concurrent-map，但要注意它默认不处理 key 为指针或含不可比较字段的情况。
sync.Map 或分片。先压测，看 pprof 的 mutex contention 和 CPU profile —— 很多所谓“并发 map 问题”，其实是逻辑层没控制好 goroutine 创建节奏，或者 key 设计导致哈希冲突严重。 
