布谷鸟哈希在C++中空间利用率高但易因循环踢出失败，标准库不用因其插入非确定性且不满足强异常安全要求；需严格控制MAX_RETRIES、双哈希独立性及早扩容（负载>0.5）。
布谷鸟哈希（Cuckoo Hashing）在 C++ 中能显著提升空间利用率，但默认实现容易因循环踢出失败而崩溃；关键不在“能不能用”，而在是否控制好 MAX_RETRIES、双哈希函数独立性、以及扩容触发阈值——三者任一失当，都会让高负载下插入直接失败。
为什么标准库不用布谷鸟哈希？
std::unordered_map 采用链地址法，核心权衡是“稳定性优先”：哪怕负载因子达 0.9，也能保证插入成功（只是变慢）。而布谷鸟哈希的插入是概率性操作——它依赖有限次“踢出-重安置”完成插入，一旦陷入循环（比如三个键互相踢来踢去），就必须扩容或报错。C++ 标准要求容器插入必须强异常安全且可预测，布谷鸟哈希天然不满足这点。
常见错误现象：insert() 调用后卡死、无限循环，或抛出未捕获的 std::runtime_error；根本原因是未设重试上限，或哈希函数相关性太强。
- 双哈希函数必须真正独立：例如
hash1(key) = key % table1.size()和hash2(key) = (key * 2654435761U) % table2.size()，避免都用取模导致分布耦合 -
MAX_RETRIES不宜超过 50；实测 >100 后，失败率不再明显下降，反而拖慢正常路径 - 扩容不是等表满才做，建议在负载因子 > 0.5 时就触发——布谷鸟哈希对密度更敏感，0.7 已属高危
如何写一个不崩的 CuckooHashTable 插入逻辑？
核心是把“踢出”变成受控状态迁移，而非无条件覆盖。每次踢出前，先检查目标位置是否为空；若非空，则交换内容并继续踢出被换出的旧键，同时递增重试计数器。一旦超限，立即扩容并重新哈希全部元素。
示例关键片段：
std::swap
- 不要盲目追求 0.95 负载——实测中，0.92 是多数场景的甜点，再高则
rehash()频率陡升 - 桶大小必须是质数，否则
hash1/hash2取模后周期坍缩，加剧循环风险 - 如果键类型是
std::string，务必自定义哈希函数（如std::hash<:string>），禁用strlen类简单累加，否则“abc”和“bca”极易同哈希
布谷鸟哈希真正的价值不在“省空间”，而在“确定性最坏查找时间”：最多查两个位置，这对实时系统或硬时限场景不可替代；但所有优化都建立在双哈希函数不相关、重试有界、扩容及时这三点上——漏掉任一，它就从利器变成定时炸弹。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
