自增ID实体使用Hibernate事件监听器时出现主键重复错误

问题原因分析 #

出现该问题的核心原因，基本和IDENTITY自增主键的特性以及自定义AuditListener的逻辑有关：

• IDENTITY策略下，数据库会在插入完成后生成主键值，Hibernate要到插入结束后才会给实体的id字段赋值，这导致PostInsert/Update事件触发时，实体状态和非自增主键版本存在差异。
• 自定义Listener中可能不小心对Product实体执行了重复的持久化操作（比如调用session.save/update），此时Hibernate会误以为要重新插入一条记录，但code字段已存在，触发唯一约束。
• Listener逻辑若依赖实体的id状态（插入前为null，插入后才赋值），可能出现状态判断错误，导致重复处理。

针对性解决方法 #

1. 清理Listener中的冗余操作 #

检查AuditListener代码，确保只专注于AuditLog实体的创建和保存，绝对不要对Product实体执行save/update/merge等持久化操作。PostInsert/Update/Delete事件触发时，Product已经完成了对应的数据库操作，重复调用会导致Hibernate尝试再次写入，触发code的唯一约束。

2. 正确获取事件中的实体对象 #

在Listener的事件处理方法中，直接使用事件对象提供的实体（比如PostInsertEvent.getEntity()），不要通过session.load/get重新查询Product。重新查询可能拿到旧的快照状态，导致逻辑出错。

3. 校验Product实体的code字段配置 #

• 确认code字段的@Column(unique = true)配置正确，没有误加其他导致重复的约束。
• 排查Listener中是否有修改Product的code值的逻辑，避免后续操作时code重复。

4. 规范会话操作 #

在Listener中保存AuditLog时，直接使用事件中获取的Session（event.getSession()），不要新建独立会话。如果需要执行flush操作，确保只针对AuditLog实体，不要影响Product的会话状态。

替代审计方案 #

如果自定义Listener的问题难以排查，可考虑以下成熟的审计方案：

1. Hibernate Envers #

官方提供的审计框架，无需自定义Listener：

• 只需在需要审计的实体上添加@Audited注解，即可自动生成审计表，记录实体的插入、更新、删除历史，包括字段变更细节。
• 完美兼容IDENTITY主键策略，内部已处理各种主键类型的会话状态问题，稳定性更高。

2. Spring Data JPA Auditing #

适合轻量审计需求：

• 通过@CreatedBy、@CreatedDate、@LastModifiedBy、@LastModifiedDate注解快速实现基础审计（创建人、创建时间、修改人、修改时间）。
• 如果需要记录字段变更，可以结合@EntityListeners和@PrePersist、@PreUpdate、@PreDelete注解，在实体生命周期回调中生成审计日志，和Spring生态集成更顺畅。

3. 数据库触发器 #

完全脱离应用层的审计方案：

• 在数据库层面为Product表创建INSERT/UPDATE/DELETE触发器，当表数据变更时，自动将变更记录插入到AuditLog表。
• 优点是对应用代码零侵入，缺点是调试和维护需要数据库相关知识，无法直接获取应用层的上下文信息（比如当前登录用户）。

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