负载因子 = len(m) / (2^B × 8)，其中 B 是 map 的桶数组指数，2^B 为桶数量，每桶最多 8 个键值对，反映实际装载密度。
负载因子怎么算：不是 len(m) / cap(m)
Go 的 map 没有 cap 概念，所谓“容量”只是 make(map[K]V, hint) 传入的提示值，最终桶数量由运行时根据 hint 推导出的 B 决定（即桶数 = 1 ）。负载因子真实计算公式是：<br> <code>loadFactor = len(m) / (1 <br>其中 <code>len(m) 是当前键值对总数，h.B 是当前主桶数组的指数（h 是底层 hmap 结构），不是你传给 make 的数字，也不是 map 占用的内存字节数。
6.5 是硬编码阈值，不随版本或场景变化
这个值写死在 src/runtime/map.go 的 loadFactorThreshold 常量里，截至 2026 年所有稳定版 Go（1.18–1.26）都未改动。它不是经验值或可调参数——你无法通过编译选项、环境变量或 runtime 函数修改它。
- 触发扩容 ≠ 必须刚好等于 6.5；只要
len(m) >= (1 就会标记为需扩容 - 注意是「大于等于」，且比较发生在每次写操作（
mapassign）末尾，不是惰性检查 - 即使你刚 delete 掉一半元素，只要之前扩容过且迁移未完成，
h.B仍维持高位，此时负载因子可能远低于 6.5，但也不会缩容
溢出桶过多也会触发扩容，但条件更隐蔽
当哈希冲突集中（比如大量 key 的低 B 位相同），系统会不断分配溢出桶（overflow bucket），这时即使总元素不多，也可能触发扩容。判断逻辑分两档：
- 若
h.B ：当 <code>h.noverflow > (1 时触发 - 若
h.B >= 15：当h.noverflow > (1 （即 32768）时触发 - 这个
h.noverflow是运行时累计值，不随 delete 清零，只增不减
这种场景在构造恶意 key 或处理特定格式 ID（如时间戳截断后低位全零）时容易复现，但日常代码中较少被察觉。
为什么不能靠预估 B 来避免频繁扩容
你传 make(map[int]int, 1000)，Go 可能设 B=10（1024 桶），但也可能设 B=0（1 桶）——取决于内部启发式算法和当前内存状态。实测中，小 hint 值（B=0 或 B=1，意味着插 7~14 个元素就可能触发首次翻倍扩容。
- 真正可控的只有「下限」：hint 越大，B 起始值越可能偏高，但不保证
- 如果你明确知道后续会塞进 5000 个元素，直接传
make(map[int]int, 5000)比循环 insert 安全得多 - 但即便如此，只要插入过程中某次写导致
len(m) / (1= 6.5，该次操作就会启动扩容流程
最易被忽略的一点：扩容是渐进式的，h.oldbuckets 和迁移进度 h.nevacuate 会长期共存于内存中，直到所有 bucket 都被访问过一次——这意味着压测时看到 RSS 持续上涨、GC mark 阶段变长，很可能就是卡在迁移途中。
