必须重写hashCode，因为哈希集合依赖hashCode定位桶、equals精确比对；若equals为true而hashCode不同，对象会被散列到不同桶，导致查找失败、重复插入等逻辑错误。
重写 equals 时必须同步重写 hashCode，这是 Java 规范强制要求的契约，直接关系到 HashMap、HashSet 等集合能否正确工作。
为什么必须保持一致？
哈希集合依赖“先散列、再比对”的两步机制：
- 先用
hashCode()计算对象应放入哪个桶（bucket） - 桶内若有多个元素，再用
equals()精确判断是否为同一逻辑对象
如果两个对象 equals() 返回 true，但 hashCode() 不同，它们会被分到不同桶里——结果就是：查不到、重复添加、集合行为失常。
重写时的核心原则
确保语义统一、字段一致、行为稳定：
立即学习“Java免费学习笔记（深入）”；
-
字段完全一致：参与
equals判断的字段，必须全部用于hashCode计算；反之亦然 -
顺序严格对应：比如
equals先比id再比name，hashCode也必须按相同顺序传入Objects.hash(id, name) -
避免可变字段：若字段可能被修改（如普通 setter），且又参与
equals和hashCode，会导致哈希值变化，破坏一致性 -
null 安全处理：用
Objects.equals(a, b)替代a.equals(b)，用Objects.hash(f1, f2)替代手动计算，自动处理 null
推荐写法与常见错误
使用 JDK 7+ 提供的工具类，简洁可靠：
- ✅ 正确示例：
return Objects.hash(id, name);（字段与equals完全一致） - ❌ 忘记重写
hashCode：沿用 Object 默认实现（基于内存地址），导致逻辑相等但散列位置不同 - ❌ 字段不匹配：比如
equals比了id和email，hashCode却只用了id - ❌ 引入非业务字段：如把
createTime或临时缓存字段加入hashCode，破坏稳定性
不可变类的优化技巧
对于 final 字段构成的不可变类，可以缓存哈希值提升性能：
- 声明私有
private final int hashCode; - 在构造器中一次性计算并赋值：
this.hashCode = Objects.hash(id, name); -
hashCode()方法直接返回该字段，避免重复计算 - 注意：仅适用于字段永不改变的场景，否则缓存会失效
