sync.Map适合读多写少场景，读操作无锁高效，但高频写会导致锁竞争加剧、性能反降；不适用于计数器、遍历一致性要求高或删除密集型场景。
sync.Map 适合读多写少的场景
它不是万能的并发 map 替代品，而是为特定负载优化的设计：当 Load 次数远高于 Store 或 Delete 时，性能优势才明显。比如配置缓存、服务发现注册表（只注册一次，反复查询）、HTTP 请求上下文元数据映射等。
- 读操作（
Load、LoadOrStore成功路径）是无锁的，直接访问readmap，开销极低 - 写操作（
Store新 key、Delete）会先尝试写dirtymap，但若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 是原子的，但注意它返回的loadedbool 表示“本次调用前是否存在”，不是全局最新状态
不适合高并发写、计数器、需要遍历一致性或删除密集型场景
这些是开发者最容易误用的地方，表面看能跑通，实则埋下性能和逻辑隐患。
- 不要用
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语言免费学习笔记（深入）”；
- 用
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 的设计哲学是用空间换读性能，不是用复杂度换通用性。
