简介：很多开发者认为私有方法加@Transactional事务必然不生效，也有人认为注解本身会报错。本文从代理机制出发，厘清默认失效的根本原因，说明注解解析、调用链路与代理拦截之间的关系，并介绍编译期或类加载期织入这一例外路径，帮助读者建立完整认知。
在技术社区里，关于“私有方法上加 @Transactional 事务会不会生效”这个问题，一直存在大量争论。有人斩钉截铁地说“肯定不生效”，也有人表示“我试过，是可以生效的”。这两种说法其实都不够完整。更准确的表述应该是：在默认的代理模式下，私有方法上的 @Transactional 不会生效；但换一种织入方式，它确实可以生效。
面试时如果只回答“不生效”，往往会被认为理解不够全面。真正体现深度的回答，是先说明默认行为，再解释背后的机制，最后补充例外路径。本文就把这个问题彻底讲清楚。
在讨论“为什么不生效”之前，有必要先澄清几个容易跑偏的方向。
误解一：Java 不允许在私有方法上加注解？
不是。@Transactional 的 @Target 包含 METHOD，它并不限制方法的可见性。把注解放到 private 方法上，编译器不会报任何错误，注解也能正常存在于字节码中。
误解二：这是注解解析的 Bug？
也不是。同一个注解写在 public 方法上就能生效，说明解析逻辑本身没有问题，问题出在别的地方。
误解三：数据库层限制了私有方法？
更不是。数据库根本不知道 Java 方法的访问修饰符是什么，它只关心连接、SQL 和提交回滚指令。
排除了这些方向后，问题的焦点就集中到了一处：事务到底是怎么被“加”到方法上的？
很多人对 Spring 事务的直觉模型是这样的：
扫描到 @Transactional 注解 → 读取配置 → 给这个方法开启事务。
这个模型是错的。注解本身只是元数据，它不会自己执行任何逻辑。真正做事的是 Spring 容器在启动阶段为你生成的一个代理对象。
整体链路大致如下：
拦截器的执行步骤可以概括为：
因此，事务生效有一个硬性前提：方法调用必须经过代理对象。注解负责“声明”，代理负责“执行”。调用没走代理，注解写得再标准也没用。
默认模式下，Spring 使用的是基于接口或基于类的动态代理。这类代理有一个共同特征：它们只能覆盖（override）父类或接口中可被继承的方法。
私有方法有两个关键性质：
代理类在字节码层面无法“重写”一个私有方法，自然也就无法在它前后插入事务逻辑。换句话说，代理对象根本没有能力拦截对私有方法的调用。即使注解被扫描到，拦截器也没有入口。
此外还有一个更隐蔽的问题：自调用。即便方法是 public 的，如果它是在同一个类的另一个方法里被 this.xxx() 直接调用，这个调用也不会经过代理，事务同样不会生效。这与私有方法的失效原因在本质上是同一个——调用链路绕过了代理。
所以真正决定事务是否生效的，不是方法的可见性本身，而是这次调用有没有穿过代理边界。
如果换一种事务织入方式，结果就不同了。除了默认的代理模式，还可以选择编译期或类加载期织入的方式。它的思路不是生成代理对象，而是直接修改目标类的字节码，把事务逻辑“织”进方法体内部。
在这种模式下：
启用方式通常是在配置类上声明事务管理并指定织入模式，让容器在编译期或类加载期完成字节码增强。此时事务逻辑已经成为方法自身的一部分，调用不再需要穿过任何代理层。
需要强调的是，这是一个例外路径，并非常规做法。它引入构建期依赖，对编译流程有额外要求，调试和排查成本也更高。绝大多数业务代码仍然应该使用默认的代理模式。
基于以上分析，可以得出几条明确的工程建议：
第一，事务方法统一使用 public 修饰。 这不是“规范洁癖”，而是代理机制下的必然要求。私有方法和受保护方法在默认模式下无法被代理拦截。
第二，避免类内自调用。 如果确实需要在类内部复用事务逻辑，可以把事务方法抽到独立的 Bean 中，通过注入的方式调用，确保调用穿过代理。
第三，理解注解与执行的分工。 @Transactional 只表达“这个方法需要事务”，不负责“怎么开事务”。把这两件事分开看，很多困惑就迎刃而解。
第四，谨慎对待非默认织入模式。 它确实能解决代理模式的边界问题，但代价是构建复杂度和可维护性。只有在明确需要时才考虑。
“私有方法加 @Transactional 事务不生效”这句话，准确的说法应该是：在默认的代理模式下，由于代理无法覆写私有方法，调用不会经过拦截器，因此事务不生效。 它不是 Java 的限制，不是注解解析的 Bug，也不是数据库的问题，而是代理机制的必然结果。
理解这一点，比记住一句结论更重要。它让你在面对自调用失效、final 方法失效、非 public 方法失效这一系列问题时，能够用同一套逻辑去解释和排查，而不是逐个去背结论。
技术讨论最怕的就是人云亦云。把机制搞清楚，结论自然就站得住脚。