Go map通过hash & (1
哈希值怎么被截断成桶索引？
Go 的 map 不会直接用完整哈希值做数组下标，而是只取低 B 位——这个 B 是当前 hmap.B 字段的值，决定了桶数组长度为 2^B。定位桶的公式就是 hash & (1，本质是位与代替取模，避免除法开销。
常见错误是误以为“哈希值后几位”是固定位置（比如总取最后 5 位），其实它完全取决于当前 B 值。扩容后 B 加 1，桶数翻倍，同一个 key 的桶索引可能变也可能不变——只看新 B 下低几位是否相同。
- 如果
B=4，桶数是 16，索引 =hash & 0b1111 - 如果
B=5，桶数是 32，索引 =hash & 0b11111 - key 的哈希值在单次运行中恒定，但桶索引随
B动态变化
tophash 高 8 位的作用到底是什么？
tophash 存的是哈希值的高 8 位（即最高字节），不是整个哈希值，也不是低 8 位。它被写入桶内每个槽位的 tophash 数组，用于快速预筛：查找时先比 tophash，不匹配就跳过整个槽位，避免昂贵的键比较。
这个设计直接受限于桶大小（固定 8 槽）。如果高 8 位都撞了，才需要逐个比 key 本身；而绝大多数情况下，tophash 就能拦掉 7/8 的槽位。
- 不存全哈希值 → 节省内存（每个槽只占 1 字节）
- 不存低 8 位 → 低比特容易因哈希函数扰动而集中，区分度差
- 高 8 位冲突概率 ≈ 1/256，足够支撑 O(1) 平均查找
为什么查找要遍历 overflow 桶链表？
当目标 key 定位到某个主桶（primary bucket），但该桶的 8 个槽位里没找到匹配项时，map 会顺着 overflow 指针一路往下查，直到遇到 nil 或找到 key。这不是“链表遍历”，而是“桶链遍历”——每个 overflow 桶仍是满容量（8 槽）的独立结构。
容易踩的坑是认为 overflow 是“链表节点”，实际它是另一个完整桶，只是逻辑上挂载在主桶之后。所以查找路径是：主桶 → 第一个 overflow 桶 → 第二个 overflow 桶 → ……
- overflow 桶数量过多会显著拖慢查找，触发等量扩容
- 删除操作不会自动回收 overflow 桶，只清空槽位标记
- 遍历时仍需检查每个 overflow 桶的
tophash，不能跳过
hash0 种子值对查找过程有影响吗？
没有直接影响。hash0 是哈希计算的初始种子，在程序启动时随机生成，参与哈希函数内部的乘加混合运算，但它不参与桶定位或 tophash 提取。它的作用纯粹是防攻击：防止外部构造恶意 key 导致大量哈希碰撞，从而瘫痪 map 性能。
也就是说，同一份代码、同一组 key，在两次不同进程运行中，hash0 不同 → 哈希值不同 → 桶分布不同 → 查找路径不同。但只要进程内，hash0 固定，所有查找行为就完全确定。
真正影响查找效率的，是 B、tophash 分布、overflow 链长度这三项。hash0 只在初始化和扩容重哈希时起作用，日常查找看不见它。
