Spring事务失效的典型场景与避坑指南

在基于Spring的应用开发中，声明式事务（@Transactional）已经成为处理数据库一致性的默认手段。它把事务管理的样板代码从业务逻辑中剥离出来，让开发者可以专注于核心流程。然而，很多团队在项目推进中都会遇到一种令人困惑的现象：方法上明明标注了@Transactional，代码逻辑看起来也没有问题，但一旦发生异常，数据却并没有按预期回滚。更棘手的是，这类问题通常不会在编译期暴露，也不会在常规功能测试中被立刻发现，而是等到生产环境出现账目不平、库存错乱或状态不一致时才被追查出来。

这类“事务静默失效”问题的根源，往往不在业务代码本身，而在于对Spring事务代理机制、异常约定以及传播行为的理解不够完整。本文从实际开发中常见的失效场景出发，系统梳理事务不生效的原因，并给出可落地的规避方案。

一、同类内部调用绕过代理

Spring的声明式事务本质上依赖AOP代理来实现。当容器中的Bean被@Transactional标注后，Spring会为该Bean生成一个代理对象。外部调用方通过注入拿到的是这个代理对象，而不是原始的目标对象。代理对象在方法执行前后负责开启事务、提交事务或触发回滚。

问题出现在Service类内部的自我调用。例如：

@Service
public class WalletService {
    @Transactional
    public void batchRecharge(List<Long> userIds, BigDecimal amount) {
        for (Long userId : userIds) {
            this.recharge(userId, amount);
        }
    }
    @Transactional
    public void recharge(Long userId, BigDecimal amount) {
        // 执行扣款或充值逻辑
    }
}

在batchRecharge方法内部调用this.recharge()时，this指向的是原始目标对象，而不是Spring容器中的代理对象。代理对这次内部调用完全无感知，因此recharge方法上的@Transactional注解不会生效。结果就是，batchRecharge整体在一个事务中运行，而recharge自身的回滚行为与batchRecharge完全绑定，甚至在某些调用路径下根本不在事务保护范围内。

解决这个问题有几种常用方式。一种是通过注入自身来获取代理对象：

@Service
public class WalletService {
    @Autowired
    private WalletService self;
    public void batchRecharge(List<Long> userIds, BigDecimal amount) {
        for (Long userId : userIds) {
            self.recharge(userId, amount);
        }
    }
    @Transactional
    public void recharge(Long userId, BigDecimal amount) {
        // 业务逻辑
    }
}

另一种方式是将被调用的方法拆分到独立的Service Bean中，让跨Bean调用天然经过代理。无论选择哪种方案，核心原则是：避免在同一个类内部通过this调用带事务注解的方法。

二、private方法无法被代理

Spring AOP的CGLIB代理机制通过生成目标类的子类来实现方法拦截。这意味着被代理的方法必须能够被子类继承和重写。对于private方法来说，子类无法访问，更无法重写，因此CGLIB无法在其上织入事务逻辑。

如果开发者在某个private方法上标注@Transactional，代码不会报错，运行期间也不会抛出异常，但事务增强完全不会生效。这种情况比内部调用更隐蔽，因为从代码外观上看，注解是存在的，开发者很容易产生“已经加了事务”的错觉。

因此，需要事务保护的方法必须至少是public的。如果某个private方法需要独立事务控制，应将其提升为public并放入可被代理的Bean中，或者重新审视方法职责划分，将其中的事务性操作提取到独立的公共方法中。

三、异常被吞掉导致代理无法感知

声明式事务的回滚机制依赖于异常传播。代理对象只有在捕获到方法抛出的异常时，才能判断是否需要回滚。如果业务方法内部捕获了异常并且没有重新抛出，代理就会认为方法正常返回，进而提交事务。

典型代码如下：

@Transactional
public void pay(Long orderId) {
    try {
        // 扣款逻辑
        accountDao.deduct(orderId);
    } catch (Exception e) {
        log.error("扣款失败", e);
    }
}

这段代码中，扣款操作抛出异常后，被catch块吞掉，方法最终正常结束。代理对象看不到任何异常信号，于是提交事务。数据库中的扣款操作虽然失败了，但其他已经执行的写操作仍然被提交，造成数据不一致。

如果希望在记录日志的同时保留回滚行为，可以在catch块处理完成后重新抛出异常：

@Transactional
public void pay(Long orderId) {
    try {
        accountDao.deduct(orderId);
    } catch (Exception e) {
        log.error("扣款失败，触发回滚", e);
        throw e;
    }
}

这里的关键是让异常继续向外传播，确保代理能够捕获并触发回滚。

四、受检异常默认不回滚

Spring事务的默认回滚策略是：只有在抛出RuntimeException或Error时才会回滚。对于受检异常（Checked Exception），事务管理器默认执行提交操作。

