在 Spring Boot 工程中，声明式事务的核心入口就是 @EnableTransactionManagement。虽然 Spring Boot 默认已经通过自动配置悄悄帮我们开启了事务支持，但当你需要自定义代理方式、调整事务执行顺序或排除某些自动配置时，就必须手动理解并整合这个注解。不少项目在引入多数据源或自定义 Advisor 之后，事务突然不生效，根本原因往往出在注解的使用姿势和代理机制的错位上。
注解底层加载机制与自动配置关系
@EnableTransactionManagement 本身只是一个开关，它向容器中导入了 TransactionManagementConfigurationSelector，进而注册 ProxyTransactionManagementConfiguration 等配置类。这些配置类负责创建事务拦截器 TransactionInterceptor 和通知适配器，最终织入到带有 @Transactional 的 Bean 方法中。在纯 Spring 环境下，如果不加这个注解，事务功能完全关闭；但在 Spring Boot 中，TransactionAutoConfiguration 已经利用条件注解帮我们完成了等价操作。
当你显式写上 @EnableTransactionManagement 时，并不会与自动配置冲突，因为后者的内部同样使用了该注解并通过 @ConditionalOnMissingBean 控制。不过一旦你自定义了 PlatformTransactionManager 并且存在多个候选 Bean，自动配置可能失效，此时手动声明注解并明确指定事务管理器才是最稳妥的做法。理解这层关系，可以避免在排查“为什么事务没回滚”时盲目猜测。
从源码角度看，该注解有两个关键属性：proxyTargetClass 和 mode。proxyTargetClass 为 true 时强制使用 CGLIB 子类代理，为 false 则优先 JDK 动态代理；mode 可切换为 ASPECTJ 模式，但需额外依赖织入器。绝大多数 Spring Boot 项目保持默认即可，只有当你需要代理具体类而非接口时才需显式开启 CGLIB。
代理模式选择对事务生效范围的影响
Spring 的事务本质是基于 AOP 代理实现的。如果目标 Bean 实现了接口且 proxyTargetClass=false，容器会采用 JDK 动态代理，此时只有通过接口方法调用才能被拦截。若你在一个没有接口的实现类上标注 @Transactional 且未开启 CGLIB，启动阶段就会报错或事务完全不织入。相反，设置 @EnableTransactionManagement(proxyTargetClass = true) 可让 CGLIB 生成子类代理，直接代理类方法，覆盖更多场景。
另一个极易踩坑的点是“同类自调用”。例如在一个 Service 内部，方法 A 调用同为自身的 @Transactional 方法 B，由于调用发生在目标对象内部而非代理对象，事务拦截器根本不会被触发。很多开发者误以为只要加了注解就万事大吉，结果数据部分提交造成脏数据。解决办法包括将方法 B 抽到另一个 Bean、通过注入自身代理（如 @Autowired private Self self）调用，或采用 AspectJ 编译期织入彻底摆脱代理限制。
下面的示例展示了如何通过暴露代理来避免自调用失效。在配置类开启暴露代理后，方法内部通过 AopContext.currentProxy() 获取代理对象发起调用，从而保证事务切面生效。这种方式虽能解决问题，但增加了代码与 Spring AOP 的耦合，仅在确需保留同类调用结构时推荐使用。
@Configuration
@EnableTransactionManagement(proxyTargetClass = true, exposeProxy = true)
public class TxConfig {
@Bean
public PlatformTransactionManager transactionManager(DataSource ds) {
return new DataSourceTransactionManager(ds);
}
}
@Service
public class OrderService {
public void placeOrder() {
// 通过代理调用，事务才会生效
((OrderService) AopContext.currentProxy()).createOrder();
}
@Transactional
public void createOrder() {
// 数据库写入操作
}
}
与 Spring Boot 自动装配整合的最小实践
在标准的 Spring Boot Web 项目中，引入 spring-boot-starter-jdbc 或 spring-boot-starter-data-jpa 后，事务基础设施已经齐备。此时你甚至不需要写任何 @EnableTransactionManagement，只需要在业务方法上标注 @Transactional 即可。但如果你构建了多模块架构，且核心事务配置放在独立模块，就应当显式添加注解，防止不同模块的组件扫描顺序导致自动配置未覆盖到你的 Bean。
自定义事务属性时，建议配合 @Transactional 的 rollbackFor 明确指定异常类型。默认配置只在遇到运行时异常和 Error 时回滚，若业务层抛出受检异常（如 IOException），事务不会回滚，这常成为数据不一致的根源。在整合手动开启的 @EnableTransactionManagement 场景下，这一规则并不会改变，仍需开发者自行约束。
以下代码给出一种典型整合方式：在独立配置类声明注解并定义事务管理器，同时在业务层精确控制回滚边界。该写法兼容 Spring Boot 2.x 与 3.x，无需额外依赖，适合作为团队内部事务规范模板。
@Configuration
@EnableTransactionManagement
public class AppTransactionConfig {
@Bean
public PlatformTransactionManager txManager(DataSource dataSource) {
DataSourceTransactionManager manager = new DataSourceTransactionManager(dataSource);
// 可设置默认超时等全局属性
manager.setDefaultTimeout(30);
return manager;
}
}
@Service
public class AccountService {
@Transactional(rollbackFor = Exception.class, isolation = Isolation.READ_COMMITTED)
public void transfer(Long from, Long to, BigDecimal amount) throws BusinessException {
// 扣减与增加操作
if (amount.compareTo(BigDecimal.ZERO) <= 0) {
throw new BusinessException("金额非法");
}
// 持久化逻辑
}
}
最后需要提醒，当项目中存在多个 PlatformTransactionManager 实例时，必须在 @Transactional 中通过 value 或 transactionManager 指定名称，否则 Spring 会因找不到唯一管理器而启动失败。结合 @EnableTransactionManagement 的显式声明，可以让整个事务体系在 Spring Boot 中既灵活又可控。
Spring_BootEnableTransactionManagement事务管理修改时间：2026-08-15 08:30:27