分布式事务下 Spring 声明式事务失效的 3 种修复方案

核心背景：Spring 声明式事务基于 AOP 动态代理实现，在分布式事务场景下，经常出现 @Transactional 注解不生效，数据库不回滚问题。本文从代理机制、异常捕获、多数据源 三个根因，给出可直接落地修复代码、问题分析、Mermaid架构流程图。

一、三大失效根因总览

1. 代理机制问题 ：类内部方法调用，不走AOP代理对象，@Transactional完全失效（最常见）
2. 异常捕获问题：业务手动 try‑catch 吃掉异常，事务切面无法感知异常，不会触发回滚；或者抛出非受检异常以外异常
3. 多数据源分布式事务问题 ：单数据源本地事务无法跨多个数据库，普通@Transactional只能管控当前数据源，其他库SQL异常无法回滚

---

二、问题1：代理机制失效（内部方法调用）

原理

Spring事务是AOP生成代理对象执行事务增强；this.xxx()内部调用，调用的是原始对象，不是代理对象，事务增强逻辑不会执行。

错误代码（失效示例）

@Service
public class OrderService {

    @Transactional(rollbackFor = Exception.class)
    public void createOrder(){
        // 内部调用，this调用原始对象，事务注解无效
        this.insertOrderDb();
    }

    public void insertOrderDb(){
        // db操作
        orderMapper.insert(new Order());
        int i = 1/0; // 抛出异常，不会回滚！
    }
}

✅修复方案两种可选

方案A：自我注入获取代理对象（推荐，无侵入）

@Service
public class OrderService {
    // 自引用拿到代理对象
    @Autowired
    private OrderService selfProxy;

    public void createOrder(){
        // 使用代理对象调用事务方法，AOP增强生效
        selfProxy.insertOrderDb();
    }

    @Transactional(rollbackFor = Exception.class)
    public void insertOrderDb(){
        orderMapper.insert(new Order());
        int i = 1/0;
    }
}

方案B：拆分方法到独立Service类

把带事务的方法抽取到另一个Service，跨类调用天然走代理。

Mermaid流程图：代理失效对比

flowchart LR
    A[Controller调用orderService.createOrder] --> B{调用对象?}
    subgraph ❌错误：this内部调用
    B -->|this原始对象| C[执行createOrder]
    C --> D[this.insertOrderDb]
    D --> E[直接执行业务逻辑<br/>无AOP事务拦截器]
    E --> F[抛出异常]
    F --> G[事务不会回滚]
    end

    subgraph ✅正确：代理对象调用
    B -->|代理proxy对象| H[执行createOrder]
    H --> I[selfProxy.insertOrderDb]
    I --> J[AOP事务拦截器进入<br/>开启事务]
    J --> K[执行业务逻辑抛出异常]
    K --> L[拦截器捕获异常触发回滚]
    end

---

三、问题2：try‑catch捕获异常，事务无法回滚

原理

@Transactional回滚依赖AOP拦截器捕获方法抛出的异常 ；如果业务代码try‑catch吞掉异常，方法正常返回，切面感知不到异常，不会回滚。

错误代码（失效示例）

@Service
public class PayService {

    @Transactional(rollbackFor = Exception.class)
    public void pay(){
        try {
            payMapper.insertPayLog();
            int i = 1/0;
        }catch (Exception e){
            // 异常被吃掉，方法无向外抛出异常 → 事务不回滚
            log.error("异常",e);
        }
    }
}

✅修复方案

1. catch中重新抛出异常；

2. 或者手动编程式事务触发回滚 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

   @Service
   public class PayService {
   @Transactional(rollbackFor = Exception.class)
   public void pay(){
   try {
   payMapper.insertPayLog();
   int i = 1/0;
   }catch (Exception e){
   log.error("支付异常",e);
   // 方式1：手动标记回滚，不抛出异常也可以回滚
   TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

            // 方式2：向外抛出异常，AOP切面捕获做回滚
            // throw new RuntimeException(e);
        }
    }

   }

注意：rollbackFor = Exception.class必须配置，Spring默认只对RuntimeException、Error回滚。

Mermaid流程：异常捕获事务流转

flowchart TD
A[进入@Transactional方法] --> B[AOP开启事务]
B --> C[执行业务代码]
C --> D{发生异常?}
D --是--> E{是否被try‑catch吃掉?}
E --✅向外抛出异常--> F[AOP拦截捕获异常 → 事务回滚]
E --❌catch吞掉异常，方法正常返回--> G[AOP无感知 → 事务提交，数据脏写]
E --catch内setRollbackOnly()--> H[标记事务回滚，最终回滚]
D --否--> I[正常提交事务]

---

四、问题3：多数据源分布式场景，普通声明式事务失效

场景：业务同时操作 order库、pay库两个不同数据源，@Transactional只能控制其中一个数据源；一个库成功，另一个库失败，出现数据不一致。

普通Spring事务是单数据源本地事务，无法跨库。

错误示例

// 配置两个数据源 ds1(order库) ds2(pay库)
@Transactional(rollbackFor = Exception.class)
public void multiDbBiz(){
    // 操作数据源1 order库
    orderMapper.insertOrder();
    // 操作数据源2 pay库
    payMapper.insertPay();
    int i = 1/0;
    // 此时只会回滚当前绑定数据源，另一个数据源已经提交，数据错乱
}

✅修复方案：3种落地选型

1. 方案1：Seata AT模式（推荐，分布式事务）
2. 方案2：JTA+Atomikos 两阶段提交
3. 方案3：SAGA模式，业务补偿（长事务场景）

Seata AT最简代码示例

1. 引入seata依赖，配置注册中心、数据源代理

   @Service
   public class MultiDbService {
   // 使用Seata全局事务注解，替代普通@Transactional
   @GlobalTransactional
   public void multiDbBiz(){
   orderMapper.insertOrder();
   payMapper.insertPay();
   int i = 1/0;
   // 发生异常，两个数据源全部回滚
   }
   }

Mermaid架构图 Seata AT分布式事务

五、总结对照表

失效场景	根因	修复要点
内部this调用方法	AOP代理对象未使用	自我注入代理对象 / 拆分Service
try‑catch吞异常	切面捕获不到异常	重抛异常 / setRollbackOnly()
多数据源跨库操作	本地事务只能单库	Seata @GlobalTransactional / JTA / SAGA补偿

关键提醒：@Transactional 本质只是AOP代理增强，不是魔法，只有代理对象调用、异常向外抛出、单数据源前提下才能生效；分布式场景必须引入分布式事务组件。