绝大多数场景下不该用sync.map，它仅适用于读多写少、键生命周期长且不频繁遍历的场景；高频写入、需range遍历或频繁增删键时，应优先选用map+sync.rwmutex。
sync.Map 什么时候该用、什么时候不该用
绝大多数场景下，sync.Map 不是你需要的“并发安全 Map”。它专为**读多写少、键生命周期长、且不频繁遍历**的场景设计。如果你在做高频写入（比如计数器累加）、需要 range 遍历、或者键会频繁新增/删除，直接用 map + sync.RWMutex 更快、更可控。
常见错误现象：sync.Map 的 Range 是非原子快照，遍历时可能漏掉刚写入的键；LoadOrStore 在键存在时不会更新值，和预期不符；没有 len() 方法，想查大小得自己计数。
- 适合：HTTP 请求的 session 缓存、配置热加载的只读映射表、连接池中长期存活的连接 ID 映射
- 不适合：实时统计（如每秒请求数）、需要排序或批量删除的场景、单元测试里临时建 map
- 性能影响：写操作比加锁 map 慢 2–5 倍；读操作在命中 read map 时接近原生 map，但一旦触发 miss 并升级，开销明显上升
LoadOrStore 和 Store 的行为差异必须看清
LoadOrStore 看似“有就返回、没有就设”，但它对“有”的定义是：键存在且值非 nil（注意：nil interface{} 也算“存在”）。如果之前 Store(k, nil) 过，再调 LoadOrStore(k, v) 仍会返回那个 nil，而不是存入新 v。
而 Store 是无条件覆盖，不管之前有没有、是不是 nil。
- 别依赖
LoadOrStore实现“首次写入才生效”的逻辑，除非你能确保从不存nil - 想实现“空值才写”，得先
Load判断，再Store，但要注意竞态——此时不如直接上sync.RWMutex -
LoadOrStore返回的loadedbool 表示“本次是否命中已有值”，不是“本次是否写入成功”
遍历 sync.Map 必须接受数据不一致
Range 方法不阻塞写操作，它内部先拍一个 read map 快照，再遍历；若期间有写入落到 dirty map，那些键值对就不会出现在本次 Range 中。这不是 bug，是设计取舍。
常见错误现象：后台 goroutine 调 Range 打印所有 key，却发现某些刚 Store 的 key 总是“偶尔消失”。
- 不能用
Range做一致性校验或事务性操作 - 如果必须强一致遍历，请改用
map+sync.RWMutex，并在读前加RLock，读完再RUnlock -
Range回调函数里不要调Load/Store，可能引发 panic（文档明确禁止）
类型擦除带来的隐式开销和调试困难
sync.Map 是 interface{} 键值对，所有类型都要经历装箱/拆箱。这不只是性能损耗，更让调试变得模糊：panic 时堆栈看不到具体类型，fmt.Printf("%v", m) 只输出 &{...}，没法直接观察内容。
对比 map[string]int + sync.RWMutex：类型安全、IDE 可跳转、pprof 能分清内存归属、出错时 panic 信息带具体类型。
- 别为了“省几行锁代码”牺牲可维护性；Go 官方文档也建议：仅当 profiling 确认锁争用是瓶颈时，才考虑
sync.Map - 如果真要用，至少封装一层类型安全 wrapper，比如
type StringIntMap struct{ m sync.Map }，把interface{}转换藏在方法里 - go tool trace 里看
sync.Map操作，会发现大量runtime.convT2E调用，那是接口转换的痕迹
真正难的不是怎么写 sync.Map，而是判断它是不是当前问题的解——多数时候，答案是否定的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
