go map扩容由装载因子≥6.5或溢出桶数≥主桶数触发；装载因子=len(m)/(2^b)，6.5是内存与冲突权衡的实测阈值；初始b=0时插7个元素即扩容，b=7时约832个才触发。
Go 的 map 不会在你插入第 N 个元素时固定扩容，而是由两个硬性条件之一触发：装载因子 ≥ 6.5，或溢出桶数 ≥ 主桶数。这两个条件在 runtime 源码里是并列判断的，满足任一即扩。
装载因子怎么算？为什么是 6.5？
装载因子 = len(m) / (2^B)，其中 B 是 hmap 结构体里的字段，表示当前桶数组长度为 2^B。这个比值一旦 ≥ 6.5，立刻触发翻倍扩容（B 加 1）。
6.5 不是拍脑袋定的：每个桶最多存 8 个键值对，但 Go 允许一定比例的溢出链存在；6.5 是在内存占用和哈希冲突之间反复权衡后的实测阈值。它比 Java 的 0.75 看似大很多，是因为 Go 的“桶”本身是固定 8 槽的结构体，不是单个 slot。
- 初始
make(map[int]int, 0)通常 B=0 → 桶数=1 → 插入 7 个元素就可能触发扩容（7/1 = 7 > 6.5） -
make(map[int]int, 100)可能设 B=7 → 桶数=128 → 要插满约 832 个才触发（128×6.5） - 注意：
make的容量参数只是 hint，不保证初始 B 值，实际由运行时按需取最近 2 的幂向上对齐
溢出桶过多也会触发扩容，但条件有分段
溢出桶（overflow bucket）是解决哈希冲突用的链表节点。当主桶装不下，新 key 就被链到溢出桶里。hmap 里用 noverflow 字段粗略统计其数量。
触发条件不是简单“溢出桶数 ≥ 主桶数”，而是：
- 当
Bnoverflow ≥ 2^B（即溢出桶数 ≥ 主桶数） - 当
B≥ 15 时：noverflow≥ 2^15（固定为 32768，不再随主桶增长）
这个设计是为了防止超大 map 因溢出桶持续增长而失控。一旦达到阈值，即使装载因子还很低，也会强制扩容——本质是「冲突太密集，必须重哈希摊薄」。
扩容不是一次性搬完，oldbuckets 和 nevacuate 是关键
Go 的 map 扩容是渐进式（incremental）的，不会卡住整个 goroutine。核心靠三个字段协作：
-
oldbuckets：指向旧桶数组，只读，用于搬迁中查旧数据 -
nevacuate：记录已搬迁完成的旧桶编号（从 0 开始），未达此编号的旧桶仍可读写 -
flags中的hashWriting和sameSizeGrow位控制并发安全与迁移状态
每次 mapassign（赋值）、mapaccess（读取）甚至 range 遍历时，都会顺手搬一个旧桶。这意味着：一次插入可能触发扩容，但真正 rehash 是分散在后续多次操作里的。
你无法通过 len(m) 或 cap 判断是否正在扩容——唯一可靠方式是观察 runtime.hmap 的 oldbuckets != nil。
map 不会缩容，删再多也不会回收桶内存
这是明确的设计选择，不是 bug。删除元素只会清空键值、置 tophash 为 0，但桶结构（包括溢出桶链）全部保留。
原因很实在：
- 缩容需要全量 rehash，开销不比扩容小
- 高频增删场景下，缩容再扩容容易形成抖动
- 多数服务生命周期内 map 只增不减，缩容收益低
如果你真需要释放内存（比如临时构造百万级 map 处理完就丢），唯一办法是新建一个 map，把剩余键值对 copy 过去——但要注意这会重置 hash0，遍历顺序必然改变。
真正容易被忽略的是：即使你用 make(map[int]int, 1e6) 预分配，只要后续删了 99% 的元素，底层桶数组依然占着原来的空间，GC 也收不走。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
