spring 的 @transactional 默认会在运行时异常发生时标记事务为回滚，即使该异常在方法内部被 catch 处理——这是导致“明明已捕获并重试，最终却返回 500 错误”的根本原因。
spring 的 @transactional 默认会在运行时异常发生时标记事务为回滚，即使该异常在方法内部被 catch 处理——这是导致“明明已捕获并重试，最终却返回 500 错误”的根本原因。
在 Spring 声明式事务（@Transactional）机制中，事务的回滚决策并非取决于异常是否被抛出到调用栈顶层，而是由 Spring 事务管理器在异常首次被抛出至事务代理边界时立即做出的。一旦底层方法（如 m2() 中的 eventRepo.save()）抛出 RuntimeException（例如 DataIntegrityViolationException 或其子类 UniqueConstraintViolationException），即使该异常立刻被 catch 并消化，Spring 仍会将当前事务标记为 ROLLBACK_ONLY。后续所有数据库操作（包括重试保存、m3() 调用等）虽能执行成功，但当事务尝试提交时，Spring 会检测到该标记并强制回滚，最终抛出 UnexpectedRollbackException，HTTP 层表现为 500 错误。
✅ 正确解法：使用编程式事务隔离重试逻辑
为避免外层事务受内层异常影响，应将带重试的冲突处理逻辑（即 m2() 的 while-try-catch-save 流程）置于一个独立、新启的事务中。这样，其内部异常仅影响自身事务，不会污染外层 m1() 的事务上下文。
推荐采用 TransactionTemplate（更简洁安全）或 PlatformTransactionManager 手动控制事务。以下为使用 TransactionTemplate 的生产级实现：
@Service
public class EventService {
@Autowired
private TransactionTemplate transactionTemplate;
@Autowired
private EventRepository eventRepo;
@Transactional
public void m1(Event event) {
// ✅ 在独立事务中完成带重试的保存，不污染 m1 的事务
transactionTemplate.execute(status -> {
m2(event); // 此处的异常仅回滚该子事务
return null;
});
// ✅ m3() 在原始事务中执行，不受重试异常影响
m3();
}
// ⚠️ 移除 @Transactional —— 交由 transactionTemplate 管理
public 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().equals("23505")) { // PostgreSQL 唯一约束码
event.setVersion(event.getVersion() + 1);
} else {
throw e; // 非预期异常，直接上抛
}
}
}
}
@Transactional
public void m3() {
// 其他业务写操作...
}
}关键配置：确保
TransactionTemplate使用PROPAGATION_REQUIRES_NEW（默认行为），以保证每次execute()启动全新事务。
? 补充说明与最佳实践
-
不要依赖
@Transactional(rollbackFor = ...)来“取消”回滚：该属性仅指定哪些异常触发回滚，无法撤销已发生的回滚标记。 -
慎用
noRollbackFor：即便配置@Transactional(noRollbackFor = UniqueConstraintViolationException.class)，Spring 仍可能因底层 JDBC 异常类型不匹配而失效，且语义上违背 ACID 原则——唯一约束失败本就是数据一致性破坏，理应隔离处理。 -
增强健壮性建议：
- 在
m2()中增加最大重试次数限制（如for (int i = 0; i ），防止无限循环； - 使用
@Retryable（Spring Retry）替代手写 while 循环，提升可读性与监控能力； - 对
eventRepo.save()操作添加日志，记录版本递增过程，便于问题排查。
- 在
通过将冲突敏感操作下沉至独立事务边界，即可彻底解除异常传播对主业务流程的影响，确保 m1() 成功提交并返回 201 状态码。
