Spring Boot中@Transactional传播行为详解

Spring Boot中@Transactional事务失效的根源往往不在MyBatis本身，而在于对Spring AOP代理机制（仅拦截public方法）、事务传播行为（如REQUIRED与REQUIRES_NEW在嵌套调用中的关键差异）、SQL执行路径（是否通过@MapperScan托管的Mapper接口）等底层原理的理解偏差；本文直击开发中高频踩坑点——从同类方法直接调用绕过代理、内层异常导致整链路回滚、REQUIRES_NEW引发的数据幻觉，到NOT_SUPPORTED下仍触发间隙锁等反直觉现象，帮你穿透表层注解，真正让事务按预期工作。

MyBatis事务不生效？先看@Transactional是否作用在public方法上

Spring AOP代理默认只拦截public方法，如果把@Transactional加在private、protected或包级方法上，事务根本不会启动——连日志都不会打。这不是MyBatis的问题，是Spring代理机制的硬限制。

实操建议：

• 检查目标方法是否为public，且未被final修饰
• 避免在同一个类内调用本类的@Transactional方法（比如serviceA.method1()内部直接调this.method2()），这会绕过代理，事务失效
• 若必须同类调用，考虑注入自身Bean：@Autowired private ServiceA self;，再用self.method2()

Propagation.REQUIRED vs Propagation.REQUIRES_NEW：嵌套调用时行为差异极大

Propagation.REQUIRED（默认）复用当前事务，没有就新建；Propagation.REQUIRES_NEW则总是挂起当前事务、开新事务。两者在异常回滚、数据库连接、日志一致性上表现完全不同。

常见错误现象：

• 用REQUIRED时，内层方法抛异常，外层没捕获，整个事务回滚——但你可能只想回滚内层
• 用REQUIRES_NEW时，内层事务提交后，外层事务仍可回滚，导致“已提交却消失”的数据幻觉
• 内层REQUIRES_NEW方法里查不到外层刚insert但未commit的数据（隔离级别影响）

示例场景：订单创建后发通知，通知失败不应导致订单回滚：

@Transactional(propagation = Propagation.REQUIRED)
public void createOrder(Order order) {
    orderMapper.insert(order);
    notifyService.sendAsync(order); // 这里用REQUIRES_NEW更安全
}

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void sendAsync(Order order) {
    // 即使这里异常，订单数据不受影响
    notificationMapper.insert(new Notification(order));
}

MyBatis执行SQL后事务未提交？检查是否漏了@MapperScan或SqlSession生命周期

事务由Spring管理，但MyBatis操作需通过Spring托管的SqlSession才能参与事务。如果手动new SqlSession，或Mapper接口没被@MapperScan扫描到，SQL会走自动提交模式（auto-commit=true），@Transactional完全无效。

实操建议：

• 确认配置类或启动类上有@MapperScan("com.example.mapper")，路径要精确匹配
• 不要在代码里写sqlSessionFactory.openSession()，全部使用@Mapper接口注入
• 检查Mapper接口方法是否返回void或受影响行数——返回List或Optional不影响事务，但若误配了ResultMap导致查询失败，可能掩盖事务问题

Propagation.SUPPORTS和Propagation.NOT_SUPPORTED：读多写少场景下的轻量选择

这两个传播行为常被忽略，但在高频查询、缓存预热、日志记录等只读场景下能显著降低事务开销。它们不强制开启事务，也就避免了不必要的连接占用和锁竞争。

关键区别：

• SUPPORTS：有事务就加入，没事务就非事务执行——适合“可有可无”的读操作，如统计报表预加载
• NOT_SUPPORTED：主动挂起当前事务，以非事务方式执行——适合明确不能进事务的操作，如写本地日志文件、调用外部HTTP接口
• 两者都要求方法内不能出现INSERT/UPDATE/DELETE，否则可能报Cannot execute update in a read-only transaction

注意：MySQL默认隔离级别是REPEATABLE READ，即使NOT_SUPPORTED，查询仍可能触发间隙锁——这不是传播行为的问题，而是存储引擎层面的机制。

事务传播不是开关，是上下文协商。Propagation参数选错，轻则逻辑错乱，重则数据不一致。最常被忽略的是：事务边界和SQL执行路径是否真正对齐——别只盯着注解写了没，要看它到底有没有落到执行SQL的那个对象实例上。

今天关于《Spring Boot中@Transactional传播行为详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！