Go map溢出桶是独立bmap实例而非链表节点，每个含tophash[8]、8组key/value及overflow指针；固定存8对因与tophash绑定实现快速过滤，满则挂新桶链，非单元素链式分配。
Go map 的溢出桶（overflow bucket）不是链表节点，而是独立的 bmap 实例
很多人误以为 Go 的溢出桶是传统链表里的「节点」，实际它是一个完整的新桶（bmap），结构和主桶完全一致：含 tophash[8]、8 组连续 key/value、一个 overflow *bmap 指针。它不存单个键值对，而是又一个能装 8 对的容器。
这种设计避免了链表遍历开销（无需 malloc 单个节点 + 指针跳转），也减少 cache miss —— 每次访问都是连续内存块。
-
overflow指针只在当前桶满（8 个键值对）时才被分配并指向新桶 - 新溢出桶由
hmap.extra统一管理，不是堆上零散分配，而是批量预分配或按需创建 - 查找 key 时，会顺着
bucket → overflow → overflow → …链式扫描，但每跳一次都是整块内存读取，非单元素遍历
为什么每个桶固定存 8 个键值对？tophash 是关键加速器
8 这个数字不是拍脑袋定的，它和 tophash[8] 紧密绑定：每个桶预存 8 个哈希值高 8 位，用于快速过滤。
查找时，先比对目标 key 的哈希高 8 位是否匹配 tophash 数组中某一项；只有匹配项才继续比对完整 key。这大幅减少字符串或结构体 key 的完整比较次数。
- 若桶内 key 数 tophash 中未用位置填
emptyRest或evacuatedX等标记，表示后续无有效 key - 超过 8 个 key 时，必须走溢出桶 —— 因为
tophash长度写死为 8，无法扩容 - 这个设计让「平均查找成本」保持在常数级，即使冲突多，也只是多扫一两个溢出桶，而非遍历长链表
mapassign 插入时如何决定是否新建溢出桶？
插入逻辑在 runtime/map.go 的 mapassign 函数里。是否新建溢出桶，取决于当前桶（含所有已挂载的溢出桶）是否还有空位，而不是只看主桶。
它会从主桶开始，逐个检查每个桶的 tophash，找第一个 empty 或 deleted 槽位；如果一路扫完所有已存在的桶都无空位，才会调用 growWork 或直接新建一个溢出桶追加到链尾。
- 新建溢出桶前会检查负载因子（
count > 6.5 * 2^B），触发扩容优先于新建溢出桶 - 溢出桶本身也遵循「满 8 就挂下一个」规则，所以可能形成很长的桶链，但 runtime 会在扩容时逐步搬迁，避免链过长
- 注意：
mapiterinit遍历时也会按桶链顺序访问，所以大量溢出桶会拖慢迭代，这不是 bug，是设计权衡
并发写 map 崩溃和溢出桶无关，但扩容期间的 oldbuckets 会影响溢出桶可见性
panic: fatal error: concurrent map writes 的根本原因是写操作未加锁，和有没有溢出桶无关。但扩容过程会让问题更隐蔽。
扩容时，hmap.oldbuckets 持有旧桶数组，而新桶数组（buckets）刚开始为空。此时写操作会先查 oldbuckets，再迁移到 buckets。如果某个 key 原本落在带溢出桶的旧桶里，迁移逻辑只搬该 key 所在的主桶和**直接挂载的溢出桶**，不会递归搬整个桶链 —— 这意味着部分溢出桶内容可能暂时「消失」或重复出现。
- 这不是数据丢失，而是渐进式搬迁的中间态；但若此时并发读写，就可能看到不一致状态
- 因此，哪怕你手动控制写入节奏，只要没用
sync.RWMutex或sync.Map，溢出桶的存在只会放大竞态窗口，不会消除它 - 真正要解决的，从来不是「怎么让溢出桶线程安全」，而是「别让 map 被并发写」
Go map 的溢出机制看着像链表，实则是「桶链」——每一环都是一整块内存。理解这点，才能明白为什么它既不像 Java HashMap 那样频繁 rehash，也不像纯拉链法那样易受长链拖累。最易忽略的是：溢出桶数量本身是性能信号，如果 hmap.noverflow 持续增长且不伴随扩容，说明你的 key 分布极不均匀，该检查哈希函数或 key 设计了。
