企业官网建设流程全解析

Spring 事务不回滚？5 个容易忽略的事务失效场景

做Java开发这么多年，@Transactional事务注解可以说是我们每天都在用的功能。很多人觉得事务非常简单，加个注解就能保证数据一致性，不用过多深究。

但实际上，我线上排查过无数次数据不一致、脏数据残留的问题，绝大多数都是Spring事务静默失效导致的。最坑的是：代码不报错、日志无异常、功能正常跑完，就是数据不对，排查起来特别折磨人。

很多新手甚至工作两三年的开发，只知道用事务，却不清楚事务的生效条件。一旦遇到特殊场景，事务直接失效，出了线上BUG根本无从下手。

今天结合我多年线上排错经验，总结5个最容易被忽略的Spring事务失效场景，全部附带可复现代码、错误原因和修复方案，帮大家彻底杜绝事务失效导致的数据问题。

一、捕获异常后未手动回滚（最高频坑）

这是日常开发中出现概率最高的事务失效场景，没有之一。

Spring事务默认只对运行时异常（RuntimeException）和错误（Error）进行回滚。如果我们手动try-catch捕获了异常，没有主动抛出，Spring感知不到异常，就会认为业务正常执行，最终直接提交事务。

很多人为了保证接口不报错，习惯性全包try-catch，直接把事务彻底废掉。

失效错误代码：

@Transactional(rollbackFor = Exception.class) public void createOrder() { try { // 新增订单数据 orderMapper.insert(order); // 模拟业务异常 int i = 1 / 0; // 新增订单明细 itemMapper.insert(item); } catch (Exception e) { // 仅仅打印日志，未抛出异常，事务不会回滚 log.error("下单失败", e); } }

上面这段代码运行后，虽然控制台报错，但订单数据会成功入库，完全违背事务一致性。

正确修复写法：

要么捕获后手动回滚，要么重新抛出异常让Spring接管：

@Transactional(rollbackFor = Exception.class) public void createOrder() { try { orderMapper.insert(order); int i = 1 / 0; itemMapper.insert(item); } catch (Exception e) { log.error("下单失败", e); // 手动触发事务回滚 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); } }

二、方法访问权限非 public

这个坑很多资深开发都会踩。Spring事务是基于AOP动态代理实现的，非public方法无法被代理拦截，导致事务注解完全无效。

很多人写测试代码、内部方法时习惯用private、protected，百思不得其解为什么事务不生效。

失效示例：

// 私有方法，事务彻底失效 @Transactional private void saveData() { // 数据库操作... }

解决方式非常简单：保证事务方法必须是public 修饰，这是Spring事务生效的基础前提。

三、同类方法内部调用，AOP代理失效

这是线上最隐蔽的事务失效场景。在同一个类中，普通方法调用本类的事务方法，会导致事务完全不生效。

原因是Spring AOP代理只能拦截外部调用，内部this调用不会走代理对象，事务注解直接形同虚设。

失效错误代码：

@Service public class OrderService { public void submitOrder() { // 内部调用，不走代理，事务失效 this.doSave(); } @Transactional public void doSave() { orderMapper.insert(order); int i = 1 / 0; } }

报错后数据依旧入库，事务完全没有回滚。

解决方案：

拆分不同Service调用，或者通过自身代理Bean调用，避免原生this调用。

四、异常类型不匹配，触发不了回滚规则

很多人默认加了@Transactional就以为所有异常都会回滚，这是严重误区。

Spring默认只回滚RuntimeException，如果代码抛出普通Exception、IO异常、自定义检查异常，事务不会自动回滚。

错误写法（大概率失效）：

@Transactional public void fileHandle() throws Exception { // 抛出普通编译异常，事务不回滚 throw new Exception("文件处理失败"); }

标准通用写法（生产必用）：

// 捕获所有异常进行回滚 @Transactional(rollbackFor = Exception.class)

生产环境所有事务方法，统一配置rollbackFor = Exception.class，从根源避免异常不回滚问题。

五、事务传播机制使用不当导致失效

最后一个高阶坑：事务嵌套场景传播机制乱用，导致内层报错外层不回滚。

最典型的就是REQUIRES_NEW独立事务，内层新开事务回滚，完全不影响外层主事务，最终导致数据不一致。

核心业务场景尽量使用默认 REQUIRED，保证事务统一，非核心日志、记录类业务再使用独立事务。

个人总结与开发规范

复盘这么多线上事务BUG，我给团队定了三条铁律，基本彻底杜绝事务失效问题：

1、所有事务方法统一添加rollbackFor = Exception.class； 2、禁止本类内部调用事务方法，避免代理失效； 3、业务异常尽量不吞异常，如需try-catch必须手动回滚。

结语

Spring事务看似简单，实则暗藏很多细节坑。大部分线上脏数据、数据错乱问题，并不是代码逻辑BUG，而是事务静默失效导致的。

掌握这5种高频失效场景，日常开发严格规避，就能保证99%的业务事务正常生效，彻底告别事务导致的线上数据不一致问题。