同类方法调用事务失效的根本原因是this调用绕过代理对象，导致AOP切面不生效；推荐将方法拆分至独立Service类并通过依赖注入调用，确保事务按预期工作。

同类方法调用事务失效的根本原因

Spring 的 @Transactional 依赖 AOP 代理机制生效。当一个类中的方法 A 直接调用本类的另一个标注了 @Transactional 的方法 B（即 this.methodB()），JVM 执行的是原始对象的方法，绕过了 Spring 创建的代理对象，事务切面根本不会被触发。无论 B 方法声明了 REQUIRES_NEW 还是 NESTED，都形同虚设。

推荐修复方式：拆分到独立 Service 类

这是最清晰、可维护性最强、也最符合 Spring 设计哲学的做法。把需要事务控制的方法移到另一个被 Spring 管理的 Bean 中，再通过依赖注入调用。

• 确保目标类使用 @Service 或 @Component 注解，由 Spring 容器管理
• 调用方通过 @Autowired 或构造器注入该 Bean，保证走的是代理对象
• 事务传播行为、回滚规则等都能按预期工作

例如：将扣减库存逻辑从 OrderService 拆出为 StockService，createOrder() 中通过 stockService.decreaseStock() 调用，事务即可正常开启和隔离。

替代方案：通过代理对象调用自身方法

若暂时无法重构类结构，可启用代理暴露并手动获取当前代理：

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• 在启动类或配置类上添加 @EnableAspectJAutoProxy(exposeProxy = true)
• 在方法内使用 AopContext.currentProxy() 强转后调用：((OrderService) AopContext.currentProxy()).decreaseStock()
• 需引入 spring-boot-starter-aop 依赖

注意：这种方式耦合度高、可读性差，仅建议临时应急，不推荐长期使用。

不推荐但偶见的写法：注入自身 Bean

在类中注入自己（@Autowired private OrderService self），再用 self.methodB() 调用。这看似简洁，实则存在隐患：

• 可能引发循环依赖（尤其在构造器注入场景）
• 若类未被正确代理（如用了 final 方法或非 public），依然会失效
• 语义上“自己调自己”违反单一职责，掩盖了设计问题

它只是把自调用换成了代理调用，没解决逻辑边界混乱的本质。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南