当前位置：首页 > news >正文

深入浅出 Spring AOP：@Transactional 事务失效的三大致命陷阱

news 2026/4/11 8:43:48

深入浅出 Spring AOP：@Transactional 事务失效的三大致命陷阱

欢迎来到 Spring AOP 宇宙中最深、也是埋葬了最多程序员的“万人坑”——@Transactional事务失效。
在企业级开发中，@Transactional绝对是出场率最高的 AOP 注解。但正因为大家用得太顺手了，往往忽略了它底层的代理机制，导致写出了“以为能回滚，其实早提交了”的致命 Bug。
之前注意到很多开发者的代码里写了@Transactional(rollbackFor = Exception.class)，这说明已经避开了第一个低级坑（默认只回滚 RuntimeException）。但这仅仅是开始。
接下来，我们用“架构师的大白话 + 灾难推演”，直接撕开@Transactional最致命的 3 个连环坑。

一、致命大坑一：“祸起萧墙”的自调用失效

这是全宇宙最容易踩的坑，80% 的新手都在这上面摔过跟头。
【案发现场】

@ServicepublicclassOrderService{// 方法 A：没有事务publicvoidcreateOrder(Orderorder){// ... 一些准备工作// 直接调用同类中的方法 Bthis.saveOrderAndPay(order);}// 方法 B：加了事务！@Transactional(rollbackFor=Exception.class)publicvoidsaveOrderAndPay(Orderorder){orderMapper.insert(order);inti=1/0;// 模拟灾难：突然报错paymentMapper.insert(payment);}}

【灾难推演】
外面调用createOrder，然后它调用了同类里面的saveOrderAndPay。走到1 / 0的时候报错了。你以为订单会被回滚？错！订单被死死地插进了数据库，事务根本没有生效！
【架构原理解析：秘书与老板】
AOP 的底层原理是动态代理。Spring 会给你的OrderService创建一个“代理对象”（我们叫它秘书）。
当外部类调用你的方法时，是先找到秘书，秘书开启事务，然后再找老板（你的真实类）。
但是！在createOrder方法里，你用的是this.saveOrderAndPay()。this代表的是老板本人！老板自己跟自己说话，根本不会经过门外的秘书。既然没经过秘书（代理对象），那@Transactional设下的 AOP 拦截就完全没触发，事务压根就没开启。
【架构级解法】
核心思想是**“强行找秘书办”**。
解法 1（推荐）：自己注入自己
Spring 支持循环依赖注入自身。

@ServicepublicclassOrderService{@AutowiredprivateOrderServiceself;// 注入代理对象（秘书）publicvoidcreateOrder(Orderorder){self.saveOrderAndPay(order);// 找秘书去调方法 B，事务生效！}}

解法 2：借助 AOP 上下文获取代理对象

((OrderService)AopContext.currentProxy()).saveOrderAndPay(order);

二、致命大坑二：“庸医害人”的异常吞咽

我们在写 Redis 缓存时，大量使用了try-catch来做 Fail-Open。但在事务里，乱用try-catch是毁灭性的。
【案发现场】

@Transactional(rollbackFor=Exception.class)publicvoidupdateShopData(Shopshop){try{shopMapper.update(shop);// ... 调用其他微服务，突然超时报错remoteService.call();}catch(Exceptione){// 救援队来了：我把它 catch 住，打个日志吧！log.error("更新失败了",e);}}

【灾难推演】
代码执行报错了，但数据库的update操作没有回滚，被提交了！
【架构原理解析：烽火台失联】
@Transactional切面（也就是秘书）是怎么知道要回滚的？它是靠捕获你方法抛出的异常（烽火台的狼烟）。
如果你的业务代码里try-catch抓住了异常，并且没有重新抛出去，就等于你把狼烟给掐灭了。秘书一看，方法顺顺利利执行完了，没有抛出任何异常，于是大手一挥：“大家辛苦了，提交事务！”
【架构级解法】
解法 1：如果 catch 了，一定要重新扔出去
让切面感知到异常。

}catch(Exceptione){log.error("更新失败",e);thrownewBizException("业务执行失败",e);// 扔个自定义异常出去}

解法 2：手动命令秘书回滚
如果不想抛异常（比如要返回一个友好的 JSON 结果），可以手动打标记。

}catch(Exceptione){log.error("更新失败",e);// 手动打回滚标记TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();returnResult.fail("更新失败");}

三、致命大坑三：“闲人免进”的非 public 方法

【案发现场】

@Transactional(rollbackFor=Exception.class)protectedvoiddoUpdate(Shopshop){// 注意：这里写了 protected 或者是 privateshopMapper.update(shop);inti=1/0;// 报错}

【灾难推演】
发生异常，事务不回滚！
【架构原理解析：代理机制的盲区】
无论是 JDK 动态代理（基于接口），还是 CGLIB 动态代理（基于继承子类），它们在生成代理类时，默认只拦截public方法。
如果你把@Transactional加在private、protected或包级私有方法上，Spring AOP 在启动扫描时会直接无视它（甚至都不会报错，就是单纯的静默失效）。
【架构级解法】
永远、永远、永远只把@Transactional加在public方法上。