private方法加@Transactional，事务为何失效？

一、一个流传很广、但只对了一半的结论

“private 方法上加 @Transactional，事务不生效”——这句话在技术社区流传极广。不少人把它当成定论背下来，面试时脱口而出“不生效”，结果反而暴露了自己对事务机制理解得不完整。

严谨的表述应该是：在默认的代理模式下，它不生效；如果改用编译期或类加载期的字节码织入方式，它可以生效。要理解这句话，必须先弄清楚声明式事务到底是怎么工作的。

二、先排除三个常见误解

在回答“为什么”之前，先把几个似是而非的解释排除掉：

1. 是 Java 语法不允许在 private 方法上加注解吗？ 不是。这类注解的 @Target 元数据包含 METHOD，并不限制方法可见性，编译器不会报错，运行期反射也能正常读到该注解。
2. 是框架的注解解析有 Bug 吗？ 不是。把同一个注解原封不动挪到 public 方法上，事务立即生效，说明解析链路本身没有问题。
3. 是数据库层面的问题吗？ 更不是。数据库只认识 SQL 与连接上的事务边界，它根本不知道 Java 方法有什么访问修饰符。

排除了这些表象原因后，问题一定出在事务的实现机制上。

三、声明式事务的真正执行者：代理对象

很多人对事务注解的直觉理解是这样的：

框架扫描到 @Transactional → 读取注解配置 → 给这个方法开启事务。

这个理解是错的。事务注解本身只是元数据，它自己不会执行任何代码。以主流的 IoC/AOP 框架为例，容器在启动阶段会为包含事务方法的 Bean 生成一个代理对象，外部调用者拿到的其实是这个代理，而不是原始对象。真实的调用链路是：

1. 外部代码调用目标方法，实际进入的是代理对象；
2. 代理内部的事务拦截器先拦截调用，检查目标方法及其所在类是否配置了事务属性；
3. 如果有，就通过事务管理器开启事务；
4. 再去调用原始对象的业务方法；
5. 方法正常返回则提交事务；抛出异常则按配置回滚或提交，最后恢复连接状态。

用伪代码表示代理的职责大致是：

// 代理对象中的方法（示意）
public Object businessMethod(Object... args) {
    TransactionStatus tx = txManager.getTransaction(def); // 1. 开启事务
    try {
        Object result = target.businessMethod(args);      // 2. 调用原始方法
        txManager.commit(tx);                             // 3. 无异常则提交
        return result;
    } catch (RuntimeException e) {
        txManager.rollback(tx);                           // 4. 默认对运行时异常回滚
        throw e;
    }
}

看到这里，根本原因已经呼之欲出：事务生效的前提，是方法调用经过了代理对象。注解只负责“告诉框架哪里需要事务”，真正负责开关事务的是包裹在外面的代理。

四、为什么 private 方法注定逃不过代理拦截

默认模式下，主流框架生成代理基本只有两条路：

1. 基于接口的动态代理：运行时生成一个实现了目标接口的代理类。它只能拦截接口中声明的方法，实现类里的 private 方法完全触达不了。
2. 基于继承的字节码生成代理：运行时生成目标类的子类，通过重写父类方法来插入拦截逻辑。

第二条路看似有机会覆盖 private 方法，但 Java 语言层面就把它堵死了：private 方法不参与多态。它采用静态绑定，子类根本“看不见”父类的 private 方法，也就无从重写。子类里即使写一个同名方法，也只是另一个独立方法，父类内部的 this 调用永远绑定到父类自己的方法体，不会经过子类。

除了“拦不住”，还有一层“读不到”：主流框架的事务属性解析器默认只识别 public 方法上的事务注解。也就是说，即便某个私有方法真的被调用到了，拦截器去查事务配置时，得到的也是“无事务配置”。

最后还有一个高频伴生问题——自调用。即使方法改成了 public，如果它是被同一个对象内部的 this.method() 调用的，这次调用同样不经过代理，而是直接命中原始对象，事务依然不生效。这也说明“事务失效”从来不只是方法可见性一个维度的问题。

