桶数量需兼顾负载因子（0.7～1.0）与哈希函数质量，reserve(N) 实际取≥N的最小质数（如reserve(1000)得1009），盲目调用易致缓存失效或无效扩容；应配合max_load_factor()并验证bucket_count()和各桶分布。
桶数量不是越多越好，也不是越少越省；实际性能拐点往往出现在负载因子 0.7～1.0 区间，且严重依赖哈希函数质量——只调 reserve() 不改 max_load_factor()，大概率白忙。
为什么 reserve(1000) 后 bucket_count() 是 1009？
因为 GCC libstdc++ 和 Clang libc++ 都硬编码质数序列（如 2, 3, 5, ..., 1009, 1013），reserve(n) 的语义是“确保能装下至少 n 个元素不触发 rehash”，它会查表取 ≥n 的最小质数作为桶数。这不是四舍五入，是向上跳质数。
常见错误现象：
- 传
reserve(1008)，结果bucket_count()变成 1013；再传reserve(1012)，仍是 1013；但传reserve(1014)，就跳到 1019 - 想预留 1000 个元素空间，却分配了 1009 个桶，插入 800 个后
load_factor()才 0.79 —— 看似安全，实则空桶过多，L1 cache miss 上升 - 在循环里反复调用
reserve()，等价于反复清空 + 全量 rehash，开销爆炸
如何让 reserve() 真正按预期工作？
裸调 reserve(N) 很难精准控制桶数；更可靠的方式是结合 max_load_factor()，让标准库反推目标桶数。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 已知最终元素总数为
N，优先写成：umap.max_load_factor(0.75); umap.reserve(N); - 批量插入前，先检查
umap.bucket_count()，插入后再看一次，确认是否真扩容 - Release 模式下实测 —— Debug 模式中
reserve()的内存分配和缓存影响常被掩盖 - 避免用
rehash(N)替代reserve(N)：前者强制重建桶数组（哪怕size()是 0），后者才是为“将要插入”做准备
桶太多或太少，哪个更容易被忽略？
桶太少导致冲突链变长、查找退化为 O(n)，现象明显（耗时飙升、bucket_size(i) > 8）；但桶太多引发的缓存局部性下降，更隐蔽也更致命。
关键表现：
- 插入仅 1000 个元素，却
reserve(1000000)→ 桶数组巨大而稀疏，CPU 取桶头指针频繁 cache miss - 实测显示：桶数超过元素数 10 倍后，单次
find()耗时可能回升 15%～20%，这不是哈希问题，是硬件访存代价 -
bucket_count()返回当前桶数，不是容量上限；它只在 rehash 后变化，insert()不改变它
比桶数更关键的其实是哈希函数
哪怕桶数完美、负载因子理想，若哈希函数把大量键映射到同一桶（例如对指针地址直接 reinterpret_cast<size_t>，而内存页连续），所有优化都归零。
验证方法很简单：
- 遍历所有桶，统计
bucket_size(i) > 0的非空桶数量；理想情况应接近bucket_count() * 0.7 - 若只有几百个非空桶，而
bucket_count()是 10 万，问题几乎一定出在哈希函数，而非桶数 - 优先复用
std::hash<std::string>等标准特化，别手写只取首字符、模小质数之类“简单哈希”
真正卡住性能的，往往不是你没调 reserve()，而是你调了却没验证 bucket_count() 和 bucket_size()，也没确认哈希分布是否均匀——这些值必须打印出来看，不能靠“应该够了”拍脑袋。