例如，文件处理、网络通信或某些第三方SDK调用会抛出IOException、TimeoutException等受检异常。如果业务方法直接将这些异常向外抛出，而没有额外配置，事务不会回滚。

@Transactional
public void importData(InputStream in) throws IOException {
    // 读取文件并写入数据库
    fileParser.parse(in);
    orderDao.batchInsert(orders);
}

如果fileParser.parse抛出了IOException，orderDao.batchInsert之前已完成的部分写入不会被回滚。

解决方式是在@Transactional注解上显式指定回滚异常类型：

@Transactional(rollbackFor = Exception.class)
public void importData(InputStream in) throws IOException {
    // 业务逻辑
}

从团队规范角度出发，统一使用rollbackFor = Exception.class是一个值得推荐的实践。它不会对RuntimeException的默认回滚行为产生负面影响，同时把受检异常也纳入回滚范围，减少因遗漏配置而导致的数据风险。

五、REQUIRES_NEW的独立提交风险

事务传播行为中，REQUIRES_NEW会为当前方法开启一个全新的独立事务，并挂起外层事务。这个特性常用于“子操作失败不应影响主流程”的场景。例如充值成功后赠送积分，积分逻辑失败时不应导致充值失败：

@Transactional
public void recharge(Long userId, BigDecimal amount) {
    walletDao.addBalance(userId, amount);
    try {
        pointsService.grantPoints(userId, amount);
    } catch (Exception e) {
        log.warn("积分赠送失败，不影响充值", e);
    }
}

其中pointsService.grantPoints方法标注了@Transactional(propagation = Propagation.REQUIRES_NEW)。积分操作在独立事务中执行，失败后只回滚自己的事务，外层充值事务不受影响。

但REQUIRES_NEW也有反向风险。一旦内层事务提交成功，它的结果就不再受外层事务控制。如果外层事务在后续逻辑中发生异常并回滚，内层事务已提交的数据不会随之回滚。

例如：

@Transactional
public void recharge(Long userId, BigDecimal amount) {
    walletDao.addBalance(userId, amount);
    pointsService.grantPoints(userId, amount); // REQUIRES_NEW，独立提交
    // 此处抛出异常
    orderDao.updateRechargeStatus(userId, "FAILED");
}

如果orderDao.updateRechargeStatus抛出异常，外层事务回滚，walletDao.addBalance的余额变更会回滚，但积分已经通过REQUIRES_NEW提交，无法撤销。最终现象是用户充值失败，积分却到账了。

这种场景下，如果业务要求充值余额和积分赠送必须“同生共死”，应使用NESTED传播行为。NESTED不会开启独立事务，而是在外层事务中创建一个保存点。内层逻辑失败时回滚到保存点，外层事务后续仍可继续；外层事务整体失败时，所有嵌套操作一并回滚。

@Transactional(propagation = Propagation.NESTED)
public void grantPoints(Long userId, BigDecimal amount) {
    // 积分写入逻辑
}

需要注意的是，NESTED依赖底层数据库对保存点的支持。使用DataSourceTransactionManager配合MySQL InnoDB时，保存点是原生支持的，可以放心使用。但在切换数据库或事务管理器时，需要重新确认该项能力。

六、其他需要留意的边界情况

除了上述几类高频问题，还有一些容易被忽视的配置细节也可能导致事务行为偏离预期。

首先是事务管理器不生效的问题。在多数据源场景下，如果没有明确指定事务管理器，Spring可能选择了错误的事务管理器，导致注解虽然存在但实际上没有管理目标数据源的事务。此时需要通过@Transactional的transactionManager属性显式指定。

其次是数据库引擎不支持事务。例如在MySQL中使用MyISAM存储引擎时，事务特性本就不存在，无论应用层如何配置都不会产生回滚效果。确保业务表使用支持事务的存储引擎是基本前提。

另外，Spring Boot的自动配置虽然简化了事务管理器的注册，但一旦项目手动配置了多个DataSource或者引入了自定义的事务管理器Bean，就需要特别关注默认事务管理器的选择逻辑是否正确。

总结

Spring事务失效的原因大多是机制性而非业务性的。同类内部调用绕过代理、private方法无法被增强、异常被吞掉、受检异常默认不回滚、REQUIRES_NEW独立提交后无法回补，这些问题在代码评审阶段并不容易被一眼看出，但一旦在生产环境触发，定位成本往往很高。

理解这些场景的底层原理，比单纯记住“事务会失效”更为重要。开发者在编写事务相关代码时应形成几个关键习惯：避免同类this调用、保持代理可见性、异常要传播到代理层、统一回滚异常类型、谨慎使用REQUIRES_NEW并优先考虑NESTED。只有在理解代理机制与事务传播模型的基础上，才能让声明式事务真正可靠地为数据一致性服务。