Go的map扩容期间不保证并发读取安全，runtime会主动panic而非返回脏数据，因惰性搬迁中读写goroutine可能并发修改oldbuckets等共享状态，导致use-after-free；sync.Map通过read/dirty双层结构绕过原生扩容机制，RWMutex保护需确保所有读写均严格加锁。
Go 的 map 在扩容期间**不保证并发读取安全，且 runtime 会主动 panic，而不是返回脏数据或静默失败**。这不是 bug，是明确的设计取舍：宁可崩溃，也不容忍不可预测的内存状态。
为什么 map 扩容时并发读会触发 fatal error
Go 的 map 扩容采用「惰性搬迁（evacuate）」策略：新旧 bucket 并存，搬迁按需触发（比如第一次访问某个旧 bucket 时才搬）。问题在于，mapaccess1（读操作）和 mapassign（写操作）都可能在同一线程中触发对同一旧 bucket 的 evacuate —— 但它们不共享锁、不协调状态。runtime 检测到「一个 goroutine 正在 evacuate，另一个也在 evacuate 或写入同一 bucket」，就立即 throw("concurrent map read and map write")。
关键点：
- 不是因为「读到了旧值」不一致，而是因为 evacuate 过程中会修改
oldbuckets和overflow指针，甚至释放旧内存；并发访问可能导致 use-after-free 或指针错乱 - 哪怕你代码里只读、从不显式写，只要 runtime 自动触发了扩容，且多个 goroutine 碰巧访问了同一个尚未搬迁的 bucket，就会 panic
- panic 发生在
runtime.mapaccess1_fast64或类似函数内，堆栈里通常能看到evacuate字样
sync.Map 为何能绕过扩容一致性问题
sync.Map 根本不复用原生 map 的底层结构，也不参与它的扩容流程。它把读写逻辑拆成两层：read（原子读取的只读快照）和 dirty（带 mu 锁的可写 map）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
这意味着：
-
Load先无锁查read，命中即返回；未命中才加锁查dirty，不会触发任何搬迁 -
Store总是写入dirty；只有当dirty == nil时，才 shallow-copyread初始化它 —— 这个 copy 是一次性操作，不涉及 runtime 的渐进式 evacuate - 没有
oldbuckets和buckets并存状态，自然没有跨桶竞争问题
用 sync.RWMutex 保护原生 map 时，读是否真安全
**是安全的，但前提是所有读写路径都严格包裹在锁内。** RWMutex 不干预 map 内部行为，它只确保「读与读可并行，读与写/写与写互斥」。
容易踩的坑：
- 漏锁：比如遍历
for range m忘记加RWMutex.RLock()，或 defer 前 panic 导致 unlock 被跳过 - 锁粒度不当：在锁内做耗时操作（如 HTTP 请求、文件 IO），导致其他 goroutine 长时间阻塞
- 误以为「只读就不用锁」：即使你没写，runtime 扩容时的 evacuate 是隐式写，它不受你的业务逻辑控制，必须靠锁挡住所有并发访问
map 底层 hmap 结构里哪些字段和扩容直接相关
看 runtime/map.go 中的 hmap 定义，这几个字段决定了扩容行为：
-
B：当前 bucket 数量为2^B；扩容时B加 1（增量扩容）或不变（等量扩容） -
oldbuckets：非 nil 表示正在扩容，指向旧 bucket 数组；读操作会先查这里 -
nevacuate：已搬迁的 bucket 数量；runtime 用它判断是否完成搬迁 -
extra：包含oldoverflow和nextOverflow，用于管理溢出桶迁移
真正危险的不是字段本身，而是这些字段在多 goroutine 下被不同路径（mapaccess1 vs mapassign）同时读写却无同步机制 —— 这正是 panic 的根源。
