sync.Map.Delete在高频删除下更慢，因其底层惰性删除、内存屏障及dirty map提升开销，每秒超50次删除时吞吐反低于sync.RWMutex+map，且大量Delete后紧接Range会触发一次性扩容。
sync.Map.Delete 在高频删除下为什么反而更慢
它不是为“每秒删几百次”设计的。底层惰性删除 + 内存屏障 + dirty map 提升开销，导致写入吞吐比 sync.RWMutex 包裹的原生 map 还低。压测中一旦 Delete 超过 50 次/秒，QPS 往往断崖下跌。
常见错误现象：fatal error: concurrent map writes 一出现，就盲切 sync.Map——结果问题没解，性能还倒退。真正该做的是确认是否真有并发写，还是读写混用漏锁；高频写场景本就不该选 sync.Map。
- 删除不立即释放内存，只原子置
entry.p为 nil，后续Load或Range才可能触发清理 - 大量
Delete后紧接Range，会强制提升 dirty map，引发一次性扩容和复制成本 -
misses累积到阈值后触发 dirty → read 升级，需加mu锁，此时所有写被阻塞
CompareAndDelete 是条件删除的唯一原子姿势
Go 1.20+ 引入的 CompareAndDelete 是唯一能安全实现“值匹配才删”的方法。自己写 Load + if + Delete 是竞态高发区：中间 gap 可能被其他 goroutine 覆盖值。
它返回 bool，失败不 panic，必须显式判断。传入的 old 值必须是同一地址或深度相等（结构体建议传指针）；nil 不能直接比较，得先 Load 判断。
立即学习“go语言免费学习笔记（深入）”；
if v, ok := m.Load("token:123"); ok {
if u, ok := v.(*user); ok && u.Version == 5 {
// ❌ 非原子：u.Version 可能已被改
m.Delete("token:123")
}
}
// ✅ 原子：仅当当前值等于 &user{ID:123, Version:5} 时才删
deleted := m.CompareAndDelete("token:123", &user{ID: 123, Version: 5})
LoadAndDelete 适合“取完就扔”的原子读删
如果你要“读出值、立刻删掉、且不能漏删或重复删”，LoadAndDelete 是正确选择。它在一次原子操作里完成读取 + 标记删除，避免了 Load 和 Delete 分两步带来的竞态窗口。
但它不检查值内容，只认 key 存在与否。适用于 session token 清理、临时任务 ID 回收等场景。注意：返回的 loaded 必须判断，否则可能误把不存在的 key 当成已删。
- 成功时返回
(value, true)，key 确实存在并已被标记删除 - 失败时返回
(nil, false)，key 不存在或已被删过 - 不触发 dirty map 提升，比单纯
Delete更轻量
高频删除场景该换什么
每秒写入（含 Store/Delete）超 50 次，sync.Map 就该被替换。它只适合“创建一次、读一百次、删零次”的缓存类长生命周期键值对。
真实高负载删除，优先考虑：
- 分片锁：
shardedMap或concurrent-map库，按 key hash 分桶，锁粒度降到 1/N -
sync.RWMutex+ 原生map：读多写少但写频仍高于 50qps 时，实测吞吐常优于sync.Map - 定期重建实例：对 key 空间可预测的场景（如定时刷新的配置），用新
sync.Map替换旧实例，避免长期运行的内存残留 - 预分配 +
sync.Pool：若 value 是固定结构体，配合对象池减少 GC 压力，比反复Delete更高效
别忽略 Range 的代价：它会锁全表、复制快照、无法中断。想批量清理过期数据？老实用分片锁 + 定时器 + 带时间戳的 value 字段自己控制生命周期。
