std::unordered_set不能替代布谷鸟哈希：其最坏O(n)查询、不支持安全删除、内存开销不可控；布谷鸟哈希需手写，依赖优质双哈希函数、质数表长及防循环踢出机制，方能实现稳定O(1)查询与超90%空间利用率。
std::unordered_set 不能替代布谷鸟哈希——它查得慢、删得不安全、空间开销不可控，真要压到 90%+ 空间利用率且稳定 O(1) 查询，必须手写。
为什么 insert 会卡死或反复失败
不是表满了，而是踢出链形成了环：keyA 踢 keyB，keyB 踢 keyC，keyC 又踢回 keyA。没有终止机制时，while 循环就停不下来。
- 硬编码
MAX_RETRIES = 500（别用 1000 或 100），实测在负载因子 ≤ 0.85 下成功率 > 99.9% - 每次踢出前检查位置是否已访问过，用
std::vector标记槽位索引比存key更省内存 - 失败后必须扩容，新
table_size设为原大小 × 1.3～1.4，避开质数重复导致的哈希分布塌缩
两个哈希函数怎么写才不互相打架
若 hash1(k) 和 hash2(k) 输出高度相关（比如都用 k % N 加个偏移），所有键的两个候选槽位会挤在同一片区域，布谷鸟逻辑直接失效。
- 整型输入推荐：
hash1 = k % table_size，hash2 = (k * 2654435761U) >> (32 - bits)（黄金比例移位法，bits 是表长二进制位数） - 字符串输入别复用同一套 BKDR：一个用乘数 31，另一个改用 FNV-1a 变体（
hash ^= c; hash *= 16777619） - 所有哈希函数参数必须是
const Key&，std::string类型绝不能值传参 - 每次扩容后重置哈希函数实例，避免旧种子残留影响分布
如何让内存比 std::unordered_map 少 30%+
std::unordered_map 每个节点带指针 + 对齐填充，而布谷鸟哈希能用纯数组塞满——但前提是结构紧凑、无冗余状态标记。
- 用单个
std::vector<:optional value>>>，而非两个独立表；空位靠std::nullopt表示，省掉布尔标记字段 - 对整型 key/value，可用哨兵值（如
INT_MIN）代替std::optional，进一步减小 sizeof - 禁止在每个槽位存“deleted”、“empty”等状态位；布谷鸟机制天然支持“清空即删除”，无需墓碑标记
- 初始化时调用
reserve()预分配，避免 vector 动态增长带来的碎片和拷贝
插入失败后重建表的触发条件很关键
盲目一失败就重建，代价太高；一直重试又可能卡住。实际星图特征库场景中，连续 3 次 insert 返回 false 才该重建——且重建不是简单复制，要换整套哈希系数。
- 新系数从质数池随机采样（如 6 个不同质数用于线性组合），避免与旧系数产生线性相关
- 新
table_size在原基础上增加 5%，并再次校验是否为质数（用 Miller-Rabin 快速判别） - 重建前 dump 当前所有
key到临时 vector，重建后顺序重插，避免递归调用导致栈溢出 - 真正难调的点不在算法逻辑，而在哈希函数输出的低位信息是否被截断——模运算前务必保留完整计算结果，别提前
& 0xFFFF
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
