sync.map 的 read 字段是被 atomic.value 包裹的 readonly 结构体，支持无锁原子替换但不支持直接增删键；其内部 map 可变仅因 entry 指针可更新，增删限制源于上层逻辑而非内存模型。
sync.Map 的 read 字段本质是 atomic.Value
read 不是普通 map，而是被 atomic.Value 包裹的 readOnly 结构体。这意味着：它不能直接增删键，但可以原子地整体替换——比如用新构造的 readOnly 实例覆盖旧值。这种替换完全无锁，靠的是 atomic.Value.Store 和 atomic.Value.Load 的底层内存屏障与对齐保证。
常见误解是认为 read 里存的是“不可变 map”，其实它内部的 m map[interface{}]*entry 是可变的（值指针可更新），只是整个 m 字典本身不支持增删操作；真正禁止增删的是上层逻辑，不是内存模型。
read 到 dirty 的升级就是一次原子替换
当 misses ≥ len(dirty) 时，sync.Map 会把当前 dirty 拷贝成新的 readOnly，然后调用 read.Store(newReadOnly) 原子替换。这个动作不会阻塞正在读 read 的 goroutine，因为 atomic.Value 的 Store 是线性一致的（linearizable）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
需要注意：
- 替换前，dirty 会被置为 nil，后续写入会触发重建
- 被标记为 expunged 的 entry（即逻辑删除的键）不会进入新 read，相当于自然清理
- 此过程不涉及任何对 read.m 的遍历加锁，纯靠原子指针切换
为什么不能直接对 read.m 做原子写入
read.m 是普通 map，Go 的 map 本身不是并发安全的，也不能对其做原子赋值（map 类型不可寻址，无法取地址传给 atomic.StorePointer）。所以 sync.Map 只能退而求其次：把整个 readOnly 结构体（含 m 字段）封装后，用 atomic.Value 托管。
这就带来两个实际约束：
- 每次想“更新 read 中某个键的值”，必须走 entry.p 上的 atomic.StorePointer，而不是改 read.m[key]
- 想“批量更新多个键”，没有捷径——只能逐个调用 LoadOrStore 或等下次 dirty → read 升级
- 如果你绕过 sync.Map 方法、手动解包 read 并修改其 m，会导致数据竞争和 panic
原子替换的边界很窄，别误当成通用原子 map
sync.Map 的原子性只体现在两个层面：一是 read 整体替换，二是单个 entry.p 的指针读写。它**不提供**对任意键值对的原子 CAS、不支持原子批量操作、也不保证多次 Load/Store 的事务性。
比如：
- LoadAndDelete 看似原子，实则内部可能先读 read、再锁 dirty，中间有窗口期
- 两次 Load 之间，值可能已被其他 goroutine 改写，且无版本号或序列号可供校验
- 若你需要强一致性语义（如 compare-and-swap on value），应考虑 sync/atomic + 自定义结构，而非依赖 sync.Map
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
