溢出桶是独立的bmap结构体，非传统链表节点；每个溢出桶可存8个键值对，通过overflow指针构成桶链，查找时依赖tophash高8位快速剪枝，不遍历全部溢出桶。
溢出桶（overflow bucket）不是链表节点，而是独立的 bmap 实例
很多人看到“溢出桶链表”就默认它是传统链表结构，误以为每个溢出桶里存一个键值对、靠指针串起来。实际不是：overflow 字段指向的是另一个完整的 bmap 结构体——和主桶一样，它也包含 tophash[8]、8 个 key、8 个 value 和一个自己的 overflow 指针。这意味着：
- 每个溢出桶仍能存最多 8 个键值对，不是“一个节点一个元素”
- 溢出桶之间构成的是“桶链”，不是“键值对链表”
- overflow 指针不参与哈希计算，只用于线性遍历定位
查找时不会遍历全部溢出桶，靠 tophash 高 8 位快速剪枝
Go map 查找某个 key 时，并非从头到尾拉通所有溢出桶比对 key。它先算出该 key 的哈希值，取高 8 位（tophash），然后只在当前桶及其溢出桶的 tophash 数组中逐个比对这个值。一旦某 slot 的 tophash 不匹配，就跳过整个 slot 对应的 key/value —— 这省掉了大量无效的 key 内容比较。
- 如果 key 的 tophash 值在某个溢出桶里完全没出现，后续溢出桶直接不进
- 只有 tophash 匹配的 slot 才会触发完整 key 比较（用 == 或 reflect.DeepEqual）
- 这就是为什么 map 在冲突较多时仍能保持接近 O(1) 的平均查找性能
插入新键值对时，溢出桶按需分配，不预建、不复用
当一个桶已满（8 个键值对），再插入新 key 时，运行时会调用 newoverflow 分配一个新的 bmap 作为溢出桶，并链接到当前桶的 overflow 字段。关键点在于：
- 溢出桶内存由 mallocgc 分配，不是从预分配池里取
- 不会复用已释放的溢出桶（没有回收机制）
- 多次扩容后，溢出桶可能形成很长的链，但 Go 不会自动整理或合并它们
- 若负载因子过高（比如 > 6.5），触发整体扩容，此时所有键值对重哈希，溢出桶链被彻底丢弃
遍历时顺序不可靠，且不保证主桶与溢出桶的访问先后
for k, v := range m 的遍历顺序是随机的，这不只是因为哈希扰动，更深层原因是：
- 遍历器先随机选一个起始桶索引，再按数组顺序扫 hmap.buckets
- 对每个非空桶，它先遍历本桶的 8 个 slot，再顺着 overflow 链依次访问每个溢出桶
- 但溢出桶本身是堆上分配的，地址不连续，遍历器只是按指针链顺序走，不排序、不回溯
- 所以即使两次 map 容量、内容完全相同，溢出桶的分配地址不同，遍历顺序也可能不同
溢出桶机制看起来像链表，但它真正影响性能的环节不在指针跳转，而在 tophash 剪枝是否有效、以及溢出链是否过长导致缓存局部性变差——后者在大量写入又极少删除的场景下容易被忽略。
