当使用 @Transactional 注解时，即使在方法内部捕获了运行时异常（如唯一约束冲突），Spring 仍会将当前事务标记为“rollback-only”，导致后续操作失败并返回 500 错误。本文详解其原理，并提供程序化事务与声明式事务两种可靠解决方案。
当使用 `@transactional` 注解时，即使在方法内部捕获了运行时异常（如唯一约束冲突），spring 仍会将当前事务标记为“rollback-only”，导致后续操作失败并返回 500 错误。本文详解其原理，并提供程序化事务与声明式事务两种可靠解决方案。
在 Spring 的声明式事务管理中，@Transactional 默认遵循 “异常驱动回滚” 原则：只要事务执行过程中抛出未被捕获的 RuntimeException 或 Error，Spring 就会自动将事务状态设为 ROLLBACK_ONLY。关键点在于——该标记不可逆，且作用于整个事务上下文。即使你在 catch 块中成功处理了异常并重试写入（如递增版本号后再次保存），只要原始异常曾发生过，Spring 就不会允许事务提交，最终在方法退出时触发强制回滚，表现为 HTTP 500 和 Transaction rolled back because it has been marked as rollback-only 类似错误。
你提供的代码中，m2() 方法虽捕获了 UniqueConstraintViolationException 并重试，但该异常最初由 JPA/Hibernate 在 eventRepo.save() 内部抛出，已触发 Spring 事务管理器对当前事务的回滚标记；而 m2() 自身也标注了 @Transactional，因此它与 m1() 构成嵌套事务（实际是同一个物理事务），异常影响无法隔离。
✅ 正确解法一：程序化事务（推荐用于重试逻辑）
通过 PlatformTransactionManager 显式控制事务生命周期，确保重试过程完全独立于外层事务：
@Autowired
private PlatformTransactionManager transactionManager;
void m1(Event event) {
// 启动一个全新的、独立的事务（PROPAGATION_REQUIRES_NEW）
DefaultTransactionDefinition def = new DefaultTransactionDefinition();
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
TransactionStatus status = transactionManager.getTransaction(def);
try {
m2(event); // 此处的重试完全在此新事务内完成
m3(); // 成功后继续其他操作
transactionManager.commit(status); // 显式提交
} catch (Exception e) {
transactionManager.rollback(status); // 显式回滚，不影响外层
throw new RuntimeException("Failed to persist event after retries", e);
}
}
// 注意：移除 @Transactional，避免与程序化事务冲突
void m2(Event event) {
boolean success = false;
while (!success) {
try {
eventRepo.save(event);
success = true;
} catch (DataIntegrityViolationException e) { // 推荐捕获更通用的父类
if (e.getCause() instanceof SQLException sqlEx &&
sqlEx.getSQLState().startsWith("23")) { // SQL State 23xxx 表示完整性约束
event.setVersion(event.getVersion() + 1);
} else {
throw e; // 非预期异常，立即抛出
}
}
}
}⚠️ 注意事项：
m2()必须移除@Transactional，否则会与程序化事务产生冲突；- 使用
DataIntegrityViolationException替代具体异常类型，提升数据库兼容性；- 通过
SQLException.getSQLState()进一步校验异常根源，避免误判；PROPAGATION_REQUIRES_NEW确保每次重试都在干净事务中进行，彻底隔离异常副作用。
✅ 正确解法二：声明式事务 + noRollbackFor（适用于简单场景）
若重试逻辑较轻且无需跨方法传播事务，可改用声明式事务并明确指定不回滚的异常类型：
@Transactional(noRollbackFor = UniqueConstraintViolationException.class)
void m1(Event event) {
m2(event);
m3();
}
@Transactional(noRollbackFor = UniqueConstraintViolationException.class)
void m2(Event event) {
boolean success = false;
while (!success) {
try {
eventRepo.save(event);
success = true;
} catch (UniqueConstraintViolationException e) {
event.setVersion(event.getVersion() + 1);
}
}
}⚠️ 但此方式有局限：noRollbackFor 仅阻止该异常直接导致的回滚标记，若重试中再次抛出同类异常，或事务中其他位置抛出未声明的运行时异常，仍会回滚。因此仅适用于单次捕获+确定性重试，不推荐用于复杂重试策略。
✅ 最佳实践总结
| 方案 | 适用场景 | 安全性 | 可维护性 |
|---|---|---|---|
| 程序化事务（REQUIRES_NEW） | 高频重试、需强事务隔离、多步骤补偿操作 | ★★★★★ | ★★★☆☆（需手动管理） |
noRollbackFor 声明式 |
单次捕获+简单重试、快速修复 | ★★☆☆☆ | ★★★★★ |
应用层预检（如先 SELECT） |
低并发、容忍竞态条件 | ★★★☆☆ | ★★★★☆ |
? 终极建议：对版本号自增这类业务重试，优先采用 程序化事务 +
REQUIRES_NEW，它语义清晰、行为可控，且与 Spring 的事务传播机制完全契合。同时，在catch块中加入重试次数限制（如最多 5 次），防止无限循环导致数据库压力激增。
通过理解 Spring 事务的“回滚标记”本质，并选择合适的事务控制粒度，即可彻底规避“异常已捕获却仍报 500”的典型陷阱。
