spring boot 全局异常处理无法直接捕获事务回滚失败异常，因为回滚发生在事务管理器层面，而全局异常处理器（如 @controlleradvice）拦截的是业务逻辑抛出的异常。要解决这个问题，必须使用 transactionsynchronizationmanager 注册同步回调，在事务提交前检查是否存在未处理的异常或标记为回滚状态，从而手动触发所需的错误响应。
为什么全局异常处理抓不到回滚异常
当 Spring 的事务代理拦截到方法执行完毕时，它会先尝试提交事务。如果此时发现数据库约束冲突、死锁或代码中显式调用了 setRollbackOnly()，事务管理器会抛出 UnexpectedRollbackException 或 TransactionSystemException。这些异常是在事务提交阶段产生的，往往绕过了正常的业务调用栈，导致 @ExceptionHandler 无法按预期捕获它们，或者捕获到的时机已经晚于业务逻辑的返回点。
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
@Service
public class OrderService {
@Transactional
public void createOrder() {
// 模拟业务逻辑
if (true) {
throw new RuntimeException("Simulated DB Constraint");
}
}
}
上述代码在运行时会触发事务回滚。由于异常是在事务提交阶段被包装或重新抛出的，全局异常处理器可能只能捕获到最外层的包装异常，而无法区分是业务异常还是回滚异常。因此，我们需要在事务内部通过同步机制来感知这一状态。
如何通过事务同步器捕获回滚状态
利用 TransactionSynchronizationManager 可以在事务生命周期内插入自定义逻辑。我们可以在业务方法中注册一个 beforeCommit 回调，在该回调中检查当前事务是否已被标记为只回滚。如果检测到回滚标记，说明即将发生回滚，此时可以记录日志或设置特定的上下文变量，供后续的全局异常处理器读取。
import org.springframework.transaction.support.TransactionSynchronization;
import org.springframework.transaction.support.TransactionSynchronizationManager;
public class TransactionHelper {
public static void registerBeforeCommit(Runnable action) {
if (TransactionSynchronizationManager.isActualTransactionActive()) {
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
@Override
public void beforeCommit(boolean readOnly) {
action.run();
}
});
}
}
}
在业务服务中调用 TransactionHelper.registerBeforeCommit，并在回调中判断 TransactionSynchronizationManager.isCurrentTransactionRolledBack()。如果为真，则表明回滚已定局。此时可以将错误信息存入 ThreadLocal 或自定义异常对象中，然后在 @ControllerAdvice 中统一捕获该特定异常，从而实现精准的错误响应。
基于 ThreadLocal 传递回滚错误信息的具体问题
在实现了事务同步监听后，如何将“回滚”这一事实传递给全局异常处理器是一个关键问题。由于事务同步回调和业务方法的返回值不在同一个执行流中，直接抛出异常会导致事务管理器再次包装异常。最佳实践是使用 ThreadLocal 存储回滚原因，并在 @ControllerAdvice 中检查该值。如果存在回滚原因，则构造一个包含具体错误信息的 ResponseEntity 返回给前端，而不是依赖默认的异常堆栈打印。
