哈希表检索失败的根本原因是查找路径中断于空槽或遍历完所有可能位置未命中；键不可变性仅保障哈希值稳定，非失败直接动因。
哈希表检索失败，根本原因不在键是否可变，而在于查找路径中断于空槽或遍历完全部可能位置仍未命中——键的不可变性只是保障哈希值稳定的前提，不是失败的直接动因。
键不可变性的作用是维持哈希一致性
如果键对象在插入后被修改，且修改影响其 hashCode()（Java）或 __hash__（Python），会导致后续查找时计算出错误的散列地址。此时即使目标键实际存在于表中，也会去错位置查找，最终“查不到”——表面是检索失败，实则是逻辑错位。
- 例如：用可变列表
[1,2]作键插入哈希表，之后改为[1,2,3]，其哈希值通常改变，再查时必然跳到另一处，原位置已无法抵达 - 字符串、整数、元组等不可变类型天然满足哈希稳定性，因此被广泛选作键
- 不可变性不等于“不能改”，而是“一旦用作键，就不应改”；语言层面限制（如 Python 元组不可变）是防御性设计，非算法必需
真正导致检索失败的三个典型场景
无论键是否可变，只要满足以下任一条件，查找就会失败：
- 目标键确实不存在于表中：这是最常见、最符合语义的失败情形。哈希表按规则探测，直到遇到空槽（开放地址法）或链尾（链地址法），确认无匹配项
- 冲突处理机制未覆盖全部可能性：比如线性探测中表已满，或双重哈希的第二个函数生成零步长，导致死循环或提前终止
-
哈希函数或比较逻辑不一致：插入与查找时用了不同哈希函数，或
equals()与hashCode()行为矛盾（Java），使“相等的键”被判定为不等
开放地址法下“失败查找长度”的实质
查找失败时，系统必须确认“该键绝不可能存在”。它从哈希地址出发，按探测序列依次比对，直到首次遇到空位——这个距离就是本次失败查找的长度。这不是由键变不变决定的，而是由当前表状态和探测策略共同决定。
- 例如：哈希函数为
h(k)=k%13，某次查找从位置 7 开始，线性探测得 7→8→9→10→11→12→0→1→2，第 9 次比对发现位置 2 为空，则失败查找长度为 9 - 该长度反映的是局部聚集程度，而非键本身属性；键可变只会让这个长度变得不可预测，但不会凭空制造失败
链地址法中失败查找更依赖桶内结构
在链地址实现中，“失败”意味着遍历完对应桶（即哈希值相同的链表/链）所有节点，均未匹配。此时失败长度 = 链表长度 + 1（最后一次比对空指针）。
- 若某桶为空，失败只需 1 次操作（查头指针即为空）
- 若桶中有 5 个节点，且键都不匹配，需执行 6 次判断（5 次非空比对 + 1 次空判断）
- 键是否可变不影响链表遍历逻辑，只影响能否准确落到该桶——落错桶，就变成“查了别的链，当然失败”
