sync.Map 专为读多写少、键生命周期长的场景优化，非通用并发安全替代品；适用于缓存、只读为主全局配置等，不支持 range 遍历，Load/Store 语义与普通 map 不同，误用易致性能下降或逻辑错误。
sync.Map 不是“并发安全的通用 Map 替代品”，它是为**读多写少、键生命周期较长**的场景优化的特殊结构。盲目替换 map + sync.RWMutex 可能导致性能下降或语义错误。
什么时候该用 sync.Map？
它适合这些明确场景：
- 缓存类数据（如 HTTP handler 中按用户 ID 缓存临时 token），读操作远多于写，且 key 很少被删除
- 全局配置映射，启动时初始化，运行中只偶尔更新个别字段
- 不需要遍历全部键值对，也不依赖
len()的精确性（sync.Map没有导出的Len()方法） - 无法预估 key 数量，又想避免锁竞争（但注意：高写入频率下，它的
Store会退化为加锁操作）
Load/Store 和普通 map 的语义差异
sync.Map 的方法不接受 interface{} 类型的 value —— 它只做类型擦除，不做类型检查。传入 nil 是合法的，但 Load 返回 (nil, false) 时，你无法区分“key 不存在”和“key 存在但值为 nil”。
常见误用：
立即学习“go语言免费学习笔记（深入）”；
var m sync.Map
m.Store("key", nil)
v, ok := m.Load("key") // v == nil, ok == true —— 注意！ok 为 true
所以别依赖 v == nil 判断存在性，始终看 ok。
为什么不能用 range 遍历 sync.Map？
它没有实现 range 协议，因为并发修改时遍历结果不可靠。必须用 Range 方法传入回调函数：
m.Range(func(key, value interface{}) bool {
// 处理 key/value
return true // 继续遍历；返回 false 则中断
})
注意：Range 是弱一致性快照 —— 它不保证看到所有已 Store 的项，也不保证不重复看到某项。不要在 Range 回调里调用 Load/Store/Delete，否则可能触发 panic 或死锁。
比 sync.Map 更常见的替代方案
大多数真实业务场景，更推荐：
- 读写都频繁？直接用
map+sync.RWMutex，清晰可控，基准测试通常更快 - 需要原子计数？用
sync/atomic管理单个整数，别塞进 map - 要支持删除+遍历+精确长度？老老实实用
map加互斥锁（sync.Mutex），别贪图“无锁”假象 - 键类型固定且数量有限？考虑
sync.Pool或分片 map（sharded map），自己控制锁粒度
sync.Map 的内部实现包含 read map + dirty map + miss counter，这些机制只为特定负载服务。用错场景时，它反而比一把锁更重。
