sync.Map 仅适用于读多写少（读占比>90%）、键生命周期不一的场景；频繁写入时性能反不如加锁普通 map，且不提供 Len()、Delete 不立即释放内存、LoadOrStore 不延迟求值。
sync.Map 的适用场景很窄，别一上来就用
它不是 map 的并发安全替代品，而是为「读多写少 + 键生命周期不一」的特定负载设计的。如果你在 goroutine 里频繁增删 key（比如每秒几百次写），sync.Map 反而比加锁的普通 map 慢；它的优势只在读操作占比 >90%、且 key 不会集中更新时才明显。
常见错误现象：fatal error: concurrent map writes 出现后，下意识换成 sync.Map，结果压测 QPS 不升反降——因为写冲突本可通过细粒度锁或分片控制，而 sync.Map 的写路径有原子操作+内存屏障开销，还带额外指针跳转。
- 适合场景：服务启动时预热一批配置项，后续只读；HTTP handler 中缓存用户 session token（创建一次，反复验证）
- 不适合场景：实时统计计数器（如每请求
Inc()）、消息队列的 pending key 管理 - 性能提示：
Load和LoadOrStore在命中 read map 时几乎零成本；但第一次Store后再Load，可能触发 dirty map 提升，有一次性扩容成本
LoadOrStore 不是原子“查+设”，它可能执行两次函数
LoadOrStore 看似方便，但它的 value interface{} 参数是直接传入的，不会延迟求值。如果你传的是函数调用结果，比如 m.LoadOrStore(key, heavyCalc())，那无论 key 是否已存在，heavyCalc() 都会先执行——这和你直觉里的“仅当不存在时才计算”完全相反。
正确做法是手动判断 + 延迟构造：
立即学习“go语言免费学习笔记（深入）”；
// ❌ 错误：heavyCalc 总是执行
m.LoadOrStore(key, heavyCalc())
// ✅ 正确：只在需要时算
if val, loaded := m.Load(key); loaded {
return val
}
val := heavyCalc()
m.Store(key, val)
return val
- 容易踩的坑：用
LoadOrStore缓存数据库查询结果，却没意识到每次调用都在做无谓的 DB 查询 - 注意：即使 key 已存在，
LoadOrStore返回的loaded是 true，但你传进去的 value 仍会被完整赋值（只是不生效） - 兼容性提醒：Go 1.12+ 才支持
Range方法；旧版本遍历必须靠外部锁 + 复制到普通 map
sync.Map 没有 Len()，别指望快速获知大小
它故意不提供 Len() 方法，因为准确计数需要遍历所有 bucket 或维护额外计数器，都会破坏其读优化目标。你调用 Range 统计长度，实际是 O(n) 全量扫描，且期间其他 goroutine 的写操作仍可并发进行——所以这个“长度”只是快照，下一毫秒就可能失效。
使用场景里若真需要大小感知（比如限流器判定是否满载），说明 sync.Map 本身就不合适：
- 改用带计数器的自定义结构，例如
sync.RWMutex+map+int64计数字段 - 或者接受近似值：用
Range定期采样，但不要用于关键路径判断 - 注意：
Range回调函数内不能调用Store/Delete，否则 panic —— 文档明确禁止，但错误信息是concurrent map iteration and map write，容易误判
删除 key 后，旧值可能还在内存里驻留很久
Delete 只是逻辑标记，并不立即释放内存。如果 key 曾进入 dirty map，删除后它会留在 dirty map 的底层哈希表中，直到下次 misses 达到阈值（默认 256 次未命中），才会把整个 dirty map 提升为 read map 并清空原 dirty map——这意味着一个被删的 key，可能在内存里“幽灵存在”数分钟甚至更久，尤其当写操作稀疏时。
这对内存敏感场景很关键：
- 缓存大量短期 token（如 JWT）时，
sync.Map可能导致 OOM，应改用带 TTL 的 LRU（如github.com/hashicorp/golang-lru） - 调试时用
pprof查 heap，看到大量sync.mapReadOnly或sync.mapBucket实例，大概率是 delete 后残留 - 没有强制刷新 dirty map 的 API；唯一办法是持续写入新 key 直到触发提升，但这不可控
真正难处理的从来不是怎么用，而是什么时候不该用——sync.Map 的接口看似简单，但每个方法背后都藏着权衡取舍，漏掉任一条件，就从优化变成负优化。
