Spring 事务传播行为与嵌套回滚处理解析

Spring事务传播行为中，默认的REQUIRED模式导致嵌套方法共享同一事务上下文，内层异常会直接标记整个事务为rollbackOnly，即使外层try-catch捕获异常也无法阻止最终回滚——这正是多数“回滚不按预期”问题的根本原因；而真正可靠的隔离方案是REQUIRES_NEW，它通过挂起当前事务、开启全新物理连接与独立事务，实现内外层回滚互不影响，特别适用于日志、审计等“尽力而为”场景；相比之下，NESTED仅依赖数据库savepoint，本质仍是同一事务内的回滚点，无法解决内层失败需外层继续执行的核心诉求，且受限于数据库支持与配置稳定性；此外，回滚行为不仅取决于传播机制，更深度耦合于rollbackFor/noRollbackFor配置及异常类型（如受检异常默认不回滚），稍有疏忽便会导致整条事务链行为失控——理解并精准组合传播行为与异常策略，才是掌控分布式数据一致性的关键。

默认的 Propagation.REQUIRED 会让嵌套方法共享事务，内层一抛异常，外层即使 try-catch 也拦不住整体回滚 —— 这是绝大多数“回滚不按预期”问题的根源。

为什么内层事务抛异常后外层 catch 了还是回滚？

因为 Propagation.REQUIRED（默认值）下，内层方法和外层方法共用同一个数据库连接、同一个事务上下文。一旦内层方法抛出未被捕获的受检/非受检异常（且没配置 noRollbackFor），Spring 就会调用 TransactionStatus.setRollbackOnly()，把整个事务标记为“只可回滚”。外层 try-catch 虽然吞掉了异常，但无法撤销这个标记。方法退出时 Spring 检测到 rollbackOnly == true，直接抛 UnexpectedRollbackException 或静默回滚。

常见错误现象：

• 外层方法明明 catch 了内层异常，日志显示“处理失败”，但数据库里外层插入的数据也没了
• 报错信息含 Transaction rolled back because it has been marked as rollback-only
• 调试发现 TransactionSynchronizationManager.isActualTransactionActive() 一直返回 true，但 isCurrentTransactionReadOnly() 或状态检查已失效

Propagation.REQUIRES_NEW 是唯一能真正隔离回滚的方案

它强制挂起当前事务（如有），并新建一个物理数据库连接 + 新事务。内层事务的提交/回滚完全独立，不影响外层事务状态。

使用场景与注意事项：

• 适合日志记录、消息发送、审计写入等“尽力而为”操作：主流程失败不能拖垮它们，它们失败也不能拖垮主流程
• 必须确保内层方法是 public，且被 Spring 代理调用（即不能 this.methodB() 直接调用）
• 性能开销略高：每次都会创建新连接，注意连接池配置（如 HikariCP 的 maximumPoolSize）
• 如果内层事务因异常回滚，且该异常未被外层捕获，它仍会向上冒泡，导致外层事务也回滚 —— 所以 try-catch 仍需保留，但目的从“防止回滚”变成“阻断异常传播”

示例关键代码：

@Service
public class OrderService {
    @Transactional
    public void createOrder(Order order) {
        orderMapper.insert(order);
        try {
            // 独立事务：即使这里失败，order 记录仍可提交
            auditLogService.record("ORDER_CREATED", order.getId());
        } catch (Exception e) {
            log.warn("audit log failed, ignored", e);
        }
    }
}

@Service
public class AuditLogService {
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void record(String action, Long refId) {
        auditLogMapper.insert(new AuditLog(action, refId));
        // 若此处抛 RuntimeException，只回滚 audit_log 表，不影响 order 表
    }
}

别乱用 Propagation.NESTED，它不是真正的嵌套事务

Propagation.NESTED 在 JDBC 层依赖数据库的 SAVEPOINT 实现，不是新开事务。它只是在当前事务内设一个回滚点，外层事务回滚时，NESTED 部分必然跟着回滚；外层正常提交，NESTED 部分才生效。它解决不了“内层失败、外层继续”的需求。

限制条件很实际：

• 仅对支持 SAVEPOINT 的数据库有效（MySQL InnoDB 可以，但早期版本或特定配置下可能禁用）
• 同一数据库连接内实现，无法跨数据源
• 若外层事务已标记 rollbackOnly，NESTED 方法根本不会执行 —— Spring 会在进入前就拒绝
• 很多团队线上禁用 NESTED，因行为不如 REQUIRES_NEW 可控

回滚控制必须配合 rollbackFor 和异常类型判断

传播行为只决定事务怎么“开”，回滚由谁触发、触发条件是什么，还得看异常策略。

关键点：

• @Transactional 默认只对 RuntimeException 和 Error 回滚，对 Exception 子类（如 IOException）不回滚 —— 如果业务逻辑抛的是受检异常，必须显式写 rollbackFor = Exception.class
• 若想让某些异常不触发回滚（比如 BusinessValidationException），要用 noRollbackFor = BusinessValidationException.class
• 内层用 REQUIRES_NEW 时，它的 rollbackFor 只影响自己事务，对外层无意义；但外层的 rollbackFor 仍要管住自己可能抛的异常

最容易被忽略的是：事务边界和异常类型的耦合关系，比传播行为本身更隐蔽。一次看似无关的异常类型变更，可能让整条事务链的回滚行为彻底改变。

到这里，我们也就讲完了《Spring 事务传播行为与嵌套回滚处理解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！