SpringBoot 中 @Transactional 注解失效的 8 种常见场景与解决方案

一、SpringBoot 中 @Transactional 注解失效

@Transactional 是 Spring 框架中声明式事务管理的核心注解，但在实际开发中，由于配置不当、使用姿势错误等原因，常会遇到事务不生效的情况。本文将系统梳理 SpringBoot 项目中 @Transactional 注解失效的常见场景，并提供对应的排查思路与解决方案。

二、事务失效的常见场景

1. 方法访问权限非 public

Spring 的 AOP 代理（CGLIB 或 JDK 动态代理）默认只对 public 方法生效。如果 @Transactional 标注在 protected、private 或默认（包级私有）方法上，事务将不会开启。

示例代码：

java 复制代码

@Service
public class UserService {
    // ❌ 错误：private 方法，事务不生效
    @Transactional
    private void updateUserPrivate(Long id) {
        // ... 数据库操作
    }

    // ✅ 正确：public 方法
    @Transactional
    public void updateUserPublic(Long id) {
        // ... 数据库操作
    }
}

解决方案：

确保 @Transactional 注解的方法为 public。
如果必须使用非 public 方法，可考虑使用 AspectJ 模式（mode = AdviceMode.ASPECTJ），但配置较复杂，一般不推荐。

2. 方法在同一个类内部调用

Spring 的事务管理基于 AOP 代理。当一个类中的方法 A（无 @Transactional）调用同一个类中的方法 B（有 @Transactional）时，调用的是目标对象（this）的方法 B，而非代理对象的方法，因此事务注解不会生效。

示例代码：

java 复制代码

@Service
public class OrderService {
    public void createOrder(OrderDTO dto) {
        // 一些业务逻辑...
        this.updateInventory(dto.getProductId(), dto.getQuantity()); // ❌ 内部调用，事务不生效
    }

    @Transactional
    public void updateInventory(Long productId, int quantity) {
        // 扣减库存操作
        inventoryMapper.decrease(productId, quantity);
    }
}

解决方案：

方案一（推荐）： 将事务方法抽取到另一个 Service 中，通过注入调用。

方案二： 在自身类中注入自己的代理对象进行调用（需开启 @EnableAspectJAutoProxy(exposeProxy = true)）。

java 复制代码

@Service
public class OrderService {
    @Autowired
    private ApplicationContext context;

    public void createOrder(OrderDTO dto) {
        OrderService proxy = context.getBean(OrderService.class);
        proxy.updateInventory(dto.getProductId(), dto.getQuantity()); // ✅ 通过代理调用
    }
}

方案三： 使用 AopContext.currentProxy()（同样需开启 exposeProxy = true）。

3. 异常类型未被捕获或未被正确抛出

@Transactional 默认只在抛出 RuntimeException 和 Error 时回滚。如果方法抛出了受检异常（Checked Exception，如 IOException、SQLException），事务不会回滚。

示例代码：

java 复制代码

@Service
public class FileService {
    @Transactional
    public void processAndSave(String filePath) throws IOException { // 声明了受检异常
        // ... 文件处理
        dbMapper.insert(data); // 数据库操作
        if (someCondition) {
            throw new IOException("文件处理失败"); // ❌ 抛出受检异常，默认不回滚
        }
    }
}

解决方案：

方案一： 在 @Transactional 注解中明确指定回滚的异常类型。

java 复制代码

@Transactional(rollbackFor = Exception.class) // 所有异常都回滚
public void processAndSave(String filePath) throws IOException {
    // ...
}

方案二： 在方法内部将受检异常包装为 RuntimeException 抛出。

java 复制代码

try {
    // ... 可能抛出 IOException 的操作
} catch (IOException e) {
    throw new RuntimeException("处理失败", e); // 转换为运行时异常
}

4. 异常被方法内部捕获并未重新抛出

如果在事务方法内部捕获了异常，并且没有重新抛出，Spring 的事务拦截器就感知不到异常，因此不会触发回滚。

示例代码：

java 复制代码

