负载因子计算公式为 count / 2^B，其中 count 是元素总数，B 是哈希表桶数量的指数，即桶数为 2^B。
负载因子怎么算：count / 2^B 是唯一公式
Go 中的负载因子不是凭感觉或元素总数判断的，而是严格按 count / (1 计算——count 是当前 map 中键值对数量（即 len(m)），B 是 hmap 结构体里的那个 uint8 字段，桶总数恒为 2^B。这个比值一旦 ≥ 6.5，立刻触发扩容。
注意：B 不是桶数，是桶数的指数；初始 make(map[int]int, 10) 可能只设 B=0（1 个 bucket）或 B=1（2 个 bucket），所以插 7 个元素就可能超 6.5，而不是等满 10 个才动。
- 不要用
cap()或预估容量反推 B —— Go 运行时只看当前count和实际B -
B在扩容时只增不减，且每次 +1（翻倍桶数），不会出现 ×1.5 或其他倍率 - 删除元素不会降低
B，也不会触发缩容；count减少只会让负载因子变小，但已分配的桶和B值保留
为什么是 6.5：硬编码阈值，不是经验值
6.5 是写死在 src/runtime/map.go 里的常量 loadFactorThreshold，不是运行时可调参数，也不是编译期宏。它背后对应的是 bucket 槽位利用率与溢出链长度的平衡点：每个 bucket 最多存 8 个 key/value 对，当平均达 6.5 时，已有大量 bucket 接近满载，查找 miss 的 probe 次数（missprobe）开始陡增，性能明显下降。
参考实测数据：负载因子从 6.0 升到 6.5，missprobe 从 6.0 升至 6.5，%overflow 从 15.27% 跳到 20.90%，说明溢出桶比例加速上升。
- 别试图通过改源码绕过这个阈值——改了也没用，相关逻辑（如
overLoadFactor()）直接引用该常量 - Redis 的阈值是 1.0，Java HashMap 是 0.75，Go 敢设 6.5，是因为它的 bucket 天然支持 8 槽 + overflow 链，结构更“厚”
- 这个值没考虑 CPU 缓存行对齐或内存碎片，纯为哈希探查效率服务
溢出桶（overflow bucket）也能触发扩容
除了负载因子，另一个独立触发条件是：noverflow >= (1 ，即溢出桶数量 ≥ 主桶数量。这通常发生在频繁增删、但总元素数不高的场景下——比如反复插入再删除，导致大量空的 overflow bucket 残留，虽 count 很小，loadFactor 远低于 6.5，但 noverflow 累积超限。
此时扩容不是为了降低负载，而是为了整理碎片、回收无效 overflow bucket，把散落的 key/value 重新聚拢进主桶。
-
noverflow是近似统计值（uint16），不精确计数每个 overflow bucket，而是按需递增，避免高频更新开销 - 该条件和负载因子条件是「或」关系，满足任一即扩；两者不互斥，可能同时满足
- 这种扩容仍是翻倍（
B+1），不是“整理式缩容”——Go 从不自动缩容
make 时传的容量只是提示，不影响 B 的初始值逻辑
make(map[int]int, 100) 并不保证初始 B=7（128 个 bucket）。运行时会根据传入容量快速估算一个最小 B，但最终以实际插入时的首次写入路径为准——首次 mapassign 才真正初始化 buckets 并确定 B。
实测中，make(map[int]int, 100) 经常得到 B=6（64 个 bucket），因为 100 ÷ 64 ≈ 1.56，远低于 6.5，没必要一开始就分配更多。
- 想尽量避免早期扩容？可以略放大 make 容量，比如
make(map[int]int, 500)更可能得B=7或B=8 - 但别指望靠 make 参数“锁死”B——后续插入仍可能因负载因子触扩
- 遍历顺序不可预测，也和这个初始 B 无关，而是由 hash seed + 扩容状态共同决定
真正难处理的不是“什么时候扩”，而是“扩的过程中还在读写”。渐进式迁移让 nevacuate 成为并发敏感字段，哪怕你只读 map，只要碰到未迁移的旧桶，就得顺手搬两个 entry；这个细节在压测高并发写场景时最容易暴露竞态。
