bucketmask必须是2的幂减1，因go map用hash&bucketmask替代取模以保证等价性、不越界、不丢位；非2幂（如len=10,bucketmask=9）会导致结果错误、索引缺失、散列失真；2幂长度使低位全1，保障散列均匀与扩容时无需重哈希；go运行时自动将初始容量向上取整至2幂。
为什么 bucketMask 必须是 2 的幂次减 1
因为 Go 的 map 用 hash & bucketMask 替代取模运算，而只有当底层数组长度是 2 的幂时，bucketMask == len - 1 才能保证结果等价于 hash % len，且不越界、不丢位。
hash & bucketMask 不等于 hash % len 的典型反例
假设桶数组长度设为 10（非 2 的幂），那么 bucketMask = 9（二进制 1001）。此时：
-
hash = 13（二进制1101）→13 & 9 = 9，但13 % 10 = 3，结果错位 -
bucketMask的二进制含零位（如1001中第 2 位是 0），导致对应 hash 位被强制归零，部分索引永远无法命中 - 更糟的是，
9小于数组长度10，看似安全，但高位信息被截断，散列均匀性崩溃
2 的幂次如何保障散列质量与扩容一致性
当桶数量为 2^B 时，bucketMask 是 B 个连续的 1（如 B=4 → bucketMask = 15 = 0b1111），这带来两个硬性好处：
- 低位全 1，
hash & bucketMask等效于只保留 hash 的低 B 位，天然无偏移、无截断 - 扩容时新长度为
2^(B+1)，新bucketMask多一位，原hash & oldMask和hash & newMask的关系变成「要么同桶，要么同桶 +2^B」，无需重哈希即可拆分迁移 - 若用非 2 幂长度，扩容必须遍历所有键重新计算
hash % newLen，性能雪崩
Go 运行时怎么确保 bucketMask 合法
Go 不允许用户直接指定 map 初始容量，而是由运行时自动向上取整到最近的 2 的幂：
-
make(map[int]int, 10)→ 实际分配 16 个桶，bucketMask = 15 -
B字段存的是log₂(len)，所以bucketMask = (1 恒成立 - 手动传入非 2 幂容量不会报错，但会被静默修正；想绕过这个机制（比如用自定义哈希表）就得自己维护
mask生成逻辑
真正容易被忽略的点是：这个设计不是为了“省一个取模指令”，而是让散列分布、扩容迁移、内存局部性三者强绑定——一旦打破 2 的幂约束，这三个环节会同时劣化，且问题往往在高并发或大数据量时才暴露。
