当前位置：首页 > 文章列表 > 文章 > java教程 > @Transactional 失效复盘：自调用、异常回滚和异步线程别再踩坑

@Transactional 失效复盘：自调用、异常回滚和异步线程别再踩坑

来源：17golang Java频道原创 2026-06-04 14:52:25 0浏览收藏

这篇写 Spring 项目里最容易被误判的 Java 事务问题：方法上明明加了 @Transactional，线上却出现数据半提交、回滚没生效、库存扣了订单没保存。最后查下来，不是数据库坏了，而是事务方法根本没经过 Spring 代理。

本文适用于 Java 17/21、Spring Boot 3.x、Spring Framework 6.x。资料只用于核对事实：Spring 声明式事务默认基于 AOP proxy；默认情况下自调用不会触发事务增强；默认回滚规则是 RuntimeException/Error 回滚，checked exception 不自动回滚。正文按生产复盘写，不照搬官方文档。

Spring Transactional 失效排查思维导图 — 脑图：事务失效要从代理机制、异常规则、线程边界和测试闭环一起看。

业务场景：订单保存了，明细没回滚

订单提交接口会保存主单、保存明细、扣库存。某次库存服务抛出业务异常后，主单数据留在库里，明细和库存状态却不一致。代码里 saveOrder() 明明加了 @Transactional，一开始大家都怀疑事务传播或数据库隔离级别。

真正原因更朴素：入口方法在同一个类里用 this.saveOrder() 调了事务方法。这个调用没有经过 Spring 代理，TransactionInterceptor 根本没机会工作。

问题复现：自调用绕过代理

把一个 @Transactional 方法放在 Service 里，然后由同类普通方法直接调用它，事务不会按你想的方式开启。因为 Spring 默认 proxy 模式只拦截从代理对象进来的外部调用。

Spring Transactional 失效诊断流程 — 排查流程：先确认调用有没有进入代理，再看异常和线程边界。

踩坑原因：把注解当成编译期魔法

@Transactional 不是贴上就生效的编译器指令。它依赖 Spring 容器创建代理对象，并在方法调用进入代理时开启、提交或回滚事务。private 方法、final 方法、自调用、对象自己 new 出来，都可能绕过这个机制。

另一个常见误区是 checked exception。默认情况下，Spring 只对运行时异常和 Error 标记回滚。你抛了自定义 checked exception，如果没有写 rollbackFor，事务可能会提交。

代码案例：把事务边界拆清楚

下面的对比是我最推荐的结构：Facade 负责编排，TxService 负责事务边界。事务方法由另一个 Spring Bean 调用，确保经过代理。

Spring Transactional 自调用代码对比 — 重点不是多拆类，而是让事务入口清晰、可测试、可拦截。

@Service
public class OrderFacade {
    private final OrderTxService txService;

    public void submit(OrderCommand command) {
        txService.createOrder(command);
        // 事务外做通知、埋点、非关键远程调用
    }
}

@Service
public class OrderTxService {
    @Transactional(rollbackFor = Exception.class)
    public void createOrder(OrderCommand command) throws OrderCreateException {
        orderRepository.save(command.toOrder());
        orderItemRepository.saveAll(command.toItems());
        inventoryRepository.freeze(command.skuId(), command.quantity());
    }
}

如果你确实需要同类内调用，有 AspectJ 模式、自注入代理等办法，但我一般不优先推荐。生产项目更需要清楚的事务边界，而不是让新人猜这次调用有没有经过代理。