必须重写hashCode()，因为哈希集合依赖hashCode()定位桶、equals()精确比对；若只重写equals()，相等对象可能散列到不同桶，导致HashSet重复插入或HashMap查不到key。
为什么重写 equals() 就必须重写 hashCode()
因为哈希集合（如 HashSet、HashMap）内部依赖「先查桶、再比值」的两层机制：先用 hashCode() 定位到数组下标（桶），再用 equals() 在桶内精确比对。如果只重写 equals() 而不重写 hashCode()，逻辑上相等的对象可能被散列到不同桶里，导致 HashSet 误存重复项、HashMap 查不到已存在的 key。
- 默认
Object.hashCode()返回的是对象内存地址的哈希值，两个内容相同但不同实例的对象，hashCode()必然不同 -
HashMap.get(key)的源码中，第一道判断就是e.hash == hash；不通过就直接跳过后续equals()比较 - 违反契约（
equals()相等 ⇒hashCode()必须相等）会导致集合行为不可预测，且这种 bug 很难通过单元测试覆盖到
不配对重写的典型故障现象
最常见的是「明明 equals() 返回 true，但 HashSet 还是加进去了两个对象」或「HashMap 里存了 key，却 get() 不出来」。
-
HashSet.add(new Person("Alice", 25))和HashSet.add(new Person("Alice", 25))—— 如果没重写hashCode()，size 可能是 2 而不是 1 -
map.put(new Apple("red"), 10)后，map.get(new Apple("red"))返回null，哪怕Apple.equals()已正确返回true - 调试时发现两个对象
equals()为true，但它们的hashCode()值差得离谱（比如-129384723vs192837465）
正确重写姿势：3 条硬约束 + 1 个推荐工具
核心不是“怎么写”，而是“不能漏什么”。Java 规范只要求满足契约，不规定实现方式，但实际开发中必须守住底线：
- 所有参与
equals()判等的字段，也必须参与hashCode()计算（反之不一定） -
hashCode()计算中避免使用可变字段（如未声明final且后续会修改的属性），否则对象加入HashSet后再改字段，就再也找不到了 - 空值处理要一致：
equals()中用Objects.equals(a, b)，hashCode()中就用Objects.hash(a, b) - 强烈建议用 IDE 自动生成（IntelliJ →
Alt+Insert→ “Generate” → 选equals()和hashCode()），它会自动处理 null、类型检查、字段一致性
public class User {
private final String name;
private final int age;
// 构造、getter 略
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
User user = (User) o;
return age == user.age && Objects.equals(name, user.name);
}
@Override
public int hashCode() {
return Objects.hash(name, age); // ← 与 equals 中的字段严格一致
}
}
容易被忽略的坑：继承场景下的陷阱
子类如果扩展了父类的判等逻辑（比如新增字段），但没重写 equals() 和 hashCode()，或者只重写了其中一个，问题会更隐蔽——尤其当父类已重写过这对方法时。
立即学习“Java免费学习笔记（深入）”；
- 子类重写
equals()时，必须调用super.equals()，否则可能破坏对称性（a.equals(b)为true，但b.equals(a)为false） - 子类的
hashCode()必须包含父类参与判等的所有字段，否则父子实例之间可能违反「相等必同哈希」契约 - 若父类没重写
hashCode()，子类重写equals()却忘了重写hashCode()，那子类实例的哈希值仍来自Object默认实现，直接失效
HashMap 的 key，就必须成对重写。漏掉一次，就可能埋下一个线上查不出来源的 null 返回或重复插入。 
