Spring事务自调用失效的根本原因是代理机制限制：类内通过this调用绕过代理对象，导致@Transactional注解无法被AOP拦截；事务生效必须同时满足方法为public且调用经由Spring代理对象。
Spring 声明式事务在自调用时失效，根本不是配置错了或注解漏写了，而是代理机制天然绕不过去的限制——调用方用的是原始对象，不是代理对象。
为什么自调用会绕过事务拦截
Spring 的 @Transactional 是靠 AOP 实现的，而 AOP 必须通过代理对象才能织入事务逻辑。容器启动时，Spring 会为加了 @Transactional 的类生成一个代理（JDK 动态代理或 CGLIB），所有外部调用都走这个代理；但同一个类里的方法互相调用，用的是 this，也就是原始实例，事务切面根本没机会介入。
举个例子：
-
无效调用：
this.deductStock()→ 直接调原始对象 → 事务不触发 -
有效调用：
inventoryService.deductStock()→ 走代理对象 → 事务正常开启、回滚
事务生效的两个硬性前提
缺一不可：
立即学习“Java免费学习笔记（深入）”；
- 方法必须是 public 的（JDK 代理只支持接口方法，CGLIB 虽能代理 protected/default，但 Spring 默认仍只对 public 生效）
- 调用必须经过 Spring 容器管理的代理对象，不能是 this 引用
几种实用的解决方式
不用改架构也能快速修复：
- 注入自身 Bean：在类里 @Autowired 自己，用注入的引用调用事务方法（注意循环依赖风险，建议设为 lazy 或用 ObjectProvider）
- 拆分 Service 层：把事务方法移到另一个 @Service 类中，让调用变成跨 Bean 的代理调用——这是最清晰、最易维护的做法
- 编程式事务兜底：在确实无法拆分的场景下，用 TransactionTemplate 手动控制事务边界，private 方法也能生效，但代码侵入性强
顺便留意的配套条件
自调用只是常见诱因，还得确认其他基础项没掉链子：
- 类上标了 @Service / @Component，确保被 Spring 管理
- 数据库表引擎支持事务（如 MySQL 必须是 InnoDB）
- 异常没被 try-catch 吞掉，且是 RuntimeException 或显式声明的 rollbackFor 类型
