集合查找失效通常因equals和hashCode未正确重写：二者必须同时重写且逻辑一致，即equals为true时hashCode必须相同；需满足规范五大契约，避免用可变字段，确保对象不可变或状态不修改。
集合查找失效，八成是 equals 和 hashCode 没写对。Java 集合（尤其是 HashSet、HashMap）依赖这两个方法协同工作：先用 hashCode 快速定位桶位置，再用 equals 精确比对对象。只要其中一个出错，contains、get、remove 就可能“看不见”本该存在的对象。
检查是否重写了 equals 但没重写 hashCode
这是最常见错误。如果只重写 equals，默认的 Object.hashCode() 仍返回内存地址哈希值，导致逻辑相等的对象散列到不同桶里，后续查找直接跳过——根本不会调用你的 equals 方法。
✅ 正确做法：
- 两个方法必须**同时重写**，且逻辑保持一致：如果
equals返回true，它们的hashCode必须相同；反之不强制，但尽量让不等对象的哈希值也不同（减少哈希冲突） - IDE（如 IntelliJ）可自动生成：右键 → Generate →
equals() and hashCode()，选中参与比较的字段即可 - 手动写时，避免用可变字段（如未加
final的普通属性），否则对象插入集合后修改字段，哈希值改变，集合内部结构就“找不到它了”
验证 equals 的实现是否满足对称性、传递性、一致性
equals 不只是“看起来相等”，它必须满足 Java 规范的五大契约：自反、对称、传递、一致、非空。违反任一契约，集合行为就不可预测。
立即学习“Java免费学习笔记（深入）”；
⚠️ 典型陷阱：
-
类型检查用
instanceof导致不对称：子类重写equals时若用instanceof Parent，父类对象调用equals(子类)可能为true，但子类调用equals(父类)却为false -
比较 null 值不严谨：应写成
Objects.equals(field1, other.field1)，而不是field1.equals(other.field1)（前者自动处理 null） - 在 equals 中读取数据库或调用远程方法：违反“一致性”（多次调用结果可能不同），也严重拖慢集合操作
确认集合中的对象没有被意外修改（破坏哈希一致性）
对象一旦放入 HashSet 或作为 HashMap 的 key，它的状态就不该再变——尤其不能修改参与 hashCode 计算的字段。
? 举例：
- 有
Person类，hashCode基于name和age；把它放进HashSet后又执行person.setAge(30)；下次set.contains(person)就很可能返回false，因为新哈希值对应另一个桶，而原桶里已无该对象 - 解决办法：把参与
hashCode/equals的字段设为final，或确保业务逻辑中不修改它们；更彻底的做法是使用不可变类（Immutable）
用调试手段快速定位问题
别靠猜，用这几招实锤：
- 在
hashCode和equals方法里加日志或断点，运行查找操作，看是否被调用、参数是否符合预期 - 打印待查对象和集合中疑似匹配对象的
hashCode()值，对比是否一致；再手动调用obj1.equals(obj2)看结果 - 用
HashSet的toArray()获取所有元素，遍历并逐个equals对比，确认目标对象确实在集合里 - 检查是否误用了不同类的实例（比如用了
new String("abc")查找存入的是"abc"字符串常量），虽然内容相同，但若自定义类没正确实现，也可能失败
不复杂但容易忽略：写完 equals 和 hashCode，立刻用单元测试覆盖基本场景——相同对象、不同对象、null 字段、修改字段后查找，比上线后排查快十倍。
