前天排查一个线上问题，代码里明明白白写着@Transactional(rollbackFor = Exception.class)，库存也扣了，可订单状态偏偏没更新，最后定位到是同一个类内部的this.updateStock()自调用，事务管理器压根没参与。类似的事我这些年见过不少，问题的根源几乎都指向同一个组件：TransactionManager。
这篇文章不打算复述官方文档，我想从一个踩坑者的角度，把 TransactionManager 的职责边界、选型逻辑、与@Transactional的配合机制，以及那些让事务静默失效的真实现场完整拆开讲一遍。适合被事务问题折磨过、或者想一次性把 Spring 事务底层搞明白的同学阅读；如果你是刚接触事务的新手，这篇文章也可以当作一份带导航的地图，顺着章节走下来，基本能绕开绝大多数高频的坑。
1. TransactionManager到底在管什么：把手工事务抽象成流水线
1.1 没有框架时，我们是怎么写事务的
如果有人问"事务管理很难吗"，你可能会说：不就是拿到 Connection，setAutoCommit(false)，执行 SQL，成功 commit，失败 rollback，finally 里 close 嘛。单看一个数据库连接确实不难，难的是当一堆业务方法互相嵌套、互相调用时，谁来维护这条完整的边界？多个 DAO 操作怎么保证用的是同一个物理连接？内层方法想回滚、外层方法想提交，最终听谁的？这些问题分散在手写代码里，很快就会变成一场灾难。
TransactionManager 就是用来把这套"生命周期管理"抽象出来的角色。在 Spring 里，它表现为PlatformTransactionManager接口，核心方法只有三个：getTransaction、commit、rollback。方法虽少，每一个背后都挂着一大堆资源绑定、传播逻辑、保存点和回滚标记。理解了这个接口，再看 Spring 事务的各种配置，会顺畅很多。
1.2 一次事务从开始到结束，TransactionManager 具体做了什么
以最常用的DataSourceTransactionManager为例，当你的方法上带有@Transactional，Spring 的TransactionInterceptor会执行下面的流程：
- 解析方法上的事务属性：传播行为、隔离级别、超时时间、只读标志、回滚规则，封装成一个
TransactionAttribute。 - 调用
transactionManager.getTransaction(transactionAttribute)。 - 如果当前线程还没有事务（由
TransactionSynchronizationManager维护），事务管理器会从这个DataSource里getConnection()，设置autoCommit = false，把连接绑定到当前线程的ThreadLocal中。 - 执行业务方法。方法内所有数据库操作通过
DataSourceUtils.getConnection(dataSource)获取连接，这个方法会优先从当前线程的ThreadLocal里取，而不是重新向连接池申请。这一步是关键：事务内所有 SQL 必须落在同一个物理连接上。 - 方法正常返回后，
TransactionInterceptor调用transactionManager.commit(status)；方法抛出异常时调用rollback(status)。提交前还有一轮TransactionSynchronization回调，给事件发布、缓存清理这类"紧跟事务成功之后"的逻辑留下钩子。 - 提交或回滚完成后，解绑
ThreadLocal中的连接，归还连接池。
你仔细看第 4 步就会发现，事务生效不是因为每条 SQL 都被神奇地包了一圈，而是因为"事务内所有数据库操作必须拿到同一个连接"。连接一旦不一致，commit 和 rollback 就各管各的了。DataSourceTransactionManager的核心工作之一，就是确保"当前线程 + 当前事务"这组映射关系稳定存在。
1.3 逻辑事务与物理事务：isNewTransaction 和 rollbackOnly 的分量
当方法嵌套调用时，一个业务请求里可能同时存在多个带@Transactional的方法。以默认的REQUIRED传播行为为例，内层方法发现当前线程已经存在事务，不会新开数据库事务，而是直接加入现有事务。那么它返回后会 commit 吗？不会。TransactionStatus里有一个isNewTransaction标识，只有发起第一个物理事务的外层调用者，才拥有最终 commit 或 rollback 的资格。
在此基础上，还有一个非常经典的坑叫rollbackOnly。内层方法如果自己触发了回滚，它并不会立刻回滚数据库，而是把共享事务标记成rollbackOnly，向外层传递一个信号："这个事务已经被污染，别想提交成功了"。外层即使没抛异常，commit 时也会收到UnexpectedRollbackException。我第一次遇到这个异常时觉得莫名其妙，明明是"成功"返回的，怎么提交失败？后来明白了，这其实是 TransactionManager 在保护数据一致性：既然某个参与者已经决定不做，就不允许最终结果出现部分提交。遇到UnexpectedRollbackException，优先去查内层方法是否抛过异常、是否把事务标记坏了，而不是在最外层找原因。
2. Spring里的TransactionManager选型：单数据源、JPA与JTA
2.1 DataSourceTransactionManager：单数据源场景的正确默认
Spring Boot 项目只要引入了spring-boot-starter-jdbc或者mybatis-spring-boot-starter，容器里就会自动注册DataSourceTransactionManager。大多数情况下你什么都不用配置，它就已经在为你工作了。
它是最直接的事务管理器：事务的粒度就是一个物理连接，底层完全依赖Connection.setAutoCommit、commit、rollback。我个人的选型原则很简单——只有单个数据源，持久层是 MyBatis 或 JdbcTemplate，一律用它。逻辑最简单，天然不容易出错。不要为了"看起来很高级"去换 JTA，在没有多个 XA 资源的情况下，JTA 只会在两层语义之间引入额外的协调开销。
2.2 JpaTransactionManager：EntityManager 伴生的事务协调者
如果项目用 Spring Data JPA 或 Hibernate，默认注册的就是JpaTransactionManager。它和DataSourceTransactionManager最大的区别在于：它要同时管理两个层面的资源——EntitManager 和它背后的 JDBC 连接。
Hibernate 的Session本身持有 Connection，一级缓存、脏检查、flush 时机全部要依附在一个事务会话里才有意义。JpaTransactionManager在getTransaction时会通过EntityManagerFactory创建并绑定一个EntityManager到当前线程，后续 Repository 操作复用同一个EntityManager，一级缓存和延迟加载才能正常工作。如果事务边界没覆盖到某个查询，你会看到 "No EntityManager with actual transaction available for current thread" 这类经典报错，本质就是当前线程没有绑定任何事务资源。
另一个容易被忽视的点：在 JPA 事务里混用 JdbcTemplate。JpaTransactionManager内部会把底层的 JDBC Connection 也暴露出来，同步绑定到当前线程，这样 JdbcTemplate 操作也能加入同一个事务。但如果你在事务里另起一个数据源连接，那就是另一个故事了，距离"假事务"只有一步之遥。
2.3 JtaTransactionManager：跨数据源的"交通管制员"
当一个业务操作必须同时写两个数据库，并且要求要么都成功要么都失败，单数据源的事务管理器就无能为力了。这时会用到JtaTransactionManager。它自己不直接拿连接，而是通过 JTA 事务协调器管理多个 XA 资源，常见的实现有 Atomikos、Narayana，或应用服务器内置的 JTA。
JTA 能带来跨库原子性，但代价非常现实：两阶段提交期间，相关资源要长时间持有锁；prepare 之后如果协调者崩溃，资源不能立即释放，系统可用性会受到直接牵连。所以在架构上，JTA 应当被视为"最后手段"，而不是"高级方案"。能用单库解决的问题，就不要制造跨库强一致需求。
下面用一张表快速总结三者的适用边界：
| 事务管理器 | 数据源数量 | 典型场景 | 主要代价 |
|---|---|---|---|
| DataSourceTransactionManager | 单数据源 | MyBatis / JdbcTemplate 单库操作 | 无法跨库 |
| JpaTransactionManager | 单数据源，内部联动 EntityManager | Spring Data JPA / Hibernate | 需要关注一级缓存与连接同步 |
| JtaTransactionManager | 多数据源 | XA 跨库强一致 | 协调成本高、锁时间长、可用性风险大 |
3. @Transactional 是怎么驱动 TransactionManager 的
3.1 默认回滚规则：为什么检查异常不触发回滚
@Transactional的默认回滚规则是：只有RuntimeException和Error才触发回滚，检查异常（checked exception）不会。这个设计初衷是：检查异常通常代表"需要人工干预的问题"，不一定是数据不一致；运行时异常才代表程序已经无法继续往下走。
但业务系统往往不这么分类。很多团队复盘"数据为什么没回滚"时，最终都发现业务方法抛的是自定义检查异常，事务管理器压根没有收到回滚信号。我的经验是两条：第一，业务校验失败统一抛RuntimeException子类，比如自定义的BizException；第二，在关键写方法上显式加@Transactional(rollbackFor = Exception.class)，把回滚条件放宽到所有异常。两者结合，能覆盖绝大多数由"异常类型不匹配"导致的脏数据问题。
3.2 传播行为：新建、加入还是挂起
Spring 的七大传播行为，从 TransactionManager 视角来看，其实都是在回答一个问题：当当前线程已存在事务，我要怎么办。最关键的两个：
REQUIRED（默认）：有事务就加入，没有就新建。一个业务用例内互相调用，所有方法共享同一个物理事务。REQUIRES_NEW：挂起当前事务，开一个全新的独立事务。典型用途是"审计日志不随主业务回滚""消息发送不受主业务失败影响"。注意它不只是"新开一个事务"，还会把外层连接暂时从当前线程解绑，执行完再恢复，所以连接获取和释放更频繁，开销更高。
还有NESTED：有事务时创建保存点，可以只回滚嵌套的那一部分。它依赖底层数据库的 savepoint 能力，在单数据源场景基本可用，但高并发环境仍需谨慎验证。至于SUPPORTS、NOT_SUPPORTED、MANDATORY、NEVER，属于低频工具类，知道它们存在即可，生产代码里出现频率极低。
3.3 隔离级别、超时和只读：TransactionDefinition 的隐藏影响
你写在@Transactional里的isolation、timeout、readOnly，最终都会被封装进TransactionAttribute，传给transactionManager.getTransaction()。DataSourceTransactionManager会把隔离级别直接设置到 JDBC 连接的setTransactionIsolation上。
这里最常见的失误是：只想着用REPEATABLE_READ防幻读，却忽略了隔离级别越高，锁竞争越激烈，长事务持锁时间越长，最后连接池被耗尽，反而把责任推到连接池配置头上。我的补充习惯是：给纯查询方法标注@Transactional(readOnly = true)。一方面给底层一个只读提示，另一方面也是一道语义防线。但不要迷信 readOnly 能提升多少性能，真正决定性能的是事务的长度和锁的范围，而不是这个标志本身。
4. 那些让TransactionManager"看不见"事务的坑：完整排查链路
4.1 自调用：AOP 代理根本没入场
事务失效原因里，自调用排在第一位。场景代码长这样：
@Service public class OrderService { public void createOrder() { this.updateStock(); // 没有走代理 } @Transactional public void updateStock() { // 扣库存 } }createOrder内部调用updateStock时，this.updateStock()调用的是当前对象，也就是原始 Bean 的方法，而不是 Spring 包装后的代理对象。事务拦截器只挂在代理对象上，所以@Transactional被直接无视。
排查手法：把org.springframework.transaction的日志级别调到 TRACE，执行一次调用链，如果TransactionInterceptor完全没有输出，基本可以确认代理没有入场。修复也直接：把updateStock挪到独立的 Bean 中，注入后调用；或者使用AopContext.currentProxy()强制走代理（前提是exposeProxy开启）。前者更好理解，也符合"事务方法归属独立的业务协调组件"的分层习惯。
4.2 private、final、以及代理对象是否真的存在
Spring Boot 默认使用 CGLIB 生成子类代理。CGLIB 通过继承目标类来创建子类，因此private方法无法重写，final方法无法被子类覆盖，类声明为final时整个代理直接失效。这些情况下@Transactional会被静默跳过，不报错、不打日志，最让人头疼。
排查技巧：在方法里用 debug 观察this.getClass().getName()，如果类名中不包含$$EnhancerBySpringCGLIB或$Proxy，说明当前对象不是代理对象。或者在启动日志里看 Spring 创建的 Bean 是否经过了代理包装。看到真实对象而非代理对象，事务注解自然轮不上。
4.3 try-catch 吞掉异常带来的"假成功"
比自调用更隐蔽的是异常被吞掉：
@Transactional(rollbackFor = Exception.class) public void doBiz() { try { updateData(); } catch (Exception e) { log.error("update failed", e); // 吃掉了，方法正常返回 } insertLog(); }TransactionInterceptor看到方法正常返回，就认为业务成功，于是调用 commit。如果updateData内部已经把共享事务标记为rollbackOnly，commit 会抛出UnexpectedRollbackException；但如果你只是自己 catch 了一个异常而没有任何参与方标记事务状态，数据库就会提交。数据账面上是"没成功"，库里却是脏结果，问题排查周期往往被拉得很长。
我的处理原则：不在事务方法内部 catch 那些"需要让事务回滚"的异常。如果确实需要局部补偿，先把异常记录下来，再继续抛；或者把回滚语义明确改造成"记录失败状态并正常返回"。一句话，别让事务方法在"看起来正常"的状态下偷偷提交一段失败的业务。
4.4 新线程与异步：ThreadLocal 决定了事务天然不跨线程
事务连接绑定在当前线程的ThreadLocal上，这是 TransactionManager 最底层的工作方式。因此，在方法内new Thread、使用线程池、或者@Async让另一个线程执行数据库操作时，新线程里既拿不到已经绑定的连接，也不会有事务上下文。看起来像"事务没生效"，其实不是——是代码把数据库操作移出了事务范围。
如果异步任务必须保证原子性，有两条路：一是把需要原子性保障的操作放在当前事务方法里同步执行，异步只做事务提交后的通知；二是异步任务内部自己用TransactionTemplate编程式开启事务。能选第一条就不要选第二条，因为异步事务的边界肉眼不可见，后期维护成本极高。
下面把这一节最典型的失效特征整理成一张速查表，方便你现场对照：
| 症状 | 根因方向 | 立即检查项 |
|---|---|---|
| 事务方法没有 TRACE 日志 | AOP 代理未介入 | 是否为同类自调用、方法是否 private/final |
| 修改了数据但回滚未生效 | 异常被吞或异常类型不符 | 检查 catch 块、检查异常是否 RuntimeException |
| 新线程里的操作不参与事务 | ThreadLocal 线程隔离 | 确认是否在事务内另开线程 |
| 外层提交时抛 UnexpectedRollbackException | 内层已标记 rollbackOnly | 查内层方法回滚路径 |
| 多数据源下事务失效 | TransactionManager 绑定错误 | 确认数据源与管理器的对应关系 |
5. 实战：订单扣减场景里的事务边界该画在哪
5.1 事务边界的核心粒度是"业务用例"
拿常见的电商下单来说，一次下单往往涉及四个写操作：锁定用户余额、创建订单记录、扣减库存、写入操作流水。这四个动作要么都成功，要么都失败。如果事务写在每个 DAO 的 insert/update 方法上，就会出现订单插入成功、库存扣减失败，订单已提交但无法回滚的情况。
事务边界一定要画在"完整业务用例"这一层，通常就是 Service 实现类的一个 public 方法。示例骨架：
@Service public class OrderApplicationService { private final OrderRepository orderRepository; private final StockRepository stockRepository; private final FlowRepository flowRepository; @Transactional(rollbackFor = Exception.class) public Long createOrder(CreateOrderCommand cmd) { memberBalanceService.lock(cmd.getUserId(), cmd.getAmount()); Order order = Order.create(cmd); orderRepository.insert(order); int rows = stockRepository.deduct(cmd.getSkuId(), cmd.getQuantity()); if (rows == 0) { throw new BizException("库存不足"); } flowRepository.insert(Flow.of(order)); return order.getId(); } }这里的锁余额、插入订单、扣减库存、写入流水，会通过默认的REQUIRED传播共享同一个物理事务。扣减库存影响行数为 0 时，抛出BizException，TransactionInterceptor捕获后调用 rollback，之前的订单和流水全部撤回。
5.2 DAO 层不要随手写 @Transactional
我见过不少团队习惯在每个 DAO 的 update 方法上贴@Transactional，理由是"反正没坏处"。实际坏处很明显：事务被切得零碎，一个用例链路里可能嵌套十几层事务；连接可能在方法返回后就被决策逻辑释放；后续维护者要反复揣摩"这个事务到底想保护什么"。
更可持续的做法是：Service 层方法作为事务单元入口，DAO 层只聚焦 SQL 执行领域。如果某个子步骤需要独立提交，单独抽到另一个 Bean 的 public 方法上，标注@Transactional(propagation = Propagation.REQUIRES_NEW)，并在命名和调用处明确表达"独立事务"的语义。这样代码结构上一眼就能看出边界。
5.3 大事务、长事务和跨系统操作：TransactionManager 管不住的边界
事务方法里最容易埋雷的是"顺手做远程操作"——调用第三方 HTTP、写 Redis、发 MQ。这些远程操作不会跟随数据库回滚，而且网络等待会拉长事务持有连接的时间。极端情况下，一个事务里等上游接口 3 秒超时，连接池就会被一堆"半死不活"的事务占满。
我的拆分思路是：核心数据库写操作留在事务内；把"提交后必须执行的远程动作"放到事务成功后的回调里，比如TransactionSynchronizationManager.registerSynchronization，或者更直白地，在事务提交之后人工调用发送。如果业务要求"MQ 必须发布成功，订单才算完成"，那就引入本地消息表：把消息记录和订单数据放进同一个本地事务，由后台任务负责投递和补偿。这是 TransactionManager 管不到、但真实业务绕不开的边界问题。
6. 当单机事务不够用：多数据源与分布式事务的边界
6.1 多数据源的 TransactionManager 配置实战
Spring Boot 多数据源场景最常见的错误是：定义了两个 DataSource，只写了@Primary，没有给另一个数据源单独定义 TransactionManager。结果要么是注入PlatformTransactionManager时冲突，要么是所有@Transactional都默认绑到主数据源上，另一个数据源的操作根本没有事务保护。
我的配置习惯是：
- 每个 DataSource 都配上自己的
DataSourceTransactionManager； - 主数据源对应的管理器标注
@Primary； - 跨数据源的业务方法上用
@Transactional("otherTxManager")显式指定管理器； - 不要在同一个事务方法里同时操作两个数据源——两个管理器各开各的事务，相互之间没有任何协调关系。
这里的本质是：DataSourceTransactionManagerA 和 B 是完全独立的两套事务。在同一个方法里操作两个数据源，看起来像"一起成功"，实际回滚时各管各的，数据一致性毫无保障。很多伪跨库问题就是从这里开始的。
6.2 真正跨库强一致：JTA 与最终一致性方案的选择
如果业务真的无法规避跨库强一致，订单表和库存表在两个独立数据库，那么 JTA + XA 是一类选择，Seata 这类分布式事务框架是另一类。XA 的强一致来自两阶段提交，但代价是 prepare 后的资源长时间锁定，高并发和长事务环境下非常不友好。Seata 这类方案引入全局事务协调器和分支事务思想，把跨资源问题转换成一个可延迟的协调流程，牺牲部分强一致换取可用性。
我个人的倾向是，现代微服务架构下减少硬性跨库事务。能够把一个业务用例的数据收敛到单一数据库，就尽量收敛；确实分散的，优先考虑"本地消息表 + 对账补偿"的最终一致性路线。这条路线不炫技，但能被业务代码里的每个人理解和运维，故障面也小得多。TransactionManager 在单机事务这一层已经把问题抽象得很好，把它强行延伸到分布式场景，往往引入的是比原问题更复杂的协调问题，而不是解决方案。
最后说一点个人体会。TransactionManager 本身不是一个需要读完所有源码才能用得好的组件，它的设计处处透露着"边界感"：连接绑定在哪个线程、物理事务由谁发起、谁有资格回滚、回滚标记如何传递。很多时候事务失效并不是 Spring 的 bug，而是我们写代码时把调用链和资源边界搞混了。排查事务问题不要急着看日志，先冷静回答三个问题：当前线程是什么？连接从哪个数据源来？方法真的走了代理吗？这三个问题答清楚，八成的问题都已经有了答案。
再分享一个小技巧：可以在项目里封装一个自定义注解，并通过BeanPostProcessor在启动阶段校验标注了事务的方法必须是public且非final。这类检查成本不高，但能让团队在开发期就暴露一部分配置问题，而不是等到线上数据错乱再去翻日志。我在几个中大型项目里实践过，事务类事故率下降非常明显。
