sync.Map适合读多写少场景，读操作无锁高效，但高频写会导致锁竞争加剧、性能反降；不适用于计数器、遍历一致性要求高或删除密集型场景。

sync.Map 适合读多写少的场景

它不是万能的并发 map 替代品，而是为特定负载优化的设计：当 Load 次数远高于 Store 或 Delete 时，性能优势才明显。比如配置缓存、服务发现注册表（只注册一次，反复查询）、HTTP 请求上下文元数据映射等。

• 读操作（Load、LoadOrStore 成功路径）是无锁的，直接访问 read map，开销极低
• 写操作（Store 新 key、Delete）会先尝试写 dirty map，但若 amended == false（即 read 和 dirty 同步完成），就得加锁并重建 read
• 高频写入会导致 misses 快速累积，频繁触发 dirty → read 全量晋升，此时锁竞争加剧，性能反不如 sync.Mutex + map

多个 goroutine 操作互不重叠的 key 是安全且高效的

这是 sync.Map 的隐含前提——它不保证「写写一致性」或「写后读立即可见」的强语义，但只要不同 goroutine 写的是不同 key，就不会互相阻塞，Store 可以并发执行。

• 例如：每个请求 goroutine 存自己的 traceID 到全局 sync.Map，key 是 requestID，彼此完全隔离
• 但如果两个 goroutine 频繁交替 Store("counter", x) 修改同一个 key，不仅无法避免锁竞争，还可能因 dirty 中旧值残留导致意料外的覆盖行为
• LoadOrStore 对单个 key 是原子的，但注意它返回的 loaded bool 表示“本次调用前是否存在”，不是全局最新状态

不适合高并发写、计数器、需要遍历一致性或删除密集型场景

这些是开发者最容易误用的地方，表面看能跑通，实则埋下性能和逻辑隐患。

• 不要用 sync.Map 实现自增计数器（如 m.Store("hits", m.Load("hits").(int) + 1)）——这不是原子操作，且反复 Load/Store 会大量 miss，逼迫晋升，最终比 sync.Mutex + map 慢 3–5 倍
• Range 不是快照遍历：回调中其他 goroutine 的 Store 可能被看到，Delete 可能被跳过，无法保证遍历期间数据稳定
• 频繁 Delete 会加速 dirty 膨胀（因为删除只发生在 dirty，read 里对应 entry 被标记为 nil），进一步抬高晋升成本
• 如果写入 QPS > 1k 且 key 空间小（比如固定几个监控指标），基本该换 sync.RWMutex + map 或分片 map

怎么判断你该不该用 sync.Map？

别靠直觉，看实际压测数据，尤其关注 sync.Map 的两个隐藏成本：锁等待时间和 dirty 晋升频率。

• 用 go tool pprof 抓 CPU profile，如果 sync.(*Map).missLocked 或 sync.(*Map).dirtyLocked 占比超过 10%，说明写压力已超出设计预期
• 简单对比：在相同 key 分布和读写比例下，压测 sync.Map 和 struct{ sync.RWMutex; m map[string]interface{} }，看吞吐与 p99 延迟谁更优
• 如果你的场景需要支持 len()、map iteration 顺序保证、或与其他 map 操作（如 merge、diff）耦合紧密，直接放弃 sync.Map，它连 len 都不提供

真正关键的不是「能不能用」，而是「在当前读写比例、key 分布、更新频率下，它会不会悄悄拖垮你的延迟毛刺或 GC 压力」。sync.Map 的设计哲学是用空间换读性能，不是用复杂度换通用性。