必须同时重写equals和hashCode，否则逻辑相等的对象因哈希值不同被散列到不同桶中，导致HashSet去重失效、HashMap查找不到已存键等问题；二者须基于相同字段计算且遵守Java规范契约。
因为 Java 集合（如 HashMap、HashSet）依赖 hashCode 定位对象位置，再用 equals 精确判断是否重复；如果只重写 equals 而不重写 hashCode，逻辑上相等的对象可能被散列到不同桶中，导致查不到、存不进、去重失效。
核心原因：哈希表的查找机制要求二者一致
HashMap 和 HashSet 底层是哈希表，插入或查找时分两步：
- 先调用对象的 hashCode()，算出它该放在哪个数组索引（“桶”）里
- 若该桶已有元素，再用 equals() 逐个比对，确认是否真正相等
如果两个对象业务上相等（a.equals(b) == true），但 a.hashCode() != b.hashCode()，它们就会被放进不同的桶——后续调用 map.get(b) 或 set.contains(b) 就永远找不到 a，哪怕它们内容完全一样。
违反约定会破坏集合行为
Java 规范明确要求：只要 equals 返回 true，hashCode 就必须返回相同值。这是 Object 类文档和《Effective Java》强调的强制契约。违反它会导致：
立即学习“Java免费学习笔记（深入）”；
- HashSet 存入重复对象：两个逻辑相等的对象因 hash 不同被当作不同元素存入
- HashMap 查不到已存在的键：用新构造的等价对象 get，返回 null
- ConcurrentHashMap 或 LinkedHashSet 行为异常：底层仍基于哈希定位，同样受影响
重写时的关键原则
两者必须基于同一组字段计算：
- equals 中用于比较的字段（比如 name 和 age），hashCode 也必须参与运算
- 推荐用 IDE 自动生成（如 IntelliJ 的
Alt+Insert → equals and hashCode），避免手误漏字段 - 注意 null 安全：字段为 null 时，用
Objects.hashCode(field)或三元判断，别直接调field.hashCode()
不重写的典型反例
假设 Person 类只重写了 equals（按 name 和 age 判断相等），但没动 hashCode：
Person p1 = new Person("Alice", 25);
Person p2 = new Person("Alice", 25);
System.out.println(p1.equals(p2)); // true
System.out.println(p1.hashCode() == p2.hashCode()); // false（用的是 Object 默认实现）
Set<Person> set = new HashSet<>();
set.add(p1);
System.out.println(set.contains(p2)); // false —— 本该是 true！
这就是未同步重写带来的实际故障。
