随机探测不被C++标准库采用，因破坏探测序列可重现性，致查找失败、删除异常及迭代器失效；线性探测易一次聚集，二次探测缓解但存二次聚集与循环风险；优化应聚焦reserve、质数容量及哈希函数设计。
随机探测在 C++ 开放寻址哈希表中**不被标准库采用，也不推荐手动实现**——它破坏探测序列的可重现性，导致查找失败或逻辑错误。
为什么 std::unordered_map 不用随机探测
开放寻址法要求每次冲突时的探测路径必须确定且可复现：插入和查找必须走完全相同的下标序列，否则查不到已存元素。随机探测每次调用 hash(key) 后再取随机数，会导致同一 key 多次查找落在不同位置，直接破坏哈希表语义。
常见错误是误以为“随机跳”能缓解聚集，但实际后果更严重：
- 查找时无法保证命中——哪怕元素存在，也可能因随机种子/顺序不同而跳过
- 删除操作无法安全执行——逻辑删除依赖确定的探测链，随机路径让“标记为空”失去意义
- 迭代器遍历失效——桶数组不再有稳定访问顺序，
begin()/end()无法覆盖全部有效元素
linear_probe 和 quadratic_probe 的真实差异
线性探测（index = (hash + i) % capacity）简单高效，但容易形成一次聚集（primary clustering），即连续占用多个桶，后续插入更易冲突。
立即学习“C++免费学习笔记（深入）”；
二次探测（index = (hash + i*i) % capacity）用平方步长打散线性趋势，缓解一次聚集，但引入新的问题：
- 不是所有容量都能探查全部桶——当
capacity不是质数或不满足4k+3形式时，探测序列可能陷入循环，永远找不到空位 - 仍存在二次聚集（secondary clustering）：相同 hash 值的 key 走完全相同的探测路径，只是比线性“跳得远”
- 计算开销略高（乘法+模），在高频插入场景下可观测到微小性能差
真正有效的开放寻址优化点
与其折腾探测方式，不如聚焦标准库允许且可控的优化项：
- 显式调用
reserve(n)预分配桶数量，避免多次 rehash —— 比任何探测策略对性能影响都大 - 用质数容量替代默认的 2 的幂扩容（
std::unordered_map默认使用非质数桶数，部分 libstdc++ 实现会自动选质数，但 libc++ 不保证） - 重载
std::hash时避免异或（^）拼接字段，改用移位混合（如(h1 ），减少哈希值低位重复 - 对字符串键，禁用默认
std::hash<:string></:string>在短字符串上的退化行为（某些旧版本 GCC 对长度 ≤ 8 的 string 直接返回字节值），可特化为 BKDR 或 FNV-1a
什么时候该放弃开放寻址，换链地址
当你遇到以下任一情况，std::unordered_map 的底层链地址法（而非你手写的开放寻址）反而是更优解：
- 键类型复杂、哈希函数难写均匀（如含浮点字段、指针地址参与计算）
- 负载因子波动剧烈（例如先插 10 万再删剩 100），开放寻址缩容成本高且不可控
- 需要稳定迭代顺序（链地址法每个桶内插入顺序可保持，开放寻址因探测跳跃完全无序）
- 调试时需快速定位冲突桶 ——
bucket_size(i)和bucket_count()是链地址法的天然优势
手写开放寻址最大的陷阱，不是选错探测公式，而是忘了它本质是个“脆弱的数组索引协议”：只要一个环节（哈希、模、探测、删除）没对齐，整张表就静默失效。生产环境优先信任 std::unordered_map 的链地址实现，把精力放在哈希质量和负载控制上。
