重写 equals() 时必须同步重写 hashCode()，且两者依据的字段严格一致；否则 HashMap、HashSet 等集合行为异常。推荐用 Objects.hash() 生成 hashCode，避免手工计算。
equals 返回 true 时，hashCode 必须相等
这是 Java 规范强制要求的“黄金法则”：如果 equals() 判断两个对象逻辑相等，那它们的 hashCode() 值必须完全一致。否则，像 HashMap、HashSet 这类哈希集合会直接失效——对象明明该被查到，却永远找不到。
- 典型现象：往
HashSet里加了对象 A，再用内容相同的对象 B 调用contains(B)，结果返回false - 根本原因：B 的
hashCode()和 A 不同，导致哈希表去错了“桶”，压根没走到equals()比较那一步 - 注意：这个约束是单向的——
hashCode()相等，equals()不一定为true（允许哈希冲突）
不重写 hashCode 就只重写 equals 是危险操作
很多开发者改了 equals()，却忘了同步更新 hashCode()，结果埋下隐蔽 bug。因为 Object 默认的 hashCode() 基于内存地址，而你重写的 equals() 已经按业务字段（比如 id、name）判断相等，两者彻底脱节。
- 错误示例：User 类重写了
equals()比较id，但没重写hashCode()→ 两个 id 相同的 User 实例，hashCode()却不同 - 后果：作为
HashMap的 key 时，第二次put()会新增 entry 而非覆盖；get()也取不到值 - 安全做法：只要重写
equals()，就立刻重写hashCode()，且两者依据的字段必须严格一致
怎么写一个靠谱的 hashCode 方法
手写 hashCode() 不必追求完美散列，关键是稳定、一致、基于 equals() 所用字段。JDK 自带的 Objects.hash(...) 是最稳妥的选择。
- 推荐写法：
return Objects.hash(id, name, age);—— 字段顺序和equals()中的判等顺序保持一致 - 避免魔数运算：别写类似
id * 31 + name.hashCode() * 7这种易错、难维护的手工计算 - 一致性前提：只要参与
equals()判等的字段没变，hashCode()就不能变；可变字段（如临时状态）绝不能参与计算 - 性能提示：字段越多、越分散，哈希冲突概率越低，但实际影响有限；比起“最优”，“正确”和“可读”更重要
什么时候可以不碰 equals 和 hashCode
不是所有类都需要重写。只有当你明确需要“内容相等”语义，并且对象会进入哈希集合或作为 Map 键使用时，才必须动手。
立即学习“Java免费学习笔记（深入）”；
- 安全场景：纯数据传输对象（DTO）、工具类、只做局部计算不存入集合的临时对象 → 用默认实现完全没问题
- 高危场景：实体类（User/Order）、VO、作为
HashMap的 key、放进HashSet去重、缓存 key → 必须检查是否已重写二者 - IDE 提示很关键：IntelliJ / Eclipse 都能一键生成符合规范的
equals()和hashCode()，比手写更可靠
真正容易被忽略的是：即使你用了 Lombok 的 @EqualsAndHashCode，也要确认它选中的字段和业务判等逻辑一致——比如是否误包含了数据库自增主键、时间戳这类可能变化的字段。
