sync.map 不适合高频配置读取，因其 load 需原子操作和指针跳转，比 rwmutex 读慢 2–3 倍；不支持可靠遍历，store 可能触发 dirty 提升引发毛刺；纯读多场景应选 rwmutex + 带版本号 map。
sync.Map 不是通用并发 map 替代品，它只在“读多写少 + key 基本不重用”场景下比 map+sync.RWMutex 快；盲目替换反而拖慢性能。
sync.Map 的 Load 为什么有时要加锁？
Load 操作不是无条件无锁的。它先查 read（原子读），命中就直接返回；没命中才触发锁路径：加 mu 锁，再查 dirty。这个“没命中”就是 misses 计数器的来源。
- 只要 key 从没被 Store 过，或刚被 Delete 后又 Load，必然走锁路径
-
read.m是快照，不会自动同步dirty新增的 key；只有当misses >= len(dirty)时，才会把dirty整体提升为新read - 所以高频新增 key 的场景下，Load 大部分时间都在锁里排队
Store(key, value) 会触发 read 提升吗？
不会。Store 只往 dirty 写（加锁），并设置 read.amended = true。它不直接修改 read.m，也不触发提升逻辑。
- 提升由 Load 失败次数驱动，不是由写操作驱动
- 如果只写不读，
dirty会越积越多，read始终 stale，后续所有 Load 都得加锁 - 极端情况：持续 Store 不同 key → 所有 Load 都锁 → 性能不如
sync.RWMutex包裹的普通 map
为什么 sync.Map 没有 Len() 方法？
因为长度无法原子获取。它的 read.m 和 dirty 是两个独立 map，且 read 可能包含已被标记为 expunged（逻辑删除但未清理）的 entry。
-
Range是唯一安全遍历方式，但它只反映调用瞬间的状态，不保证原子性 - 若真需要长度，必须自己用
sync.Mutex包裹一个计数器，在每次Store/Delete时手动维护 - 试图靠
Range累加来模拟Len()会漏掉正在被 Delete 的 entry，或重复计算expunged条目
什么时候该放弃 sync.Map 改用 map+RWMutex？
当出现以下任一情况时，sync.Map 的优势消失，甚至成为瓶颈：
- 写操作频繁（如每秒数百次 Store/Delete），尤其 key 不固定
- 需要可靠长度、遍历顺序保证、或支持 delete-all 操作
- key 有大量重复写入（同一 key 被反复 Store），导致
entry.p频繁 CAS，引发缓存行争用 - goroutine 数远超 CPU 核心数，锁竞争本身已不严重，
sync.RWMutex的读共享开销可接受
最易被忽略的点：sync.Map 的“无锁读”只对稳定热点 key 有效；一旦业务模式变化（比如缓存预热结束、流量突变），它的性能曲线可能陡降，而 map+sync.RWMutex 表现更可预测。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
