Go map扩容时并发读会panic，因runtime检测到读操作触发惰性搬迁（evacuate）与写操作竞争同一旧桶，导致状态不一致；为避免不可预测崩溃，直接终止程序而非返回脏数据。
map 扩容时为什么并发读会 panic，而不是返回脏数据
go 运行时对 map 并发读写的处理不是“尽力而为”，而是主动崩溃——只要检测到一个 goroutine 在写、另一个在读（哪怕读的是旧桶），就会立即触发 fatal error: concurrent map read and map write。这不是 bug，是设计选择：因为扩容中 oldbuckets 和 buckets 并存，且搬迁是惰性的、按需触发的，底层内存状态随时可能被重排或释放。runtime 不试图保证“读到旧值也算一致”，而是彻底禁止这种组合，避免不可预测的数据损坏或 segfault。
sync.Map 的读路径如何绕过扩容一致性问题
sync.Map 本质是把读写逻辑从单个哈希表拆成两层：read（原子加载的只读快照）和 dirty（带锁的可写副本）。它不参与原生 map 的扩容流程，也就完全规避了 oldbuckets 搬迁带来的可见性难题：
-
Load先查read，命中即返回，无锁、无搬迁开销 - 未命中时加
mu锁，再查dirty；若仍无，则记录一次miss，但不会去触发任何 rehash 或迁移 -
Store总是写入dirty，只有当dirty == nil时才 shallow-copyread初始化它，不涉及原生 map 的evacuate逻辑
手动用 sync.RWMutex 保护原生 map 时，扩容期间读是否安全
是安全的，但前提是所有读写操作都严格包裹在锁内。RWMutex 本身不干预 map 内部行为，它只是确保「任意时刻最多一个写 goroutine，或任意数量读 goroutine」访问 map。扩容由 runtime 自动触发，只要没发生并发读写（即没有锁外读+锁内写共存），就不会 panic：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 写操作（
mapassign）全程持写锁，包括触发扩容、分配新桶、搬运旧 bucket 的全部过程 - 读操作（
mapaccess1）持读锁，此时写锁被占用，不可能有其他 goroutine 同时修改底层结构 - 关键点：
for range m必须在读锁保护下进行，否则遍历中途可能被写操作打断，导致 panic
为什么不能靠 “只读不写” 就认为 map 扩容期间天然线程安全
这是最隐蔽的坑。即使你代码里没显式写 map，只要 runtime 因负载因子 ≥6.5 触发了扩容，且 nevacuate 进度滞后（比如 map 长期只读），那么第一次对该旧 bucket 的读操作就会顺手执行 evacuate —— 此时若另一个 goroutine 正在写别的 key、且恰好也命中同一旧 bucket，就构成「读中搬迁 + 写中搬迁」的竞争，直接 panic。换句话说：扩容的惰性搬迁逻辑本身就引入了隐式写行为，而这个写不经过你的锁控制。
