是，提升 dirty 时必须执行 mu.Lock()，因为 dirtyPromote 涉及遍历非并发安全的 dirty map、构造新 readOnly、更新 read、清空 dirty 和重置 misses 等多步耦合操作，必须由 mutex 保证原子性与一致性。
sync.Map 提升 dirty 时会触发 mu.Lock() 吗
会，而且是必须的。提升 dirty 到 read 的操作（即 misses 达到阈值后执行的 dirtypromote）全程在 mu 保护下进行，包括清空 dirty、重置 misses、将 dirty 赋值给 read。
这个锁不是“可选优化”，而是数据一致性强制要求：必须确保 dirty 复制到 read 的过程不被并发写入干扰，否则可能漏掉新 key 或重复迁移已删除 entry。
-
dirty非 nil 时，所有新增 key 都直接写入dirty；若提升过程中有并发写入，dirty可能边复制边被修改 -
amended字段依赖read和dirty的状态同步，竞态下会导致后续写入误判为“仅需更新read”而跳过dirty - 提升后
dirty被置为nil，下一次写入需重建 —— 这个切换点必须原子
为什么 dirtyPromote 不用 atomic 而用 mutex
atomic.Value 只能安全替换整个只读结构（如 readOnly），但 dirtyPromote 涉及多个动作耦合：遍历 dirty、过滤已删除 entry、构造新 readOnly、更新 read、清空 dirty、重置 misses。这些无法用单次 CAS 完成。
尤其注意：遍历 dirty 本身不是原子操作，其 map 是普通 Go map，必须加锁防止迭代中被并发修改（Go map 并发读写 panic）。
-
read是atomic.Value，所以赋新值可用Store()，但前提是新值已构造完毕 -
dirty是普通 map，没有并发安全保证，任何读/写都必须持mu - 即使想用
atomic.Pointer（Go 1.19+），也无法绕过遍历过程中的锁 —— 因为 map 底层 hash table 结构不可并发迭代
misses 阈值触发提升的真实竞争场景
典型高写低读场景下，misses 累积很快，但提升并非“每 N 次未命中就立刻执行”，而是由**下一个需要访问 dirty 的 goroutine 触发**。这意味着：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 多个 goroutine 同时发现
misses >= len(dirty)，都会尝试进入mu.Lock()，但只有一个能成功执行提升，其余阻塞或重试 - 提升完成后，新
read立即生效，后续读操作全部走无锁路径 —— 所以锁持有时间虽短，却是性能拐点 - 如果
dirty很大（比如 10w+ key），遍历过滤耗时明显，此时mu持有时间变长，其他写操作排队等待，表现为写吞吐骤降
这不是设计缺陷，而是空间换时间的显性代价：你省掉了日常读的锁，但把锁成本集中到了脏数据“结算”时刻。
如何避免提升时的锁争用尖峰
没有银弹，但可缓解。核心思路是减少 dirty 规模和提升频次：
- 尽量让热 key 早进
read：首次写入后尽快触发一次读（哪怕 dummy read），避免它长期滞留dirty - 避免高频写入唯一 key：比如用
Store("counter", x)频繁更新计数器，这会让该 key 始终在dirty中，且每次写都增加misses - 不要手动清空
sync.Map：调用Range+Delete会大量写入dirty，触发密集提升；真要清空，直接新建sync.Map{} - 监控
misses增长速率：可通过反射或封装 wrapper 记录，若发现misses在几秒内暴涨，说明read命中率崩了，该检查 key 分布或读写比例
真正容易被忽略的是：提升不是定时任务，它完全由读操作“被动驱动”。一个长期无人读的 sync.Map，哪怕写了上万次，dirty 也永远不会提升 —— 直到第一个 Load 落空并撞上阈值。