@Transactional
public void batchUpdate(List<Item> items) {
    for (Item item : items) {
        try {
            itemMapper.update(item);
        } catch (Exception e) {
            log.error("更新失败: {}", item.getId(), e);
            // ❌ 仅记录日志，未重新抛出异常，事务不会回滚
        }
    }
}

解决方案：

如果希望某次失败不影响整体事务，需仔细设计业务逻辑。

如果希望任何失败都导致整体回滚，则要么不捕获异常，要么在 catch 块中重新抛出。

java 复制代码

catch (Exception e) {
    log.error("更新失败: {}", item.getId(), e);
    throw new RuntimeException("批量更新失败", e); // ✅ 重新抛出
}

5. 数据库引擎不支持事务

Spring 事务的本质是依赖数据库本身的事务支持。如果使用的数据库存储引擎不支持事务（例如 MySQL 的 MyISAM ），那么 @Transactional 注解将完全无效。

解决方案：

将数据库表的存储引擎切换为支持事务的引擎，如 MySQL 的 InnoDB 。
sql 复制代码
```
ALTER TABLE your_table ENGINE = InnoDB;
```

6. 方法被 final 或 static 修饰

由于 Spring AOP 代理机制（特别是 CGLIB）是通过生成目标类的子类来实现的，因此无法代理 final 方法（子类不能重写）和 static 方法（属于类而非实例）。

解决方案：

避免在需要事务管理的方法上使用 final 或 static 关键字。

7. 多数据源环境下未指定事务管理器

在配置了多个数据源（DataSource）和对应事务管理器（PlatformTransactionManager）的项目中，如果使用 @Transactional 时未通过 value 或 transactionManager 属性指定具体的事务管理器，Spring 可能无法正确绑定事务。

示例配置：

yaml 复制代码

# application.yml
spring:
  datasource:
    primary:
      jdbc-url: jdbc:mysql://localhost:3306/db1
    secondary:
      jdbc-url: jdbc:mysql://localhost:3306/db2

解决方案：

在 @Transactional 注解中明确指定要使用的事务管理器 Bean 名称。

java 复制代码

@Service
public class CrossDbService {
    @Transactional("primaryTransactionManager") // 指定主数据源的事务管理器
    public void operateOnPrimary() {
        // ... 操作主库
    }

    @Transactional("secondaryTransactionManager") // 指定次数据源的事务管理器
    public void operateOnSecondary() {
        // ... 操作从库
    }
}

8. 传播行为（Propagation）设置不当

@Transactional 的 propagation 属性定义了事务的传播行为。不当的设置可能导致事务不按预期开启或加入。

常见陷阱：

Propagation.NOT_SUPPORTED：以非事务方式执行，挂起当前事务。
Propagation.NEVER：必须在非事务环境下执行，否则抛出异常。
Propagation.SUPPORTS：如果当前存在事务则加入，否则以非事务方式执行。

解决方案：

根据业务场景仔细选择传播行为。默认值 Propagation.REQUIRED（如果当前没有事务，就新建一个事务；如果已存在，则加入）适用于大多数单方法事务场景。

三、排查事务失效的通用步骤

检查配置： 确认 @EnableTransactionManagement 已启用（SpringBoot 默认已开启）。
检查代理模式： 确认使用的是 CGLIB 代理（应对类代理）还是 JDK 动态代理（应对接口）。可通过 spring.aop.proxy-target-class=true 强制使用 CGLIB。

查看日志： 开启 Spring 事务调试日志，观察事务的开启、提交/回滚。

yaml 复制代码

logging:
  level:
    org.springframework.transaction.interceptor: TRACE
    org.springframework.jdbc.datasource.DataSourceTransactionManager: DEBUG

代码审查： 对照上述八大场景，逐一检查代码。
单元测试： 编写单元测试，在测试中故意制造异常，观察数据是否回滚。

四、总结

@Transactional 失效通常不是 Spring 的 Bug，而是由于对 AOP 代理机制、异常处理规则或数据库配置理解不深导致的。掌握这些常见场景，能在开发中有效避坑，在排查时快速定位问题。核心要点是：方法需 public、避免内部调用、异常要抛出、引擎要支持、多源需指定。