必须重写equals和hashCode才能保证集合逻辑正确；HashSet/HashMap依赖二者协同工作，ArrayList/LinkedList的contains也依赖equals；不重写会导致判等失效。
在 Java 集合中存对象，不一定必须重写 equals，但一旦你依赖集合的逻辑判断（比如 contains、remove、HashSet 去重、HashMap 查键），而默认的 equals（继承自 Object，比较引用）不符合你的业务语义，那就必须重写 —— 否则行为会出错。
为什么 HashSet / HashMap 要求重写 equals 和 hashCode
这两个类底层靠 hashCode 定位桶位置，再用 equals 确认是否为同一元素。如果只重写 equals 不重写 hashCode，相同逻辑对象可能被散列到不同桶里，导致 contains 返回 false；反之，只重 hashCode 不重 equals，可能把不同对象误判为相等。
-
hashCode必须满足：如果a.equals(b)为true，则a.hashCode() == b.hashCode() - 反过来不成立：
hashCode相同，equals不一定为true（哈希冲突允许） - 所有字段参与
equals判断的，原则上也应参与hashCode计算（常用Objects.hash(...)）
ArrayList / LinkedList 的 contains 为什么也依赖 equals
它们的 contains 方法内部是遍历并调用 Objects.equals(element, e)，最终落到对象的 equals 方法上。如果你没重写，就比较内存地址 —— 即使两个对象字段完全一样，只要不是同一个实例，contains 就返回 false。
public class User {
private String name;
private int age;
public User(String name, int age) { this.name = name; this.age = age; }
// 没重写 equals → 默认用 Object.equals()
}
List list = new ArrayList<>();
list.add(new User("Alice", 25));
System.out.println(list.contains(new User("Alice", 25))); // false！
什么情况下可以不重写 equals？
仅当你明确满足以下任一条件时，可跳过：
立即学习“Java免费学习笔记（深入）”；
- 该类只作为“临时数据载体”，从不放入任何需要逻辑判等的集合（如仅用于 JSON 序列化后丢弃）
- 你始终用
==或显式字段对比（如user.getName().equals(other.getName()) && user.getAge() == other.getAge()） - 该类是不可变且单例的（如枚举），或你确保永远只用同一实例
- 使用 Lombok 的
@EqualsAndHashCode自动生成（但要注意：它默认包含所有非静态非瞬态字段，需确认字段语义是否合理）
重写 equals 的常见陷阱
最容易漏掉的不是“要不要写”，而是“怎么写才安全”：
- 忘记判空：
if (obj == null) return false;和if (this == obj) return true;是基础守门员 - 类型检查写成
getClass() != obj.getClass()（严格类型）还是!(obj instanceof User)（允许子类）？多数场景用instanceof更实用 - 字段比较时对
null敏感：用Objects.equals(a, b)替代a.equals(b)，避免 NPE - 修改了影响
equals的字段后，又把它放在HashSet或作为HashMap键 —— 这会导致对象“消失”（找不到、删不掉），因为哈希桶位置已失效
最常被忽略的一点：重写 equals 很容易，但一旦对象进了 HashMap 的 key 或 HashSet，后续就不该再修改参与判等的字段 —— 这不是规范建议，是硬性约束。
