我第一次被问到“为什么大厂一般不推荐使用 @Transactional”时，愣了一下。后来在新东家翻了核心业务系统的代码，发现一个耐人寻味的现象：真正跑在高并发、资金相关、订单核心链路上的方法，绝大多数没有直接在上面对 @Transactional 注解，要么移到独立的中间层，要么干脆用 TransactionTemplate 把事务边界写进代码里。没人明文规定“禁用”，但大家不约而同地选择绕开它。
其实 @Transactional 本身不是坏东西，它是 Spring 对声明式事务非常成熟的抽象。问题恰恰出在“注解”这两个字上——它把事务的边界感藏了起来。开发时只用一行注解，看着清爽，但代码跑起来之后，连接什么时候占用、锁什么时候释放、事务什么时候提交，全部变成了肉眼不可见的状态。一旦有异常或并发问题，排查链会拖得非常长。
这篇文章我想结合自己踩过的坑，把 @Transactional 在大厂场景里被冷落的深层原因拆开聊。内容会覆盖事务失效、长事务、回滚边界、可测试性、分布式演进以及编程式事务的替代写法。适合对 Spring 事务已经有基础认知、但还没遇到过生产事故的读者，也适合准备面试时想把这个话题讲深一层的人。
1. 注解声明事务的“透明陷阱”：为什么看起来简单，用起来处处是坑
1.1 事务失效的四个高频场景：不是注解没生效，是你根本没有走代理
很多人对 @Transactional 的理解是“只要我在方法上加了注解，这个方法里所有的数据库操作就都在同一个事务里”。但这个认知有个前提：你调用的对象必须是 Spring 管理下的代理对象，调用链必须经过代理。一旦这个前提被破坏，注解形同虚设。
我自己在实际项目中遇到最多的事务失效场景，排第一的是同类的自调用。例如：
@Service public class OrderService { @Transactional public void createOrder(Order order) { saveOrder(order); sendMessage(order.getId()); // this 调用，不是代理调用 } @Transactional(propagation = Propagation.REQUIRES_NEW) public void sendMessage(Long orderId) { messageDao.insert(orderId); } }这段代码表面上看起来是 sendMessage 单独一个事务，实际上它根本没有生效。因为 sendMessage 是 this 调用的，没有经过 Spring AOP 的代理对象，事务切面压根不会介入。最终结果是 sendMessage 里的操作跟着 createOrder 的事务一起走，或者创建订单失败时消息记录也被一起回滚，业务表现完全不符合预期。
排第二的是私有方法。Spring 默认使用的 CGLIB 代理对 private、final 方法无法增强。之前有一个线上小故障排查了很久，最后发现是同事在私有方法上加了 @Transactional，还特意配置了 REQUIRES_NEW 希望“强制走独立事务”，结果自然全部失效。
排第三的是异常被吞。这个太常见了，我后面单独用一小节说。
排第四的是数据库本身不支持事务，比如早期项目里还有 MyISAM 引擎的表，加了注解也不会回滚。这个现在少见，但在老系统里仍然存在。还有一种容易忽略的细节：在多线程环境里，子线程中执行的事务操作不会和主线程处于同一个事务中，因为默认事务传播只对同一个线程内的调用有效。
1.2 异常与回滚的边界：默认回滚策略为什么让很多人翻车
Spring 声明式事务的默认回滚规则是：只对 RuntimeException 和 Error 回滚，checked exception 不会触发回滚。这么设计的理由是，Spring 认为受检异常往往表示“可以处理的业务预期”，不应该把整个事务全部推翻。
但很多业务场景恰恰相反。比如用户下单，先锁库存、再扣余额、最后发积分。如果“积分服务不可用”被实现成了受检异常，而你没有显式指定 rollbackFor = Exception.class，那么库存锁了、余额扣了，偏偏事务提交了，后面又因为积分发放失败让用户反复重试，一重试就又扣一次钱。这种问题在微服务环境下尤其致命，因为远程接口跨网络的异常大多数会被包装成受检异常。
更隐蔽的是“异常被 catch 住但没重新抛出”的情况：
@Transactional public void createOrder(Order order) { try { inventoryService.deductStock(order.getProductId()); } catch (StockNotEnoughException e) { log.warn("库存不足，订单创建失败", e); // 没有继续抛出，事务不会回滚 } orderDao.insert(order); }这段代码里，库存扣减抛了异常，但被 catch 住了。事务管理器根本没有感知到任何异常，等到方法正常返回，事务会被干净地提交掉。结果就是库存扣减失败，但订单还是被创建了出来，后面库存对账怎么都对不上。
回滚边界问题在大厂里一直是 Code Review 的重点。因为声明式事务的回滚行为不是写在业务代码里的，而是由方法调用链和异常传播隐式决定，很多人根本意识不到自己在“修改事务边界”。我之前在团队里做过一次统计，事务相关的 bug 中，有接近四成属于“catch 了异常没有重新抛出”导致的静默提交。
2. 长事务才是真正的生产事故源头：连接、锁、数据库一起遭殃
如果说事务失效是“歪打正着”地产生错误数据，那么长事务就是直接冲击系统可用性的杀手。它不像事务失效那样有个明确的错误报出来，而是缓慢、持续地把系统拖垮。这种问题在开发环境、低并发环境几乎测不出来，一到线上流量上来就原形毕露。
2.1 事务内做 RPC 和批量操作，系统是怎么一步步卡死的
先看一段典型的反面代码：
@Transactional public void syncGoodsData(List<Goods> goodsList) { for (Goods goods : goodsList) { goodsPriceRemoteService.transformPrice(goods); // 每次循环一次 RPC goodsMapper.update(goods); } }这段逻辑本身不算复杂：把一批商品的价格同步到本地数据库。但因为加了 @Transactional，整段方法执行期间，数据库连接一直被这个事务持有。RPC 调用占用的时间、网络超时重试的时间，全部算在连接占用时间里。
假设商品有 1000 条，每一次 transformPrice 调用平均耗时 300 毫秒，光 RPC 就拿走了 300 秒。第一条数据更新后占用的行锁，在整个事务提交前都不会释放。如果这批商品里恰好包括了线上热点商品，那么所有涉及这些商品的订单操作都会在锁上排队。数据库连接池如果是 50，这个定时任务每次同步占住 1 个连接 5 分钟，再有一些慢查询、报表任务把连接占住，连接池很快被耗尽。后续所有正常业务请求拿不到连接，系统表现就是接口大面积超时。
更隐蔽的问题在于，很多性能监控工具只会告诉你“数据库等待时间很长”，不会告诉你“真正的瓶颈在事务内的一次外部 RPC”。我实际排查过一次就是这种表现：DBA 说数据库没有慢查询，但事务平均执行时间高达几十秒，最后通过 information_schema.innodb_trx 表看到事务状态一直处于 running，url 列上显示的线程还在等一个 HTTP 调用返回。
在数据库事务里做外部调用是最需要警惕的反模式，不只是 RPC，包括 HTTP 请求、发送 MQ、文件读写、第三方 SDK 调用，都不应该放在事务范围内。事务应该只包裹“必须同步成功、失败必须一起回滚”的纯数据库操作，外部调用要么放在事务之前，要么放在事务成功提交之后，用对账、本地消息表、重试队列去处理最终一致性。
2.2 从监控指标定位长事务：事前防御比事后救火靠谱
长事务不是不能预防，关键是要把监控做起来。MySQL 里可以直接查当前活跃事务：
SELECT trx_id, trx_state, trx_started, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS trx_running_seconds, trx_rows_locked, trx_query FROM information_schema.innodb_trx ORDER BY trx_started ASC;这条 SQL 能快速看到有哪些事务已经跑了很久。我在生产环境通过它抓到一个跑了 400 多秒的事务，顺着 trx_mysql_thread_id 找到对应连接，再从连接反向定位到业务线程堆栈，很快锁定了是一个同步接口在事务里做了两次外部调用，每次等超时 30 秒，循环了好几次。
应用层也可以配置 Spring 的事务超时时间，防止事务无限制地挂下去：
@Transactional(timeout = 5) public void syncGoodsData(List<Goods> goodsList) { // 超过 5 秒未提交，事务直接抛异常回滚 }超时是最后一道防御，而不是首选方案。核心还是要控制事务方法本身的执行时间：批量操作拆批、外部调用移出事务范围、大结果集分页处理。这几个原则，比任何监控工具都重要。
3. 隐性成本与团队协作：为什么大厂更看重“代码可预期”
3.1 声明式事务的可测试性困局
声明式事务有一个很少被公开讨论的问题：很难写单元测试。它不是不能测，而是你很难在脱离 Spring 容器的情况下验证注解的行为。
比如你想测试“库存扣减失败时整个事务回滚”，你需要一个真实的数据源、一个能被代理拦截的 Spring 上下文、一套能注入异常 mock 的方案。为了验证一行业务代码，你可能要搭一整套集成测试环境。如果事务逻辑藏在几十个方法的调用链里，测试还要复制整个调用栈。
而编程式事务把边界写在方法里，测试时可以直接对 TransactionTemplate 的 execute 回调做验证：传入一个必然抛异常的操作，断言数据库回滚到位。或者干脆用一个假的 TransactionManager 来记录事务提交与回滚的次数。这种可测试性差异在核心系统里是实打实的工程成本，毕竟大厂最不缺的就是复杂业务和严苛的回归要求。
3.2 多人协作下的事务边界混乱
另一个大厂场景特有的问题是“边界被无限放大”。一个方法加上 @Transactional 之后，它内部调用的所有方法、所有 Mapper 操作全部共享同一个事务。如果这个方法是 Service 层暴露出来的入口，并且在业务迭代里不断被新需求扩展，它的事务范围会像滚雪球一样越滚越大。
我经历过一个典型的例子：某个订单聚合服务方法，最初只有“保存订单 + 扣减库存”两个操作，事务范围很正常。后来接入了优惠券、积分、用户等级、物流预占，每一次迭代都往方法里塞一段新逻辑，所有操作都隐式落在同一个大事务里。到后面一次订单操作涉及十几张表，事务提交时需要同时持有大量锁，并发稍微一上来就锁等待超时。
最麻烦的是，没人能一眼看出这个方法的事务边界到底覆盖了多少操作。因为边界不在代码里，在注解上，而注解只告诉你“有事务”，不告诉你事务跨了多少行代码。在这种代码结构下，任何一次重构都可能无意中把事务边界改掉，引发连锁故障。
3.3 业务复杂性增长：从单库事务到分布式事务的必然演进
大厂的业务几乎不可能长期停留在一个数据库实例上。分库分表、微服务拆分是常态。而 @Transactional 本质上依赖的是本地数据库事务，它无法跨越多个数据库、多个服务实例去保证一致性。
最典型的问题：一个用户下单操作，要写订单库、扣用户钱包库、给积分库加积分。三个库来自三个独立应用，每个应用内部可以各自用 @Transactional，但整体上没有任何机制保证“三个库全部成功或全部失败”。如果订单库提交了，积分库写失败了，业务就出现了不一致。
这时候有人会说，用 Seata 这类分布式事务框架不就行了？可以，但分布式事务和 @Transactional 配合起来反而更小心。Seata 的 AT 模式虽然也通过注解标记全局事务，但它需要全局锁、分支事务资源长时间占用，事务时间越长，数据库锁粒度冲突越明显。在高并发扣减类场景里，全局事务的性能成本极高。很多大厂最终对一致性要求没那么极端的业务，宁可选择本地消息表、可靠事件、Saga 等从业务层解决最终一致性的方案，也不愿意在一个长事务注解上赌性能。
4. 工程上的替代方案：编程式事务如何把控制权真正拿回来
既然声明式事务有这么多问题，那大厂日常是怎么写事务的？我的经验是：核心链路上大量使用编程式事务，尤其是 TransactionTemplate。它把事务的边界、提交点、回滚条件全部显式地摆在代码里，读代码的人一眼就能看到事务从哪里开始、到哪里结束。
4.1 TransactionTemplate 的完整用法
先看基础设施怎么搭：
@Configuration public class TransactionConfig { @Bean public TransactionTemplate transactionTemplate(PlatformTransactionManager transactionManager) { TransactionTemplate template = new TransactionTemplate(transactionManager); // 建议在模板级别就约束默认行为 template.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED); template.setTimeout(10); // 事务秒级超时，防止长事务 template.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); return template; } }然后在业务代码里注入使用：
@Service public class GoodsSyncService { private final TransactionTemplate transactionTemplate; private final GoodsMapper goodsMapper; private final FailLogService failLogService; public GoodsSyncService(TransactionTemplate transactionTemplate, GoodsMapper goodsMapper, FailLogService failLogService) { this.transactionTemplate = transactionTemplate; this.goodsMapper = goodsMapper; this.failLogService = failLogService; } public void syncGoodsInBatch(List<Goods> goodsList) { // 按批次拆分事务，避免一个长事务占住连接和锁 for (List<Goods> batch : Lists.partition(goodsList, 100)) { try { transactionTemplate.executeWithoutResult(status -> { for (Goods goods : batch) { goodsMapper.update(goods); } }); } catch (DataAccessException ex) { // 单批次失败不影响其他批次，记录失败明细人工重放 failLogService.record(batch, ex); } } } }这里每个批次的 100 条商品在各自独立的事务里提交。这样一来，单个事务占用连接和锁的时间就被控制在了非常小的范围内。即使某一批失败，也只是失败那 100 条，其他批次照常处理。这种“部分成功部分失败”的语义在某些业务里是有意为之的，因为它比“全部回滚然后重跑全部任务”的代价小得多。
如果需要在事务里拿返回值，可以用 execute：
public OrderResult createOrderWithResult(Order order) { return transactionTemplate.execute(status -> { orderMapper.insert(order); int rows = stockMapper.deduct(order.getProductId(), order.getCount()); if (rows == 0) { // 库存不足，手动标记回滚 status.setRollbackOnly(); return null; } return new OrderResult(order.getId(), SUCCESS); }); }注意 status.setRollbackOnly() 是编程式事务里控制回滚非常重要的手段。你可以在事务里做任意业务判断，认为不该提交时就手动标记，Spring 在 return 前看到 rollbackOnly 标记就不会提交。
4.2 声明式 vs 编程式：什么场景选哪个
| 维度 | @Transactional 声明式 | TransactionTemplate 编程式 |
|---|---|---|
| 事务边界可读性 | 弱，注解只标记方法级别 | 强，代码中显式包裹 |
| 事务失效风险 | 高，代理机制依赖多个条件 | 低，调用逻辑直观 |
| 异常回滚策略 | 默认只回滚运行时异常，容易误判 | 可精确控制每个分支的回滚 |
| 方法内分批事务 | 难实现，一个方法只能一个事务 | 容易实现，循环中按批次执行 |
| 代码侵入性 | 低，一个注解搞定 | 中，需要注入模板、写包裹逻辑 |
| 是支持事务传播行为配置 | 支持 | 支持 |
不需要把声明式事务一棒子打死。它最适合的场景是：单方法内做了简单的、小范围的数据库操作，事务时间极短，且没有外部调用、没有批量循环、没有复杂异常。比如一个简单的用户资料修改，方法里就两三行 update，用 @Transactional 完全没问题。但一旦方法开始膨胀，或者需要拆批、需要嵌套才能完成一致性保障，我就会毫不犹豫地改成编程式事务。
4.3 与事务切面共存时的注意事项
还有一个容易踩的坑：如果代码里同时使用了声明式事务注解和 TransactionTemplate，要注意传播行为。比如外层方法声明了 REQUIRED，内层 TransactionTemplate 默认也是 REQUIRED，那么两者会合到同一个事务里。如果外层不加注解、只有 TransactionTemplate 是事务，那么 TransactionTemplate 执行范围内的就是独立事务。
我最推荐的组合是：底层 DAO / 通用方法不带任何事务注解，业务层在需要时直接用 TransactionTemplate 明确开启。这样整个系统的事务逻辑统一收口在少数几个方法里，代码评审时只需要盯着这几个方法就够了。遇到性能瓶颈，也能很快定位到具体事务，不会像注解声明式那样，事务藏在一个几十层深的调用链里无从下手。
5. 一次线上事故的完整复盘：一个 @Transactional 引发的连环雪崩
理论说再多，不如复盘一个真实案例。虽然细节做过脱敏，但整体链路非常典型。
5.1 事故当天的时间线
那是某个工作日下午 2 点左右，用户反馈“订单确认页转圈打不开”，紧接着监控系统报警：订单服务的数据库连接池活跃连接数飙升到上限，接口平均响应时间从几十毫秒涨到十几秒。
起初以为是数据库慢查询或者磁盘 IO 问题。DBA 查了慢查询日志，没有发现异常的大 SQL，但发现大量事务一直处于 running 状态。逐个查看这些活跃事务，发现事务内容集中在某几个订单号的 update 操作上，trx_started 时间已经远超正常范围。也就是说，不是 SQL 慢，而是事务迟迟不提交，导致行锁一直不释放，所有依赖同一行数据的更新操作全部排队。
顺着活跃事务的线程 ID 查业务线程堆栈，定位到了如下代码：
@Transactional public void settleOrderBatch(List<Long> orderIdList) { for (Long orderId : orderIdList) { Order order = orderMapper.selectLockByOrderId(orderId); order.setStatus(SETTLED); orderMapper.updateById(order); pointRemoteService.grantPoints(order.getUserId(), order.getAmount()); // 外部 RPC } }这个方法是个定时任务，每天下午统一结算一批订单。因为定时任务的定时器调用了这个入口方法，所以它一开始就有事务。问题是业务迭代时，有人在循环里塞了积分发放的 RPC 调用，RPC 超时时间设定为 10 秒。线上积分服务刚好在那个时段进行发布，响应变慢，每次 grantPoints 都等满了 10 秒才超时。一批订单几百个，循环下来一个定时任务的事务挂了几分钟，行锁全部压在订单数据上，前端所有落单操作都被堵住了。
5.2 根因分析：问题不在注解本身
这个事故的根本原因当然不只是 @Transactional。真正的问题有三个层次：第一，事务方法内做了远程调用；第二，批量循环里的事务范围过大；第三，RPC 没有做合理的超时控制，也没有拆出事务外。
但 @Transactional 在这里扮演了一个放大器：因为它把整个方法悄悄包成了一个大事务，连循环中第一个订单的更新操作能不能提交，都要等最后一个 RPC 返回才知道。如果是编程式事务，拆成每单一个事务，即使某一单的 RPC 超时，也只有那一单的行锁短暂占用，其他订单的正常操作不受影响，事故影响面会小很多。
从排查角度复盘，整个过程的定位链条是：应用超时 -> 数据库连接池打满 -> 活跃事务堆积 -> innodb_trx 定位到事务 -> 线程堆栈定位到业务方法 -> 发现 RPC 调用在事务内。每一步都不难，但加起来花了一个多小时。如果代码本身没有把事务藏起来，这起事故 10 分钟内就能定位。
5.3 事后修复与团队约定
修复方案分三步。第一步，立刻去掉 settleOrderBatch 方法上的 @Transactional，改成 TransactionTemplate，并且把事务粒度拆到单个订单的 update 操作。积分发放的 RPC 完全移出事务范围，放在事务提交成功后执行，如果失败就写入本地补偿表。第二步，给所有外部调用统一配置更短的超时时间，不合理的超时配置一律重审。第三步，团队内部约法三章：任何事务方法内禁止远程调用；一个事务方法原则上只处理一张核心表；批量新增/更新必须做批次切分。后面两条写进了代码规范，评审的时候会专门检查。
6. 规范建议：如果团队暂时还是决定保留 @Transactional，该怎么降低风险
完全没有必要在所有项目里强行禁用 @Transactional。即使是大厂，也会在非核心链路、管理后台、低频写入场景继续用它，因为开发效率确实高。但如果要用，我建议至少建立这样几条底线规范。
第一，事务方法内部禁止远程调用。这一点无论用什么事务方案都是死规矩。可以在 Code Review 环节通过静态扫描强制检查，也可以利用代码评审插件来拦截事务方法体里的 RPC 调用语句。
第二，事务方法必须设置 rollbackFor = Exception.class。虽然默认只回滚运行时异常有它的设计理由，但在业务系统里，受检异常通常意味着“这事没办成”，业务上通常也需要回滚。与其让每个开发都理解这一层，不如统一约定：事务方法全部显式写 rollbackFor，不允许依赖默认值。
第三，事务方法要短小。如果方法体超过几十行，或者包含循环、批量操作、消息发送、文件处理，就不适合用声明式事务。改成 TransactionTemplate 把事务范围进一步收窄。一个事务方法只做一件完整的事情，这句话听起来像废话，但代码里能真正做到的人不多。
第四，注意传播行为。REQUIRES_NEW、NESTED、MANDATORY 这些每个都要想清楚再写。我见过最乱的一种代码是，A 方法用 REQUIRED 调了 B，B 又用 REQUIRES_NEW 开了新事务，最后业务逻辑要求“AB 要么都成功要么都失败”，结果因为 B 已经提前提交，A 失败时根本拉不回 B 的数据。事务传播行为的选择，本质上就是在定义业务一致性边界，需要非常谨慎。
第五，无论用哪种事务方案，都要在监控里加事务时长指标。Spring 的 PlatformTransactionManager 可以包一层，统计每个事务从开始到提交/回滚的耗时，超过阈值就告警。这个指标比接口耗时更能反映数据库事务的健康度，强烈建议有条件的团队加上。
我在实际项目里最后形成的一套做法是：所有核心链路上的事务方法全部改写成 TransactionTemplate，方法命名里直接带上原语，比如 createOrderInTransaction、batchDeductInTransaction，让人一眼就知道这里有事务边界。管理后台和低频操作保留 @Transactional，但严格遵守上面的五条底线。这样既保证了核心系统的稳定性，又没有让开发效率沦丧。几年实践下来，事务相关的生产事故确实降到了很低的频率。如果你也正准备在团队里梳理事务规范，可以从这几条开始，然后结合自己的业务不断打磨出更细的约定。
