java持久化中equals/hashcode应仅基于主键id实现：已持久化实体用id判断相等，新实体需统一处理（如用==或uuid）；禁用可变字段、关联字段及业务字段，确保hashcode与equals严格同步。
在 Java 持久化场景（尤其是 JPA/Hibernate）中，equals 和 hashCode 的设计目标不是“让框架能用”，而是“让业务逻辑在集合、缓存、关联映射中行为可预期”。关键在于：持久化身份必须稳定、可比较、不随字段变更而失效。
只基于主键 ID 判断相等（最常用且安全）
当实体已持久化（即 id 非 null），用主键作为唯一标识是最可靠的方式。它天然满足持久化语义——同一数据库记录，无论加载几次、处于哪个 Session，逻辑上就是同一个实体。
-
equals 实现要点：先校验类型（
getClass() == other.getClass()），再安全比较 id（推荐用Objects.equals(id, other.id)，自动处理 null） -
hashCode 实现要点：仅由
id计算，例如return Objects.hashCode(id);；若 id 是 Long，可用id != null ? id.hashCode() : 0 -
为什么避开其他字段：name、status、updatedAt 等可变字段一旦修改，
hashCode变化会导致对象在HashSet中“丢失”（无法remove或contains）
新实体（id 为 null）需统一处理边界
刚 new 出来但尚未 persist 的实体，id 为空。此时若直接按 id 比较，所有新对象都视为“不相等”，虽安全，但可能不符合业务预期（比如临时表单数据去重）。需明确策略：
- 若允许新对象之间比较，可退回到对象身份（即不重写，用
==），但仅限生命周期短暂、不入集合的场景 - 若必须支持新对象逻辑等价（如前端批量提交前校验重复），建议引入临时唯一标识（如 UUID 字段），并将其纳入 equals/hashCode —— 但该字段需与业务约定清楚，不参与数据库主键约束
- 绝对不要用业务字段（如 email、phone）替代 id 做比较：它们在 flush 前无唯一性保障，容易在 Set 中误合并两个未保存对象
关联关系字段必须排除在外
哪怕你认为“用户+地址完全相同才算同一用户”，也不能把 @ManyToOne Address address 加入 equals。原因很实际：
- 延迟加载下，
address可能是 Hibernate 代理，调用equals会触发额外 SQL，甚至 N+1 查询 - 双向关联易引发循环调用（User → Order → User），导致 StackOverflowError
- 集合字段（如
@OneToMany List<order></order>）内容动态变化，hashCode必然不稳定
hashCode 必须与 equals 严格同步
只要 equals 里用了某个字段，hashCode 就必须用它；反之，hashCode 多算字段而 equals 不比，会违反契约（相等对象哈希值不同）。
- 正确示例：
equals只比 id →hashCode只用 id - 错误示例：
equals比 id，但hashCode还加了 name → 两个 id 相同但 name 不同的对象，equals为 true，hashCode却不同 →HashMap查不到值 - 工具建议：用 IDE 自动生成（如 IntelliJ 的 “Generate… → equals() and hashCode()”），勾选仅 id 字段；或使用 Lombok 的
@EqualsAndHashCode(onlyExplicitlyIncluded = true)+@EqualsAndHashCode.Include标注 id 字段
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
