reserve(1000)后性能下降是因为实际分配1009个桶导致空桶过多、l1 cache miss上升，且桶数阶梯式增长；应优先用max_load_factor(0.75)配合reserve(n)，避免误用rehash(0)与reserve混用。
为什么reserve(1000)后性能反而下降？
不是预留空间没用，而是它实际分配了1009个桶（GCC/Clang质数表中≥1000的最小质数），插入800个元素后负载因子仅0.79，但空桶太多导致L1 cache miss上升。更糟的是，传1008可能跳到1013，传1014又跳到1019——桶数阶梯式增长，中间没有平滑过渡。
常见错误现象：bucket_count()返回值远大于size()，遍历时缓存行利用率低；Debug模式下看不出问题，Release模式实测QPS掉15%～20%。
- 别猜质数表，插入前先打印
map.bucket_count()，插入后再看一次 - 已知最终元素总数为
N，优先写成：map.max_load_factor(0.75); map.reserve(N); - 避免在循环里反复调用
reserve()——等价于反复清空+rehash，开销爆炸
max_load_factor(0.5)真的更快吗？
不一定。设成0.5会让桶数翻倍，对小对象（如int→int）高频查询反而更慢：L1 cache每行64字节，一个桶指针+链表节点常占满一行，桶越多，cache line越分散。实测在200万次查找中，max_load_factor(0.5)比0.75慢12%。
使用场景：仅当哈希函数质量差、冲突严重（比如bucket_size(i) > 8）时，才考虑压低负载因子；否则默认0.75或0.8更平衡。
- 批量插入后记得检查
map.load_factor()，超0.8可主动rehash(0) - 用
map.bucket_size(i)扫一遍所有桶，找出最大链长；若普遍>5，优先优化哈希函数而非调负载因子 - 不要只在构造时设一次
max_load_factor()，删除大量元素后也应重设并rehash(0)
rehash(0)和reserve(N)该选哪个？
reserve(N)是“我打算插入约N个元素，请提前准备好桶”；rehash(0)是“请立刻按当前size()和max_load_factor()重算桶数”。语义完全不同，混用会白费力气。
典型误用：刚删掉90%元素，size()从10000降到800，但bucket_count()仍是10007，此时还调reserve(800)——它不会收缩，只会再分配至少800的质数个桶（比如809），内存反而更多。
- 批量插入前已知总量 → 用
reserve(N) - 刚删掉大量元素，想收缩桶数组 → 用
rehash(0)（传0表示按当前状态重算） -
rehash(n)传非零值会强制设桶数≥n，慎用；rehash(0)不分配新内存，只重建桶索引，对后续遍历友好
压测时最容易被忽略的三个点
一是Debug模式下reserve()开销常被掩盖，必须在Release模式跑真实QPS；二是不同编译器初始桶数不同（GCC初值11，Clang/MSVC是8），跨平台部署要实测；三是自定义类型作key时，若std::hash<t></t>未特化或实现退化（比如只哈希指针高位），load_factor()再低也没用——冲突全堆在一个桶里。
真正关键的不是把负载因子调多低，而是让哈希分布均匀、桶数组大小贴合实际数据量、且每次rehash都可控。这三者缺一，压测曲线就会在某个数据量拐点突然崩塌。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
