Go map触发扩容的条件是负载因子＞6.5（count＞2^B×6.5）或溢出桶数noverflow≥2^15（B≥15时）或≥2^B（B＜15时），满足其一即启动渐进式迁移，分翻倍扩容与等量扩容两种模式。
Go map 什么时候触发扩容？
不是“写满就扩”，而是由两个独立条件共同决定：loadFactor > 6.5 或 noverflow 过高。前者是主流路径，后者是兜底保护。
负载因子计算方式是 count / (1 ，即当前元素数除以桶数量（2^B）。一旦超过 6.5，立刻准备扩容；但注意：这个判断发生在每次 <code>mapassign（赋值）前，不是插入后才检查。
-
B=4时桶数为 16，最多存约16 × 6.5 = 104个键值对，第 105 次写入会触发扩容 - 若大量 key 哈希冲突严重，导致溢出桶（
overflow）堆积，即使count很小也会扩——比如B 时 <code>noverflow >= 2^15就强制扩 - 扩容不立即搬数据，只是设置
oldbuckets和nevacuate = 0，进入渐进式迁移状态
增量扩容 vs 等量扩容：怎么选？
Go 不只翻倍扩容。是否翻倍，取决于当前冲突压力：
- 常规情况走
double the buckets：新桶数 =1 ，即 B 加 1，桶数翻倍 - 当
oldbuckets != nil且h.flags & sameSizeGrow != 0，说明正在等量扩容——新桶数不变，只重建 overflow 链表，用于缓解溢出桶过多问题 - 等量扩容不会改变
B，但会清空旧oldbuckets、重置nevacuate，并把所有溢出桶归还给extra.nextOverflow池 - 两种扩容都设置
h.oldbuckets = h.buckets，但等量扩容后h.buckets指向的是新分配的、结构相同的新桶数组
渐进式迁移为什么不会卡顿？
因为迁移不是一口气干完，而是“随用随搬”：每次读写操作，只顺手搬一个旧桶（或其 overflow 链），由 nevacuate 记录进度。
立即学习“go语言免费学习笔记（深入）”；
- 读操作（
mapaccess1）会先查oldbuckets，命中则触发该桶迁移，再查新桶 - 写操作（
mapassign）同理，插入前确保目标桶已就位，必要时完成迁移 -
nevacuate是 uintptr 类型，记录下一个待迁移的旧桶索引（0 到1），迁完后递增 - 迭代器（
range）会同时遍历oldbuckets和buckets，跳过已迁走的旧桶，保证不漏不重
容易被忽略的关键细节
真正影响性能的不是扩容本身，而是你没意识到的隐式行为：
- map 创建时若指定
hint（如make(map[int]int, 100)），Go 会预估 B 值，但不保证桶数精确匹配——它按2^B ≥ hint向上取整，hint=100实际分配 B=7（128 桶），而非 B=6（64 桶） -
hash0是 per-map 随机种子，导致同一组 key 在不同 map 中哈希分布完全不同——这既是防攻击设计，也意味着你不能依赖“两次遍历顺序一致”做测试断言 - 并发写 map 直接 panic，但并发读+写也可能 panic，因为
hashWritingflag 检测的是写操作期间是否有其他 goroutine 正在读（通过iteratorflag） - 迁移未完成时，
len()返回的是真实count，但内存占用是新旧桶之和——旧桶不会立即释放，直到nevacuate == oldbucket count且无 goroutine 在用oldbuckets
