桶数量直接影响查找平均复杂度；std::unordered_map的性能取决于桶数是否足够稀疏，load_factor超1.0时才rehash，易致链表过长、缓存不友好。
桶数量（bucket count）直接影响查找平均复杂度
std::unordered_map 的查找性能不只看哈希函数好坏，更取决于实际桶数量是否足够稀疏。当 load_factor（元素数 / 桶数）超过默认最大值（通常是 1.0），容器会自动 rehash——但这个时机往往滞后，已导致链表过长、缓存不友好。压测发现：在插入 100 万个 int→int 键值对时，若初始桶数设为 1 （约 104 万），平均查找耗时比默认构造低 35%～40%；而设为 <code>1 （65536）时，部分热点桶链长度超 20，L3 缓存命中率骤降，随机查找 P99 延迟翻倍。
如何合理预设桶数：别信 size()，要看 max_load_factor() 和预期元素量
构造时传入的参数是「最小桶数」，不是精确桶数；实际分配的桶数是大于等于该值的最小质数（libstdc++）或 2 的幂（libc++）。所以不能直接写 unordered_map<int>(1000000)</int> 期望得到 100 万桶——它可能给你 1048573（质数）或 220，取决于实现。
- 先调用
max_load_factor(0.75)降低负载阈值，再用reserve(N)预分配空间：这会让容器内部确保至少有ceil(N / max_load_factor())个桶 - 若已知键分布偏斜（比如大量相同哈希值），需手动加大 reserve 值，例如预期 50 万元素，设
reserve(800000)并调max_load_factor(0.6) - 避免在循环中反复
insert()后才reserve()：此时 rehash 可能已发生多次，且旧桶数组内存未及时释放
压测时必须监控 real_bucket_count() 和 load_factor()，而非只看 time
很多压测脚本只记下 clock() 差值，却忽略容器内部状态。同一份数据，在不同 STL 实现下，bucket_count() 可能差一倍，但 size() 和 load_factor() 看起来一样——这就掩盖了实际碰撞差异。
- 每次关键操作后打点：用
map.bucket_count()和map.load_factor()输出到日志，和耗时对齐分析 - 检查最忙桶：遍历
i in [0, map.bucket_count())，记录map.bucket_size(i)最大值，>8 就值得警惕 - 注意调试构建（如 -O0）下
bucket_count()返回值可能失真，压测务必用 -O2 + -DNDEBUG
自定义哈希 + 显式桶控制，才能稳定压出真实瓶颈
用 std::hash<int></int> 压测，本质是在测整数模运算和内存布局，不是 unordered_map 本身。真正影响线上表现的是业务键（如 string 或结构体）的哈希质量和桶映射效率。
立即学习“C++免费学习笔记（深入）”；
- 对
std::string，禁用默认std::hash（GCC 11+ 默认是 FNV-1a，但短字符串易碰撞），改用std::hash<:string_view></:string_view>或 SipHash - 对复合 key，手写哈希时别用
a * 31 + b这类弱散列，优先用std::hash组合 + 混淆位移，例如：size_t operator()(const MyKey& k) const { return (std::hash<uint64_t>{}(k.a) ^ (std::hash<uint32_t>{}(k.b) << 17)) * 2654435761U; } - 压测前用
map.rehash(0)强制触发一次重散列，确认当前桶布局已收敛，再开始计时
桶数量不是“越大越好”，而是要让绝大多数桶的 bucket_size() ≤ 3，同时避免过度预留导致内存浪费。最容易被忽略的是：不同编译器/STL 版本对「质数桶表」和「2 的幂桶表」的实现差异，会让同样 reserve(1000000) 在 Clang/libc++ 和 GCC/libstdc++ 下产生完全不同的桶分布——压测报告里不注明 STL 实现和版本，数据就不可复现。
