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%的业务事务正常生效彻底告别事务导致的线上数据不一致问题。