根本原因：未重写equals()和hashCode()或二者逻辑不一致；HashSet/HashMap依赖hashCode()定位桶、equals()精确比较，违反契约会导致查找失败。
自定义对象放进 HashSet 或 HashMap 为什么查不到？
根本原因：没重写 equals() 和 hashCode()，或两者逻辑不一致。Java 集合依赖这两个方法判断“相等性”——HashSet 查重靠 hashCode() 定位桶，再用 equals() 精确比对；HashMap 的 key 同理。若只重写 equals() 而忽略 hashCode()，对象可能被散列到错误桶里，直接跳过比较；若两个方法判断标准不一致（比如 equals() 比 id，hashCode() 却基于 name），则违反契约，行为不可预测。
实操建议：
- 只要类可能作为集合元素（尤其是
Set）或Map的 key，就必须同时重写equals()和hashCode() - IDE（如 IntelliJ）生成时勾选所有参与逻辑相等的字段，且确保两个方法用**完全相同的字段组合**计算
- 避免在
hashCode()中使用可变字段（如普通 setter 可改的属性），否则对象放入集合后修改该字段，会导致后续contains()失败
equals() 重写必须满足的 5 条契约
Java 规范强制要求 equals() 实现满足：自反性、对称性、传递性、一致性、对 null 的处理。实际踩坑最多的是后两条：
- **一致性**：多次调用结果必须相同（除非涉及的字段被修改）。常见错误是把时间戳、随机数、数据库自增 ID 等不稳定值纳入比较逻辑
- **对 null 的处理**：必须显式返回
false，不能抛NullPointerException。正确写法是开头加if (obj == null) return false;，或用Objects.equals(a, b)工具方法 - **类型检查必须用
instanceof（非getClass() ==）**，否则子类实例无法与父类实例相等，破坏对称性；但若类是 final 的，用getClass()更安全（防止未来被继承误用）
用 Lombok 的 @EqualsAndHashCode 真的安全吗？
它能省代码，但默认行为有隐含风险：
立即学习“Java免费学习笔记（深入）”；
- 默认只包含**非静态、非 transient 字段**，若你手动加了
transient标记业务关键字段（比如缓存计算结果），它会被自动排除，导致逻辑相等性错乱 - 若类有父类且父类也有需要参与比较的字段，必须显式写
callSuper = true，否则父类字段被忽略 - 生成的
hashCode()依赖字段顺序，若字段声明顺序后期调整（比如重构时移动了变量位置），哈希值会变——这对序列化/反序列化、跨 JVM 场景（如 Redis 缓存）可能造成问题 - 推荐写法：
@EqualsAndHashCode(onlyExplicitlyIncluded = true)+ 在关键字段上加@EqualsAndHashCode.Include，主动控制范围
放进 TreeSet 或 TreeMap 要额外注意什么？
它们不依赖 equals()/hashCode()，而是靠 Comparable 或 Comparator 排序。但问题更隐蔽：
- 如果
compareTo()返回 0（即“逻辑相等”），但equals()返回false，TreeSet会把两个对象当成同一个而拒绝插入第二个——这是合法行为，但容易让人困惑 - 务必保证
compareTo()与equals()语义一致：即a.compareTo(b) == 0⇔a.equals(b)为 true - 若用外部
Comparator，同样要检查它是否与equals()冲突；尤其注意null值处理——Comparator.nullsFirst()等工具方法返回的比较器，可能让null对象在集合中“存在感”异常
最常被忽略的一点：集合操作本身不会触发 equals()，只有当你调用 contains()、remove()、get()（map）、或迭代时发生去重（set 构造）才会真正执行。所以测试时别只看“放进去”，一定要覆盖“查出来”“删掉它”这些动作。
