sync.Map 仅在读远多于写、各 goroutine 操作不同 key、key 动态增长且少删除等特定场景下高效；否则 sync.RWMutex + map 更可控。
不用加锁也能并发读写，但别默认用 sync.Map 替代所有 map —— 它只在特定场景下真正高效。
什么时候该用 sync.Map 而不是 sync.RWMutex + 普通 map
核心判断依据是读写比例和 key 分布模式。如果你的缓存满足以下任意一条，sync.Map 才值得考虑：
- 读操作远多于写操作（比如 100:1 或更高），且写入不频繁
- 不同 goroutine 基本操作不同 key（例如每个请求处理自己的 session ID）
- key 数量动态增长、很少删除，也不需要遍历全部 key
- 你不需要 TTL 过期、LRU 淘汰等自定义逻辑
反例：高频更新同一组配置项、需要定时清理过期项、或经常调用 Range 遍历全量数据 —— 这时 sync.RWMutex + map 更可控、更易维护。
sync.Map 的基本操作和常见误用
sync.Map 不支持直接索引访问（比如 m["key"]），所有操作必须走方法调用。容易踩的坑包括：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
Load返回(interface{}, bool)，类型断言失败会 panic，务必检查ok -
Store总是覆盖，没有“仅当不存在才写入”的原子语义 —— 要这个行为得用LoadOrStore -
Range是快照遍历，期间新增/删除不影响当前迭代，但无法保证顺序，也不反映实时状态 - 不能像普通 map 那样用
len()获取长度 ——sync.Map没提供 size 方法，需自己计数或遍历统计
示例片段：
var cache sync.Map
cache.Store("user:1001", &User{Name: "Alice"})
if val, ok := cache.Load("user:1001"); ok {
u := val.(*User) // 注意类型断言
fmt.Println(u.Name)
}
// 安全写入：已存在则返回旧值，否则存入
actual, loaded := cache.LoadOrStore("config:timeout", 30)
// loaded == true 表示 key 已存在，actual 是原值
为什么 sync.Map 在写多场景下反而更慢
它的内部结构包含一个只读 read map 和一个带锁的 dirty map。读操作优先走 read（无锁），但一旦发生写操作，就会触发 dirty map 的提升和复制 —— 这个过程是 O(n) 的。
- 频繁写入同一个 key：每次
Store都可能触发dirty提升，带来额外开销 - 大量写后紧跟
Range：Range会先尝试读read，再 fallback 到dirty，若两者都不空，实际遍历两次 - 没有批量操作接口：无法像普通 map 那样一次性清空或替换整个结构
换句话说：sync.Map 的优化本质是“用空间换读性能”，代价是写路径变重、控制粒度变粗。
缓存需要过期？sync.Map 本身不支持，得自己补
sync.Map 不管生命周期，所有键值对永远存在，除非显式 Delete。如果你需要 TTL 缓存，必须额外处理：
- 值类型里嵌入过期时间戳，每次
Load后手动判断是否过期 - 启动后台 goroutine 定期扫描并
Delete过期项（注意Range不保证原子性，可能漏删或重复删） - 更稳妥的做法是放弃
sync.Map，改用sync.RWMutex+ map 封装，把过期逻辑写进Get/Set方法里
真正复杂的缓存需求（比如带淘汰策略、命中统计、刷新机制），sync.Map 只是起点，不是终点。它省掉的是锁，不是设计成本。
