布谷鸟哈希通过双槽位约束与踢出重插机制实现稳定O(1)查询，需手写以保障90%+空间利用率；std::unordered_set因最坏O(n)查找、无原子删除、高内存开销而不适用。
布谷鸟哈希在 C++ 中解决哈希冲突，靠的不是“探测”或“拉链”，而是强制把每个 key 限定在两个槽位中，并用踢出+重插机制打破死锁——只要哈希函数够独立、表长选质数、踢出步数设合理，它就能把冲突转化成确定性迁移，从而维持 O(1) 查找。
为什么不能直接用 std::unordered_set 替代？
它查得慢（最坏 O(n)）、删得不安全（没原子删除语义）、空间开销不可控（指针+对齐填充占 30%+ 内存）。布谷鸟哈希要压到 90%+ 空间利用率且稳定 O(1) 查询，必须手写。常见错误是拿 std::hash<T> 直接双哈希——它不保证 h1(k) != h2(k)，容易让两个候选位置总落在同一片区域，布谷鸟逻辑直接失效。
- 插入失败不是因为表满了，而是踢出链成环：keyA 踢 keyB → keyB 踢 keyC → keyC 又踢回 keyA
- 必须设
MAX_RETRIES = 500（别用 1000），实测负载因子 ≤ 0.85 下成功率 > 99.9% - 每次踢出前用
std::vector<bool>标记已访问槽位索引，比存 key 更省内存
cuckoo_insert 怎么避免重复哈希和 memcpy 开销？
典型性能坑是每踢一个元素就调两次 hash1(key) 和 hash2(key)。正确做法是插入前一次性算好：h1 = hash1(key) % table_size、h2 = hash2(key) % table_size，存在栈变量里；后续全程用指针操作，比如 Entry* p = &table[h1]，比较/交换都解引用，避开下标检查开销。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 踢出时用
std::swap(*p, item)，而非item = *p; *p = new_item，少一次拷贝构造 - 若
Entry含非 trivial 析构函数（如含std::string），必须用 placement new + 显式析构，否则swap会泄漏 - 整型 key/value 可用哨兵值（如
INT_MIN）代替std::optional，进一步减小sizeof
cuckoo_find 怎么做到真正最坏 O(1)？
很多人实现里加了“未命中时遍历踢出链”，这就退化成 O(n)。正确做法是严格只查 table1[h1] 和 table2[h2] 两处。存储时必须保证：任意 key 的合法位置只有且仅有这两个——扩容/重建后若漏掉旧位置，查找就会误判为“不存在”。
立即学习“C++免费学习笔记（深入）”；
- 删除不能留空洞：删完必须填 dummy 标记（如
std::optional<Key>或自定义状态位），否则后续查找会跳过该槽位 - 如果用了开放寻址 fallback 表（三级表），那它不属于布谷鸟语义，查找时仍只看前两表；fallback 是兜底，不是查找路径一部分
- 多线程读场景下，用
alignas(64)修饰表数组，避免 false sharing，否则性能差 3 倍以上
真正难的不是写通逻辑，而是哈希函数的独立性控制和踢出路径的终止判定——这两个点稍有偏差，空间利用率就卡在 91%，再怎么调参数也上不去。实际部署时，连续 3 次 insert 返回 false 才该重建表，且重建必须换整套哈希系数，不能只是复制旧数据。
