只重写equals会导致HashSet找不到对象，因为HashSet先用hashCode定位桶再用equals比对；若逻辑相等的对象哈希值不同，就会散列到不同桶中，造成contains返回false、add重复对象成功等现象。
为什么只重写 equals 会导致 HashSet 找不到对象？
因为 HashSet（以及 HashMap）先用 hashCode 定位桶，再用 equals 精确比对。如果两个逻辑相等的对象（u1.equals(u2) == true）返回不同哈希值，它们大概率被散列到不同桶里——set.contains(u2) 就会返回 false，哪怕 u1 已在集合中。
- 现象：对象内容一样，
contains返回false；add同一对象两次，集合大小变成 2 - 根本原因：
hashCode仍走 Object 默认实现（基于内存地址），而equals已按业务字段比较 - 不是“偶尔出错”，而是“必然失效”——只要哈希值不一致，哈希集合的查找逻辑就断了
equals 和 hashCode 的契约到底约束什么？
Java 规范只强制一条核心规则：如果 a.equals(b) == true，那么 a.hashCode() == b.hashCode() 必须为 true。反过来不成立（哈希相同 ≠ 一定相等）。
- 违反该契约 →
HashMap.get(key)可能返回null，即使键确实存在 - 自反性、对称性等是
equals自身要求，但若没同步更新hashCode，这些也白搭 - 别用
getClass() != obj.getClass()做类型检查（影响继承），改用instanceof更安全
怎么写才不算翻车？三个实操底线
别自己手算哈希或拼字符串，用 JDK 提供的工具链保底。
-
equals中只比较「不可变」或「参与业务判等」的字段，比如id或name，别把lastLoginTime这种可变字段塞进去 -
hashCode必须用和equals完全相同的字段计算，推荐Objects.hash(id, name)——它自动处理null，且结果确定 - 一旦对象进了
HashSet或当了HashMap的 key，就别再修改参与hashCode计算的字段，否则永远找不回来
IDE 自动生成的代码为什么有时还出问题？
IntelliJ 或 Eclipse 生成的 equals/hashCode 大多合规，但容易忽略两个隐形坑：
立即学习“Java免费学习笔记（深入）”；
- 选错了参与比较的字段：比如勾了
createTime，但业务上只认id，结果时间戳微差就判不等 - 用了
getClass()严格类型检查，导致子类对象无法和父类实例equals（比如AdminUser和User） - 字段是懒加载的代理对象（如 Hibernate 的
LazyInitializationException场景），getter可能抛异常 —— 此时应改用字段直取或加空判断
真正难的从来不是“怎么写”，而是“哪些字段该进判等逻辑”，这得抠清楚业务语义，而不是堆代码。
