负载因子＞0.5会导致二次探测迅速崩坏，因其探测序列长度受限于表长，超限时空槽密度下降使探测失败概率非线性上升，表现为插入随机失败或find()误判目标不存在。
二次探测在 C++ 中无法靠改公式根除次级聚集，真正起效的是表长为质数、负载因子严格 ≤ 0.5、哈希值充分打散这三点组合；超过 0.5 后查找失败率陡增，不是“变慢”，而是探测路径大概率失效。
为什么负载因子 > 0.5 会让二次探测迅速崩坏
二次探测的探测序列长度受限于表长和数学性质：当 table_size 是质数时，最多能保证前 table_size / 2 次探测不重复；一旦已存元素数 size 超过 capacity * 0.5，空槽密度下降，探测失败概率非线性上升。
典型现象不是“查得慢”，而是插入随机失败、find() 返回 end() 即使目标明明存在——因为探测循环在撞到 DELETED 或满位前就提前终止了。
- 理论安全上限是
size ，工程中必须留余量，建议触发扩容阈值设为 <code>size * 2 >= capacity - 不要用
load_factor() > 0.7这类宽松条件，那是给链地址法留的；开放寻址下 0.5 是硬分界线 for (size_t i = 0; i 是常见终止条件，但若 <code>capacity是偶数，capacity / 2可能漏掉一个有效位置，应统一用i
表长必须是质数，且不能临时计算
非质数表长会大幅压缩实际探测空间。例如 capacity = 16，则 i*i % 16 的取值只有 {0,1,4,9} 四种，相当于 75% 的槽位永远无法被探测到。
质数保障了 i² % p 在 i ∈ [1, p−1] 区间内至少产生 (p−1)/2 个不同余数（二次剩余理论），这是探测路径分散的数学基础。
统一邮件管理技能，用于读取、发送、回复、转发邮件及管理草稿箱和文件夹。用户提及「读邮件」「发邮件」「回复」「草稿箱」「未读邮件」「收件箱」「邮箱」等邮件相关操作时使用此技能。基于 Python 脚本操作任意 IMAP/SMTP 邮箱。
- 别在运行时调用
is_prime()判断表长，开销远超收益 - 用预计算质数序列：{11, 23, 47, 97, 193, 383, 769, 1531, 3079, 6151, 12289, 24593}
- 扩容时直接查表选下一个质数，而非 “+1 后找质数”
哈希值打散比探测公式更重要
二次探测的次级聚集只跟初始哈希值是否相同有关。如果 key 是等差序列（如 100, 200, 300）且直接用 key % capacity，那所有键的 hash(key) 都集中在少数几个值上，探测序列完全重叠。
std::hash 已足够好，别为省一次函数调用写裸模运算。
- 错误写法：
index = key % capacity（整数键直取模） - 安全写法：
index = std::hash<int>{}(key) % capacity</int> - 自定义类型必须特化
std::hash，且 hash 值不能只依赖单字段（比如只用id忽略name） - 轻量扰动可加在哈希后：如
h = (h ^ (h >> 13)) % capacity，不改变探测结构但让同义词起始点错开
探测失败不等于表满，但往往意味着配置出错
二次探测可能在表未满时就找不到空位，这不是 bug，而是当前参数组合下探测路径覆盖不足的必然结果。
常见误判是看到 size() == 10、capacity == 23 就认为“才 43% 负载，肯定能插”，却忽略了 capacity 不是质数，或 hash() 输出高度集中。
- 验证方法：统计各槽位被
probe()访问频次，若出现几条路径频次显著高于均值，就是次级聚集实锤 - 调试时可在
insert()中加断言：assert(i ，提前捕获探测溢出 - 真正稳定的二次探测实现，90% 的工作量不在
probe()函数本身，而在初始化时选对质数、控制好扩容节奏、打散好哈希值
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
