Java中equals与hashCode应基于主键id实现，确保集合操作安全；避免使用可变字段或全字段比较，保持二者字段一致；生命周期短的实体可不重写，默认行为最安全。
Java 中 equals 与 hashCode 的配置，不是为了“对接框架”，而是为你的业务逻辑服务——框架（如 Hibernate、Spring Data JPA）本身并不依赖你写的 equals/hashCode 去做状态管理或缓存判断。它靠的是主键、一级缓存、代理对象和快照机制。所以关键不是“怎么配才能让框架认”，而是“怎么配才不会破坏你自己的集合操作和业务语义”。
用持久化身份（ID 比较）最稳妥
对绝大多数 JPA 实体来说，推荐只基于非 null 的主键（id）实现 equals 和 hashCode：
- 判断逻辑：同类型 + id 不为 null + id.equals(other.id)
- id 一旦被数据库生成（如插入后赋值），就稳定不变，不会因字段修改导致哈希码突变
- 能安全用于 Set
去重、Map 缓存键、@OneToMany(mappedBy = "...", cascade = ...) 等场景 - 避免把 name、email 等可变字段纳入比较，否则对象放入 HashSet 后改名，就再也找不到了
别用值语义（全字段比较）碰 JPA 实体
即使你认为“两个用户姓名电话都一样，就是同一个人”，也不该在 JPA 实体里用所有字段做 equals：
- 关联字段（如 @ManyToOne User creator）可能懒加载，调用时抛 LazyInitializationException
- 字段随时可更新，hashCode 变了，HashSet 里的对象就“消失”了
- 数据库唯一约束没覆盖全部字段？那值相等性本身就不可靠
- 真需要比内容，用 DTO 或专门的比较工具（如 AssertJ 的 usingRecursiveComparison）
保持 equals 和 hashCode 字段完全一致
这是硬性要求，不是建议：
立即学习“Java免费学习笔记（深入）”；
- 如果 equals 里只用了 id，hashCode 就只能用 id —— 多一个字段或少一个都会违反契约
- 用 Objects.equals(id, other.id) 配 Objects.hash(id)，null 安全且简洁
- 不要在 hashCode 里加常量（如 31 * result + 100），更不要用随机数、时间戳等不稳定值
- Lombok 的 @EqualsAndHashCode(onlyExplicitlyIncluded = true) + @EqualsAndHashCode.Include(on = "id") 是安全选择
不重写反而是种正确选择
如果你的实体生命周期短、不进集合、不参与去重或映射（比如仅作查询 DTO 或临时组装对象），那就什么也不用重写：
- 保持 Object 默认行为（== 和 System.identityHashCode）最安全
- 避免“为写而写”，尤其当团队对语义没共识时，不重写比乱重写强得多
- Hibernate 不管你重不重写，它自己用 == 判代理、用主键查二级缓存
