在 Spring Boot 项目中，事务管理看起来像是一件默认开启的事情：服务层方法加上 @Transactional，提交或回滚由框架完成。但真正遇到线上问题时，不少人会困惑：注解明明加了，为什么数据没有回滚？这通常不是注解写错，而是 Spring 事务管理的 AOP 基础设施没有真正生效。@EnableTransactionManagement 正是负责启动这套基础设施的关键注解。本文会从它与 Spring Boot 自动装配的关系讲起，再延伸到事务管理器选择、回滚规则以及常见失效场景，帮助你建立一套完整的事务排查与配置思路。
一、@EnableTransactionManagement 与 Spring Boot 自动装配的关系
@EnableTransactionManagement 并不是一个直接创建数据库事务的操作开关，它的本质是向容器注册事务代理相关的后处理器和拦截器。该注解通过 TransactionManagementConfigurationSelector 导入配置类，默认使用 PROXY 模式，在 Spring 容器中注册 TransactionInterceptor、BeanFactoryTransactionAttributeSourceAdvisor 以及 TransactionAttributeSource 等核心组件。正是因为有了这些组件，Spring 才能识别 @Transactional 注解，并生成带事务增强逻辑的代理对象。
在纯 Spring 环境中，如果希望使用声明式事务，通常必须在配置类上显式添加 @EnableTransactionManagement，否则 @Transactional 不会被 AOP 拦截。但 Spring Boot 对这一点做了明显简化。TransactionAutoConfiguration 会在类路径中存在 PlatformTransactionManager 时自动生效，并在满足条件的情况下启用事务管理。也就是说，当你引入 spring-boot-starter-jdbc 或 spring-boot-starter-data-jpa 后，即使不手动添加 @EnableTransactionManagement，框架也通常已经帮你配置好了。
那么手动添加的意义在哪里？主要体现在需要显式控制事务代理方式时。例如，如果希望使用 mode = AdviceMode.ASPECTJ，或者通过 proxyTargetClass = true 强制使用 CGLIB 代理，手动配置注解仍然是推荐做法。下面是一个最小化的手动开启示例。
@Configuration
@EnableTransactionManagement
public class TransactionConfig {
// 事务管理器通常由 Spring Boot 自动配置提供
}
二、事务管理器的选择与手动指定
事务管理器是事务生效的真正执行者。Spring Boot 会根据类路径中的依赖自动创建不同实现：如果使用 JDBC 或 MyBatis，通常创建 DataSourceTransactionManager；如果使用 JPA 或 Hibernate，则创建 JpaTransactionManager。在只有一个数据源的典型 Web 应用中，这种自动选择几乎不需要额外配置，@Transactional 可以直接使用默认事务管理器。
但在多数据源场景下，容器中可能存在多个 PlatformTransactionManager，此时 @Transactional 将无法确定应该使用哪一个，启动阶段甚至还可能抛出 NoUniqueBeanDefinitionException。解决思路是为其中一个事务管理器添加 @Primary，或者在使用 @Transactional 时通过 transactionManager 属性精确指定 Bean 名称。
自定义事务管理器的配置并不复杂，以下代码演示了如何手动创建并指定一个主数据源事务管理器。
@Bean
@Primary
public DataSourceTransactionManager transactionManager(DataSource dataSource) {
return new DataSourceTransactionManager(dataSource);
}
如果某些业务方法需要走另一个数据源的事务，可以给对应的事务管理器 Bean 命名，例如 secondaryTransactionManager，然后在方法上使用 @Transactional(transactionManager = "secondaryTransactionManager") 进行指定。这种做法比单纯依赖 @Primary 更加明确，也更适合多数据源业务流程相对独立的系统。
三、传播行为与异常回滚规则
事务传播行为决定了业务方法在遇到已有事务时应该怎么处理。默认的 REQUIRED 行为会复用当前事务，如果没有事务则新建一个。这是大多数增删改操作最常使用的策略。此外，REQUIRES_NEW 会暂停当前事务并开启一个独立新事务，常用于需要单独提交日志、审计记录等场景。正确理解传播行为可以避免出现内部方法回滚影响外部主流程，或者外部回滚但内部数据仍然保留的情况。
异常回滚规则同样容易踩坑。Spring 的声明式事务默认只对 RuntimeException 和 Error 进行回滚，受检异常不会触发回滚。很多业务代码在方法签名中抛出 Exception，却期望事务自动回滚，结果往往不符合预期。正确做法是显式配置 rollbackFor 属性，将需要回滚的异常类型明确指出来。
@Service
public class OrderService {
@Transactional(rollbackFor = Exception.class)
public void createOrder(Order order) {
orderMapper.insert(order);
orderItemMapper.insertList(order.getItems());
}
}
需要注意的是，rollbackFor 只决定哪些异常会触发回滚，不决定传播行为和隔离级别。在实际项目中，建议根据业务边界将查询方法设置为 readOnly = true，既能让底层数据源进行相应优化，也能从代码层面明确区分读写操作。例如报表查询、详情查询都可以通过 @Transactional(readOnly = true) 标记。
四、事务失效的高频场景与排查思路
第一个典型场景是同类方法自调用。Spring 事务本质依赖 AOP 代理对象完成增强，当在一个类内部使用 this.saveOrder() 调用另一个带 @Transactional 的方法时，调用不会经过代理对象，因此事务拦截器不会执行，导致注解完全失效。下面是一段问题代码。
@Service
public class OrderService {
public void addOrder(Order order) {
// 直接通过 this 调用，事务代理不生效
this.saveOrder(order);
}
@Transactional
public void saveOrder(Order order) {
orderMapper.insert(order);
int result = 1 / 0; // 模拟异常
}
}
解决这个问题的思路有三类：将 saveOrder 方法拆分到另一个 Spring Bean 中；在当前类中注入自身代理对象；使用 TransactionTemplate 编程式事务显式管理。对于复杂的局部事务控制，编程式事务往往比注解更加灵活。
第二个常见问题是方法不是 public。Spring 事务代理默认只拦截 public 方法，如果方法被定义为 package-private、protected 或 private，即使注解存在也不会生效。第三是异常被业务代码捕获后未重新抛出，事务管理器根本感知不到异常，自然也不会回滚。第四是数据库存储引擎不支持事务，例如 MyISAM 表不会真正回滚，需要确认表引擎为 InnoDB。
五、编程式事务与声明式事务的配合
声明式事务适合大多数业务场景，但在一些复杂流程中，事务边界可能无法只靠单方法注解表达。例如需要先执行一段数据库操作，再根据外部接口返回结果决定提交还是回滚，此时使用 TransactionTemplate 可以直接在方法体内控制事务范围。
编程式事务的核心思路是绕过 AOP 代理，由开发者主动调用事务管理器 API。下面是一个简单示例，它使用 TransactionTemplate 包裹一段插入逻辑，并根据执行结果手动设置回滚状态。
@Autowired
private TransactionTemplate transactionTemplate;
public void executeWithTransaction(Order order) {
transactionTemplate.execute(status -> {
try {
orderMapper.insert(order);
return null;
} catch (RuntimeException e) {
status.setRollbackOnly();
throw e;
}
});
}
这种方式的优势是粒度更细，可以精准控制事务边界，避免大方法长时间占用数据库连接。劣势是代码侵入性更强，重复模板代码较多。因此在实际项目中，建议以声明式事务为主，编程式事务为辅，只在声明式难以覆盖的局部或动态提交场景中使用。
总的来说，掌握 @EnableTransactionManagement 的作用、事务管理器的选择逻辑以及 @Transactional 的回滚规则，基本可以覆盖 Spring Boot 日常开发中的绝大多数事务问题。排查时不妨从代理是否生效、异常是否被吞、事务管理器是否唯一这三个方向依次确认，往往能快速定位根因。
Spring Boot声明式事务EnableTransactionManagement修改时间：2026-08-23 18:29:55