sync.Map 仅适用于读多写少、键生命周期长的场景，盲目使用反而更慢、易出错；它通过 read/dirty 双结构实现无锁读，但频繁写会触发 costly 晋升，短生命周期 key 导致失效快，且不支持 len、原子遍历，存 nil 值需用 ok 判断存在性。
sync.Map 不是普通 map 的并发安全替代品，它只在「读多写少 + 键长期存在」的场景下真正有用。盲目替换会导致性能更差、逻辑出错，甚至掩盖竞态问题。
为什么直接用 sync.Map 常常反而更慢
它的底层是 read map（原子读）+ dirty map（加锁写），设计目标是降低高并发读的锁开销。但代价明显：
- 首次
Store某个 key 会触发dirty map构建，比普通 map 写入贵得多 - 频繁写入（比如每秒数百次 Store/LoadAndDelete）会让
misses计数器快速累积，导致 read map 失效，后续所有读都 fallback 到加锁的 dirty map - 短生命周期 key（如 HTTP 请求 ID、临时 token）会让 read map 快速“过期”，失去优化意义
- 没有容量预分配能力，无法用
make(map[K]V, hint)控制哈希表初始大小，扩容重哈希更频繁
sync.Map.Load 返回 (nil, true) 是正常现象，别靠 value == nil 判断是否存在
这是最常踩的语义坑：sync.Map 允许存 nil 值，且不区分「key 不存在」和「key 存在但值为 nil」：
-
m.Store("k", nil)合法 -
v, ok := m.Load("k")→v == nil且ok == true - 必须始终检查
ok，不能写if v != nil { ... }来代替存在性判断 - 同理，
LoadOrStore的loaded返回值才是关键，不是actual != nil
遍历必须用 Range，但它的结果不是原子快照
sync.Map 不支持 for range，因为底层无全局锁、无迭代器状态。而 Range 也不是你想象中的“当前全部键值对”：
- 它是弱一致性遍历：可能漏掉刚
Store的项，也可能重复看到同一 key 的不同版本 - 回调函数中禁止调用
Load/Store/Delete—— 不会 panic，但会干扰内部entry状态管理，可能导致内存泄漏或清理延迟 - 如果业务需要「精确枚举一次所有现存 key」，比如做配置校验、批量清理，老老实实用
sync.RWMutex包普通map，自己控制锁范围
什么情况下才该用 sync.Map
它不是“并发 map 的默认选项”，而是特定负载下的妥协方案。只在同时满足以下条件时考虑：
- 读操作远多于写（比如 100:1 以上），且写入集中在初始化或低频配置更新
- key 集合稳定，极少删除，生命周期与程序运行时间相当（如服务级缓存、全局连接池元信息）
- 不需要
len()、不依赖遍历顺序、不关心是否漏掉某次写入（最终一致性可接受） - 已实测对比：在目标压测场景下，
sync.Map的 p99 延迟确实低于RWMutex + map
绝大多数业务代码里，sync.RWMutex 包一层 map[string]interface{} 更直观、更可控、性能也不输 —— 别被“无锁”二字带偏。真正难的从来不是选结构，而是厘清读写比例和 key 生命周期。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
