Hibernate实体生成equals()和hashCode()的方案选择

针对你提出的三个问题，结合Hibernate官方最佳实践给出明确结论：

1. IntelliJ生成模板选择 #

直接选择**Java 7+**模板，不要使用IntelliJ Default模板，原因如下：

• Java 7+模板基于JDK内置的java.util.Objects.equals()和java.util.Objects.hash()实现，自带空值安全，没有冗余的手写空判断逻辑，代码简洁不容易出错
• IntelliJ Default是兼容JDK6及更早版本的旧模板，代码冗长，且默认使用getClass()做类型校验，无法识别Hibernate生成的实体代理对象，会导致同一数据库记录的代理实例和原实例判断为不相等
• 生成时注意勾选两个配置：
  • 类型判断使用instanceof而非精确类匹配，适配Hibernate代理场景
  • 不要勾选「使用getter访问字段」选项，直接访问类的私有字段，避免触发未初始化的懒加载抛出LazyInitializationException

2. User实体参与逻辑判断的字段选择 #

结论非常明确：仅选择带唯一约束的email字段参与equals()和hashCode()逻辑，不要选自增主键id，也不要选普通字段name，核心依据是equals()/hashCode()的Java契约要求：判断相等的逻辑必须在对象整个生命周期内保持稳定，不能出现对象存到容器后hashCode突变导致寻址失败的问题。
各字段排除/选择的原因：

• 排除数据库自增生成的id：这个字段值在实体持久化到数据库之前是null，新创建的瞬态实体如果放到HashSet/HashMap这类基于哈希的容器中，等持久化后id被赋值，hashCode会直接变化，导致容器内的对象无法被正常查找，这是Hibernate实体实现相等逻辑最常见的坑
• 排除name字段：该字段没有唯一约束，属于可修改的普通业务字段，用户修改姓名后hashCode会变化，同样违反契约要求
• 选择email字段：该字段加了数据库唯一约束，属于天然的业务主键，只要在构造函数中校验非空、保证实例化时就赋值确定值，完全满足相等判断的稳定性、唯一性要求。
  如果实体没有这类天然唯一的不可变业务键，建议在实体中新增一个实例化时就自动赋值的不可变UUID字段，专门用于相等判断，不要依赖数据库生成的主键。

3. @EqualsAndHashCode注解的使用建议 #

不存在「注解一定不灵活必须手动写」的绝对结论，只要配置正确完全可以用，配置错了手动写一样出bug：

• 禁止直接在类上加无配置的@EqualsAndHashCode：Lombok默认会把所有字段（包括自增id）都纳入判断逻辑，且默认通过getter访问字段，会直接踩前面提到的自增id坑、懒加载坑
• 正确配置下可以放心使用：添加注解时指定参数@EqualsAndHashCode(onlyExplicitlyIncluded = true, doNotUseGetters = true)，只在你选定的业务键字段（比如本例中的email）上加@EqualsAndHashCode.Include注解，其他字段全部排除，生成的逻辑和手动编写的规范实现完全一致，能省掉大量重复样板代码
• 以下场景更推荐手动实现：如果相等判断有特殊业务规则（比如需要结合软删除标记判断、多字段组合业务键有特殊空值处理逻辑），手动编写逻辑更直观可控，避免注解配置疏漏导致隐蔽bug。

内容的提问来源于stack exchange，提问作者user19254373