sync.map 适合读多写少且键生命周期不一的场景，如http上下文缓存；写操作超20%时应优先用sync.rwmutex+map，因其写路径更轻量、无双层结构开销。
sync.Map 适合什么场景
它不是通用并发 map 的替代品，只在「读多写少 + 键生命周期不一」时有优势。比如 HTTP 请求上下文缓存、连接池元信息、临时 token 映射表——这些场景里，大部分 key 是只读的，新增或删除极少。
常见错误现象：sync.Map.LoadOrStore 被当成 map[key] = value 随意调用，结果发现写放大严重，GC 压力上升；
使用建议：
- 写操作占比超过 20%，优先考虑
sync.RWMutex+ 普通map - key 类型必须支持相等比较（不能是 slice、func、map）
- 不支持遍历顺序保证，
Range是快照式遍历，期间增删不影响当前迭代
分段锁（sharded map）怎么写才不翻车
手动分段本质是把一个大锁拆成 N 个小锁，降低冲突概率，但分段数不是越多越好。
性能影响点：
- 分段数太少（如 4），热点 key 仍会挤在同个桶里，锁竞争没缓解
- 分段数太多（如 1024），内存开销和哈希计算成本反超收益，尤其小数据量时
- 推荐从 32 或 64 开始压测，根据 P99 写延迟调整
实操注意：
hash(key) & (shardCount - 1) 要求 shardCount 是 2 的幂；否则得用取模，性能掉一截；容易踩的坑：
shard[i].mu.Lock() 后忘记 defer shard[i].mu.Unlock()，或者在 Range 中持有锁太久，阻塞其他 goroutine。为什么 sync.Map 在写密集时比 mutex map 还慢
因为 sync.Map 内部用了 read map + dirty map 双层结构，写操作要先尝试原子更新 read map，失败再升级到 dirty map，还要做 dirty map 提升逻辑——这一套路径远比 sync.RWMutex 直接加锁写普通 map 重。
典型错误现象：
- 用
sync.Map存 session，但每秒大量用户登录/登出，导致 dirty map 频繁重建 - 误以为
sync.Map“天生高并发”，没测就上线，结果 QPS 上不去，CPU 却跑满
参数差异：
-
sync.RWMutex + map：读写都需锁，但无额外结构开销 -
sync.Map：读几乎无锁，写路径分支多、内存分配多、逃逸更明显
压测时该看哪几个指标
别只盯吞吐（QPS），sync.Map 和分段锁的真实差距藏在尾部延迟和 GC 频率里。
重点关注：
-
go tool pprof中的runtime.mallocgc调用次数 ——sync.Map的 dirty map 提升会触发 map 扩容和复制，产生大量小对象 - P99 写延迟是否稳定，还是随运行时间持续升高（说明缓存失效或锁竞争恶化）
- Goroutine 数量是否缓慢上涨（可能锁未释放或
Range长时间阻塞）
一个简单验证命令：
go test -bench=. -benchmem -cpuprofile=cpu.out，然后用 go tool pprof cpu.out 看热点函数归属。立即学习“go语言免费学习笔记（深入）”；
实际选型时，最常被忽略的是「key 生命周期」和「写操作语义」：如果写操作需要 CAS（比如 CompareAndSwap），sync.Map 不支持，分段锁也得自己实现；而如果只是简单覆盖，那往往 sync.RWMutex + map 最省心、最可控。
