为何Visual Studio中unordered_map的bucket_count为2的n次幂？

首先明确：C标准并没有强制规定std::unordered_map的桶扩容策略，你观察到的2的n次幂增长是MSVC（Visual Studio自带的STL实现）的特有设计，其他STL实现比如GCC的libstdc早期版本就采用素数作为桶大小。

选择2的n次幂作为桶大小，核心原因是性能优化，具体优势如下：

• 桶索引计算速度更快
  常规哈希表计算元素所在桶的逻辑是哈希值 % 桶数量，整数取模是CPU中运算速度很慢的指令，性能远低于位运算。而如果桶数量是2的n次幂，可以直接用哈希值 & (桶数量 - 1)的位运算等价实现取模效果，运算开销大幅降低，在高频访问场景下的性能收益非常明显。
• 扩容逻辑更简洁
  扩容时只需要将当前桶数左移固定位数即可，你测试中观察到的8→64→512就是每次左移3位（乘以8）的策略，不需要提前预存素数表，也不需要计算离当前容量最近的素数，实现成本更低。

至于你提到的“哈希表桶数应该取素数”的认知，是针对未做哈希优化的通用实现：素数取模可以天然降低哈希值分布不均时的碰撞概率，而2的n次幂取模只会用到哈希值的低n位，如果哈希值低位分布不均，碰撞概率会显著升高。
MSVC的实现为了弥补这个缺陷，配套优化了默认哈希函数的逻辑：会对输入的原始哈希值做额外的混淆运算，把高位的特征打散到低位，保证低n位的分布足够均匀，抵消2的n次幂取模的劣势。

两种桶大小设计没有绝对的优劣：素数方案对哈希函数的要求更低，不需要额外做哈希混淆，但取模运算开销高；2的n次幂方案运算速度更快，但需要配套优化哈希函数来控制碰撞率，不同STL实现只是基于设计侧重做了不同选择。

内容的提问来源于stack exchange，提问作者DoyoHntr