private方法加@Transactional，事务为什么没生效？

一、先厘清一个常见误区

在很多技术社区里流传着一种说法：“private方法上加@Transactional，事务肯定不会生效。”这句话听起来斩钉截铁，但如果面试时你只回答“不生效”，往往会被追问一句“为什么”，而多数人答不上来。更严谨的表述应该是：在Spring默认的代理模式下，private方法上的@Transactional不会生效；但换一种织入方式，它是可以生效的。

所以要讨论这个问题，必须先限定前提——我们接下来分析的是“默认情况”，也就是基于代理的事务管理机制。理解了默认机制为何失效，才能理解为什么换一种模式就能生效。

二、排除几个似是而非的解释

在深入机制之前，先把几个常见的错误归因排除掉，避免思路跑偏。

误解一：Java不允许在private方法上加注解。
不是。@Transactional的@Target包含METHOD，并不限制方法的可见性。编译器不会因为你把注解放到private方法上而报错，注解本身是合法的元数据。

误解二：Spring解析注解时出了Bug。
也不是。同一个注解放在public方法上就能正常工作，说明注解解析逻辑本身没有问题，问题出在“注解被解析之后，事务逻辑有没有机会被执行”。

误解三：数据库层面限制了方法可见性。
更不是。数据库根本不知道Java方法是什么访问修饰符，它只关心连接、事务边界和SQL语句。访问修饰符是JVM层面的概念，与数据库无关。

排除这些之后，问题的焦点就收敛到一个方向：Spring事务到底是怎么“挂”到你的方法上的？

三、Spring事务的真正工作方式：代理对象

很多人对Spring事务的心智模型是这样的：扫描到@Transactional注解，读取配置，然后给这个方法开启事务。这个模型是错的。

Spring真正做的事情是：为你的原始Bean生成一个代理对象，由代理对象来包装原始Bean。 注解只是元数据，它告诉Spring“哪些方法需要事务”，但真正执行事务控制的不是注解本身，而是代理对象内部的拦截器。

调用链路大致如下：

1. 外部代码调用你的方法时，拿到的是代理对象，而不是原始Bean；
2. 代理对象内部持有一个事务拦截器（TransactionInterceptor）；
3. 拦截器检查当前被调用的方法是否配置了事务；
4. 如果有配置，调用事务管理器开启事务；
5. 执行你的业务代码；
6. 正常返回则提交事务，抛出异常则按配置回滚。

这个链路里有一个关键前提：方法调用必须经过代理对象。 只有经过代理，拦截器才有机会在方法执行前后插入事务逻辑。

四、private方法为什么在默认模式下失效

理解了代理机制，private方法失效的原因就清楚了，它至少涉及两个层面的问题。

1. 代理对象无法“覆盖”private方法

Spring默认使用基于接口的JDK动态代理，或基于继承的CGLIB代理。无论哪一种，代理的本质都是“在外层包一层”：

• JDK动态代理通过实现同一接口来拦截方法调用，private方法不属于接口，自然无法被拦截；
• CGLIB通过生成子类来覆盖方法，而private方法对子类不可见、不可覆盖，也就无法被重写拦截。

换句话说，代理对象根本没有能力“接管”private方法的调用，事务拦截器也就没有机会介入。

2. 类内部自调用不经过代理

即使方法不是private，只要调用发生在同一个类的内部（比如一个public方法直接调用本类的另一个带注解方法），调用走的是this，而不是代理对象，同样会绕过拦截器。这是自调用失效的经典场景，和private方法失效在根因上是同源的——调用没有经过代理。

private方法通常只在类内部被调用，天然处于“代理覆盖不到”的位置，所以默认模式下事务不生效，是代理机制的必然结果，而不是注解解析的问题。

五、让private方法事务生效的思路：AspectJ织入

既然默认模式依赖代理，那么绕开代理、直接修改字节码，就能让private方法也带上事务逻辑。这就是AspectJ织入模式的思路。

配置方式是在启用事务管理时指定织入模式为AspectJ：

@Configuration
@EnableTransactionManagement(mode = AdviceMode.ASPECTJ)
public class TxConfig {
    // 事务管理器等配置
}

在这种模式下，事务逻辑不再依赖运行时代理对象，而是在编译期或类加载期直接织入字节码，把事务通知插入到方法调用的位置。由于不经过代理，private方法同样可以被织入事务逻辑，自调用场景也能覆盖。

需要说明的是，这种模式需要相应的织入工具链支持（编译期或加载期织入），配置和构建复杂度高于默认代理模式，因此它更适合有明确需求的场景，而不是默认推荐方案。它的价值在于帮助我们理解：事务失效的根因是“调用未经过代理”，而不是“注解不能加在private方法上”。

六、实践中的检查清单

在实际项目中排查事务不生效的问题，可以按以下顺序自查：

1. 方法是否经过代理对象调用？ 外部调用正常，类内部自调用要警惕；
2. 方法可见性是否阻碍代理？ private、final方法在默认代理模式下无法被覆盖拦截；
3. 是否配置了正确的织入模式？ 需要覆盖private或自调用时，考虑AspectJ织入；
4. 异常类型是否符合回滚规则？ 默认只对运行时异常回滚，受检异常需显式配置；
5. 事务管理器是否与数据源匹配？ 多数据源场景下容易配错。

七、小结

回到最初的问题：private方法加@Transactional，事务为什么没生效？答案不是“注解无效”，也不是“Spring有Bug”，而是默认的代理机制无法拦截private方法的调用。注解只是声明，代理才是执行事务的载体；调用不经过代理，注解写得再正确也无济于事。

理解这一点，既能避免人云亦云的绝对化结论，也能在需要时选择合适的织入模式突破限制。技术判断的价值，往往就体现在这种“限定前提、说清机制”的严谨里。