HashSet对象“失联”的根本原因是equals()与hashCode()运行时协作失效；需三步验证：一查remove前后hashCode是否一致，二验相等对象hashCode是否相同，三模拟查找路径确认桶索引与equals匹配。
定位 HashSet 中对象“失联”问题，核心是验证 equals() 和 hashCode() 是否满足契约一致性——不是看它们有没有重写，而是看它们在运行时是否协同工作。下面分三步直击关键点：
一、检查 remove 操作前后的 hashCode 值是否一致
对象加入 HashSet 后若被修改，其 hashCode 可能已变，导致 remove 时找不到原桶位置。
- 在调用
set.remove(obj)前后，分别打印obj.hashCode() - 如果两次值不同，说明对象状态变更破坏了哈希一致性（如修改了参与计算的字段）
- 典型场景：Book 对象加入 set 后改了 title，而 hashCode 依赖 title → 删除失败
二、验证两个逻辑相等对象的 hashCode 是否相同
这是判断重写是否合规的最直接证据。
- 构造两个内容完全相同的对象：
p1 = new Person("Alice", 25)，p2 = new Person("Alice", 25) - 确认
p1.equals(p2) == true，再检查p1.hashCode() == p2.hashCode() - 若为 false，说明 hashCode 未正确实现（比如漏字段、用了可变字段、或用了默认实现）
三、模拟 HashSet 查找路径，手动走一遍逻辑
把 HashSet 的查找过程拆解出来，用调试或日志还原它“为什么找不到”：
- 获取待删对象的 hashCode → 算出桶索引（可用
(h ^ (h >>> 16)) & (table.length - 1)模拟） - 遍历该桶内所有元素，逐个调用
obj.equals(candidate) - 如果桶里没有元素，或有但
equals()全返回 false，就说明“失联”根源在此 - 此时可反查：该对象当初
add时的 hashCode 是多少？是否和现在一致？桶位置是否变了？
不复杂但容易忽略：问题往往不出在“没重写”，而出在“重写了但不守规矩”。每次怀疑失联，就按这三步验证，基本能快速锁定是 hashCode 不一致、equals 不对称，还是对象中途被意外修改。