五、默认模式下的正确修法

理解了原理，解法就很自然了——让调用重新经过代理：

• 把方法可见性改为 public，并确保从外部 Bean 发起调用；
• 将事务逻辑拆分到独立的 Bean，通过依赖注入组合调用；
• 同一个类内确需自调用时，注入自身代理，或使用框架提供的“获取当前代理”的上下文工具（通常还需要显式开启对应开关）；
• 或者干脆放弃声明式，改用编程式事务模板，手动控制事务边界：

public void updateOrder(Order order) {
    txTemplate.execute(status -> {
        orderMapper.update(order);
        pointMapper.deduct(order.getPoints());
        return Boolean.TRUE;
    });
}

六、另一条路：字节码织入，让 private 方法的事务真正生效

回到开头那个“反直觉”的结论：private 方法上的事务注解并非绝对无效。如果实现方式从“运行期代理”切换为“字节码织入”，结果就不同了。

这类方案分为编译期织入与类加载期织入两种：前者由构建插件在编译阶段直接修改字节码，后者通过 Java Agent 在类加载阶段完成改写。无论哪种，框架都是把事务逻辑织入方法体内部或方法调用点，不再依赖“生成子类 + 重写方法”的代理套路。private 方法的方法体本身就能被改写，事务逻辑自然可以生效。

使用上通常分两步：

1. 引入对应的织入支持：编译期织入由构建插件在编译时完成；类加载期织入则需要在启动参数中挂载 Agent；
2. 在开启事务管理的配置注解上，把织入模式从默认的“代理模式”切换为“织入模式”。

切换之后，框架不再为 Bean 生成运行时代理，而是在字节码层面直接完成事务逻辑的植入。

不过，织入模式并不是“免费午餐”，工程上需要权衡：

• 构建链路变复杂：需要额外的织入插件或 Agent 参数，本地与持续集成环境必须统一；
• 调试成本上升：事务逻辑被织进字节码，断点与堆栈不再“一眼即懂”；
• 团队认知成本：如果团队成员都按“代理模式”的心智模型理解事务，切换后容易产生理解偏差。

因此，多数团队的务实选择仍然是：遵守“事务方法用 public、避免自调用”的编码规范，把织入模式作为特殊场景下的备选手段。

七、如何给出一个有深度的回答

把上面的分析压缩成一句话，就是面试或技术评审中值得给出的表述：

默认的代理模式下，private 方法上的事务注解不生效——因为事务由代理对象实现，而 private 方法不参与多态、无法被代理重写，且事务属性解析默认只识别 public 方法；但如果切换为编译期/类加载期的字节码织入模式，事务逻辑可以直接织入方法体，private 方法的事务就能生效。

顺便延伸几个同源的失效场景，它们与 private 失效共享同一个根因——调用没有走到“带事务逻辑”的那份代码：

• 方法被 final、static 修饰，无法被子类代理重写；
• 异常在方法内部被 try-catch 吞掉，拦截器感知不到；
• 抛出的是受检异常，而默认回滚规则只覆盖运行时异常与 Error；
• 传播行为配置不当，例如内层方法以 NOT_SUPPORTED 方式挂起了事务；
• 事务方法内另起线程执行 SQL，两个线程不共享事务上下文。

八、总结

• 事务注解只是元数据，真正执行事务的是代理对象，事务生效的前提是“调用经过代理”。
• private 方法不参与多态、无法被子类代理重写，且默认解析规则只识别 public 方法，因此在默认模式下必然失效。
• 字节码织入（编译期/类加载期）绕过了代理机制，让 private 方法的事务成为可能，但会抬高构建与维护成本。
• 与其记住“生效/不生效”的孤立结论，不如理解“注解 + 代理 + 调用链路”这条完整的因果链——遇到问题多思考、多实践，而不是人云亦云，这才是这类问题真正想考察的能力。