sync.Map 仅适用于读远多于写、key 生命周期长的场景；写频超50次/秒或写占比超1/10时，应改用map+sync.RWMutex。
sync.map 不是通用缓存方案，它只在「读远多于写」且 key 生命周期长的场景下真正有效；盲目替换普通 map + sync.rwmutex 反而拖慢性能、增加内存压力。
什么时候该用 sync.Map 而不是 map + sync.RWMutex
别被“并发安全”四个字带偏。实测中，当 key 总数稳定（比如几千个）、写操作每秒超过 50 次时，sync.Map 的吞吐通常比加锁的普通 map 低 2–3 倍。
- 适合
sync.Map的典型场景：HTTP 服务里缓存全局配置、用户权限白名单、指标聚合中固定 key 的计数器 - 不适合的场景：订单状态缓存（频繁更新）、会话 token 存储（定期过期+批量清理）、热点商品库存（高并发写）
- 关键判断点：写操作是否真的「偶发」？如果
Store调用频率接近或超过Load的 1/10，就该切回sync.RWMutex+ 普通map
LoadOrStore 看似方便，但行为和直觉相反
LoadOrStore 不是“有就返回，没就设”，而是“完全不存在才设”。如果之前调过 Delete，这个 key 就进了 deleted 状态，再调 LoadOrStore 仍返回 nil, false —— 它不会复活。
- 想确保 key 存在并拿到值？用
Load+Store组合，自己控制逻辑 - 只用于初始化一次的场景（如单例对象注册），才用
LoadOrStore -
LoadOrStore的value参数不能为nil，否则 panic；而Store允许nil - 高频调用
LoadOrStore且 key 已存在时，比纯Load多一次原子判断，开销略高
Range 是快照，不是遍历，别指望它实时或可控
Range 内部会先锁住整个 sync.Map，复制当前所有有效 entry 到临时 slice，再解锁回调。这意味着：
- 你在回调里删 key、改 value，对后续迭代无效
- 无法提前退出（哪怕你 return false，也只是停止回调，不影响已复制的数据）
- 看不到
Range执行期间新写入或刚删除的条目 - 大容量下易触发 GC：每次
Range都分配新 slice，若每秒调几次，小对象堆积明显
没有 TTL、不能淘汰、不支持 len()，别当它是缓存容器
sync.Map 本质是并发安全的键值容器，不是缓存库。它不提供任何生命周期管理能力：
- 没过期机制：想加 TTL，得自己在 value 里塞
expireAt字段，每次Load后手动检查并Delete - 没大小限制：内存只增不减，长期运行下可能引发 GC 压力与内存碎片
- 不能获取长度：
len()不支持，要统计就得自己维护计数器或用Range（代价高） - 大容量（>10 万条）建议换
bigcache或freecache：前者规避 GC，后者带软过期和 LRU 淘汰
真正难的不是选 sync.Map，而是确认你的读写比例、key 变更节奏和内存容忍度是否匹配它的设计边界——多数人踩坑，是因为把“并发安全”等同于“适合缓存”，而忽略了它连最基础的缓存语义都没实现。
