必须重写hashCode，因为Object规范强制要求：若a.equals(b)为true，则a.hashCode()必须等于b.hashCode()；否则HashMap等集合中对象必然查不到或重复添加，因先通过hashCode定位桶，再调用equals。
面试官问“为什么重写 equals 就必须重写 hashCode”，答错或只说“集合要用”是拿不到分的。真正得分点在于讲清契约逻辑、演示典型翻车场景、指出 IDE 生成时容易忽略的细节。
紧扣 Object 规范，把契约当法律条款讲
JavaDoc 明确规定：如果 a.equals(b) 返回 true，那么 a.hashCode() 必须等于 b.hashCode()。这不是建议，是强制约定。面试时直接引用这条，比泛泛而谈“为了 HashMap 正常工作”更专业。
反过来说，只要违反这条，就会在哈希集合中出问题——不是“可能失效”，而是“必然查不到”或“重复添加”。可以一句话点破：hashCode 不一致，连 equals 的机会都没有，因为 HashMap 先用 hashCode 定位桶，桶都不在一个位置，根本不会调用 equals 去比较。
避开重写时的三个高频失分点
- 只改 equals，不碰 hashCode：这是最常见错误。哪怕你 equals 写得再严谨，只要 hashCode 还是默认实现，对象放进 HashSet 或作为 HashMap 的 key 就会行为异常。
- 用 Objects.hash() 处理数组字段：Objects.hash(new int[]{1,2}) 和 Objects.hash(new int[]{1,2}) 可能返回不同值，因为数组对象的默认 hashCode 是基于内存地址。正确做法是用 Arrays.hashCode(intArray) 替代。
- 继承场景下破坏对称性或传递性：比如父类重写了 equals，子类又加了新字段但没处理好 instanceof 判断或类型转换，会导致 a.equals(b) 为 true，b.equals(a) 却为 false。
展示你能落地的实操习惯
面试时不光讲道理，更要体现工程意识：
立即学习“Java免费学习笔记（深入）”；
- 用 IntelliJ IDEA 自动生成时，勾选所有参与业务判等的字段，手动检查是否漏掉不可变字段（如 ID）或忽略敏感字段（如 createTime）；
- 对含数组、List、Map 的类，不盲目套用 Objects.hash，而是分情况处理：基本类型数组 → Arrays.hashCode；对象数组 → Arrays.deepHashCode；List → 直接传入 Objects.hash（List 已重写 hashCode）；
- 写完立刻验证：new 两个字段完全相同的对象，断言它们的 equals 结果为 true，且 hashCode 值相等。
用一句话收住核心逻辑
hashCode 是“快速分组”，equals 是“精确确认”。分组错了，确认就无从谈起；确认对了，分组却乱了，系统压根找不到你让它确认的对象。
