在Java后端圈子里，@Transactional几乎是每个Spring开发者最早接触的几个注解之一。刚入行的时候，很多人对它的理解就是“在方法上加上这个注解，方法里的数据库操作要么全成功，要么全失败”，省去了手动begin、commit、rollback的样板代码，看起来确实是神器。但在大厂里待过几年后你会发现，代码评审时如果有人在核心链路上直接甩一个@Transactional，大概率会被追问“这个事务是非开不可吗？能不能去掉？”不是大厂故意刁难，而是这个注解背后的坑，远比表面看上去的要多。
这篇文章我想从实际踩坑经历出发，把@Transactional在真实业务场景里的“原罪”讲清楚。它为什么会失效、什么时候会拖垮性能、单库事务在分布式环境下又是怎么变成隐患的、以及大厂更倾向于用什么方案替代。不管是刚写Spring没多久的新人，还是被线上事故折腾过的老手，这篇文章应该都能给你一些参考。
1. 内容整体设计与思路拆解
在展开细节之前，我想先聊聊为什么大家会集中吐槽@Transactional。它本身不是坏东西，但因为它太“方便”了，反而容易被人用在不合适的地方。理解这个问题的关键，在于要弄清楚一件事：事务的本质是锁和日志的组合，而锁意味着串行化，日志意味着额外的IO开销。
1.1 从一次线上事故说起：谁动了我的数据
我之前带过一个支付对账相关的项目，有一个“批量入账”的接口。当时新来的同学很自然地在这个方法上加了@Transactional，他的逻辑很简单：把所有入账操作放在一个事务里，任何一个失败就全部回滚，这样数据不会出现“一半成功一半失败”的状态。
听起来毫无问题，对不对？但上线后第三天，线上就开始出现大量超时告警。我让他查数据库慢查询日志，结果发现表虽然不大，但大量SQL都集中在同一行记录上长时间持锁。再追下去，发现这个批量入账方法在事务里还调用了一个远程账户通知服务，网速稍微抖一下，事务就迟迟不提交，锁就捏在手里不放。
这个案例非常典型：他做对了事务的一致性保证，却忽略了事务的隔离性代价。一个简单的@Transactional，把“批量写库”和“外部RPC调用”绑定在了同一个生命周期里。类似的问题在大厂代码评审中几乎是每周都会出现。
1.2 大厂不推荐的真正理由：不是禁用，而是慎用
大厂并不是给@Transactional判了死刑，而是把它从“默认选项”降级成了“需要充分理由才能使用”。核心原因是三方面的：
- 职责边界被破坏：一个方法一旦加了事务，这个方法的逻辑就被迫变成一个原子单元。但现实业务中，很多操作天然就是“可补偿”的，不需要原子化。
- 性能边界模糊：事务的隔离级别、传播行为、锁粒度，很多人并没有真正理解。默认配置直接套上去，长事务、大事务、死锁问题接踵而至。
- 分布式环境下能力不足：单库事务只能在本地生效，一旦涉及微服务间调用、消息队列、多数据源，
@Transactional反而给人制造“我好像有事务保护”的错觉。
所以我更愿意把这篇内容理解为：什么时候你别用@Transactional，以及如果你真的要用，怎么把风险降到最低。
2. 核心细节解析与实操要点
可能有人会觉得：“不就是一个注解吗？我用了这么多年也没出过事。”那我只能说你比较幸运，还没有被线上事故教育过。下面我挑几个最容易踩的坑展开说一下，这些都是我在实际项目里真真切切遇到过的。
2.1 事务失效的若干种姿势
如果面试被问到“@Transactional为什么会失效”，很多人能回答出“自调用失效”和“异常被吞了”这两条。但真实场景里的失效情况远不止这两类，我整理了一个我亲手排查过的问题列表：
| 失效场景 | 真实原因 | 现象 |
|---|---|---|
同类内部方法调用（this.xxx()） | 不走代理对象，事务切面不生效 | 异常抛出但数据部分更新 |
try-catch吞掉异常 | Spring默认只对RuntimeException回滚，异常没抛出去 | 数据出现“半成功”状态 |
方法不是public | Spring AOP默认只拦截public方法 | 事务不生效 |
| 数据库引擎不支持事务 | 比如MyISAM表 | 写操作照常但无法回滚 |
| 多线程调用 | 事务上下文不传递到子线程 | 子线程里的写操作不在事务内 |
每个场景背后几乎都有一次血泪线上事故。拿“异常被吞”来说，很多同学写代码时喜欢在catch块里记录日志然后返回一个错误码，这在普通业务方法里没问题，但如果方法上有@Transactional，事务不会因为你返回了错误码就回滚。你必须在catch块里手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()，否则数据就悄悄写进去了。
2.2 默认隔离级别与锁升级
MySQL 默认的隔离级别是REPEATABLE_READ，也就是可重复读。Spring 的@Transactional如果你不指定isolation属性，它走的是数据库默认隔离级别，所以大多数情况下你实际用的是REPEATABLE_READ。
这有什么问题呢？REPEATABLE_READ为了保证同一事务内多次读取结果一致，会在SELECT上加S锁（共享锁），在UPDATE/DELETE上加X锁（排他锁）。在高并发写入场景下，多个事务同时更新同一行或相邻的索引范围，就容易触发间隙锁（Gap Lock）和Next-Key Lock，进而产生死锁。
举个我在订单系统中实际遇到过的案例：有一个“订单自动确认收货”的定时任务，和用户手动点击“确认收货”的接口，都会去更新同一批订单的状态。两个事务同时扫描status = 待收货的订单区间时，互相持有了对方需要的间隙锁，MySQL 检测到死锁后，会随机kill掉一个事务。被kill的那个事务如果没有正确处理死锁异常，用户就会看到“操作失败”。
这类问题用@Transactional不是完全不能解决，但你得非常清楚自己操作的数据范围、索引设计、锁顺序，任何一环没考虑到，就是一个隐患。
2.3 事务内调用远程RPC：时间黑洞
这是我认为最不值得踩的坑。在事务方法里调用RPC、HTTP接口、消息发送、文件上传，本质上是在用一个数据库事务去控制一个毫秒级甚至秒级延迟的外部系统。这么做有两个后果：
- 事务持有时间变长，数据库连接池被长期占用，高并发下连接耗尽；
- 外部系统调用失败时，事务回滚了，但外部系统已经做了操作，两边数据不一致。
我见过最夸张的一个案例，是有人在一个@Transactional方法里循环调用了20多次外部供应商接口，每次平均耗时300毫秒。一次请求这个事务至少要跑6秒，数据库连接直接被卡死。这已经不是在写事务性代码了，这是在制造线上事故。
正确的做法是什么？把外部调用放在事务外，或者干脆去掉事务，靠状态机+重试+幂等来控制数据一致性。这个后面我会详细讲。
3. 实操过程与核心环节实现
既然吐槽了这么多，那总得告诉你怎么做是合理的。下面我结合几个真实场景，分别给出“别用@Transactional的替代方案”，以及“如果确实要用，怎么把伤害降到最低”。
3.1 方案一：用自研轻量级事务工具类控制边界
大厂里很多基础架构团队会给业务方提供一个TransactionTemplate的封装，核心思路就是把事务边界显式化，而不是靠注解的隐式切面。你可以在代码里精确控制“在哪个方法里开启事务、在哪个节点提交”。
@Service public class OrderService { @Autowired private TransactionTemplate transactionTemplate; @Autowired private OrderMapper orderMapper; @Autowired private AccountService accountService; public void createOrder(OrderDO order) { // 前置校验、幂等检查都可以放在事务外面 boolean created = transactionTemplate.execute(status -> { try { orderMapper.insert(order); // 注意：这里不要调RPC，只做纯DB操作 return true; } catch (Exception e) { status.setRollbackOnly(); throw e; } }); if (created) { // 事务提交之后，再发MQ通知、调外部接口 accountService.deductBalance(order.getUserId(), order.getAmount()); } } }这个方式相比@Transactional，最大的好处是事务边界肉眼可见。你把“数据库原子写入”和“外部动作”彻底拆开，事务只保护真正需要对一致性负责的那一小段逻辑。很多大厂的基础架构规范里，都会明确推荐TransactionTemplate，因为它更显式、更能强迫开发者思考事务的真实边界。
3.2 方案二：拆分为独立事务 + 幂等补偿
很多业务操作本质上是“本地数据库写操作 + 下游系统操作”的组合。比如“下单成功后发优惠券”、“支付成功后发积分”。这类需求用@Transactional去包住下游操作是完全不现实的，因为你既不能回滚别人的数据库，也不能因为下游失败而撤销主业务。
业内通用的做法是本地事务只保护主流程数据 + 可靠消息/事件驱动下游。流程大致是：
- 开启本地事务，写入业务表数据，同时插入一张“事件表”或“消息表”，状态为“待发送”。
- 本地事务提交后，通过一个后台任务或MQ，把事件表中的记录异步推送出去。
- 下游系统处理成功后回调确认，事件表状态更新为“已发送”。
- 如果推送失败，后台任务不断重试，消费方保证幂等。
这样做的好处是：本地事务非常短，锁持有时间短；下游失败不会影响主流程已完成的数据；最终通过重试机制达到最终一致性。
3.3 方案三：如果一定要用@Transactional，这几条红线你得守住
如果你评估完发现自己就是“单库、单服务、操作不复杂、没有外部调用”，那用@Transactional也无可厚非。但有几条经验红线，你最好牢牢记住。
首先，方法体内绝对不能有RPC、HTTP、MQ等外部网络操作，这个已经不需要再解释了，就是血的教训。其次，能用小事务解决的就不要搞大事务，比如一个批量导入几十万数据的场景，拆分批次提交，而不是一个事务包到底，否则undo log膨胀和长时间锁等待会把你压垮。
还有一点很多人容易忽略：@Transactional上尽量显式指定rollbackFor，因为默认值只对RuntimeException和Error生效，受检异常（如Exception）是不会触发回滚的。
@Transactional(rollbackFor = Exception.class) public void updateData() { // 你的业务逻辑 }如果你在代码里把Exception通过try-catch捕获，那rollbackFor也没用。所以我的习惯是：异常一律往外抛，由最外层的事务切面统一处理回滚逻辑。如果你确实想在事务方法内部消化异常，那就手动调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()，这是唯一能确保事务回滚的方式。
3.4 给“不得不开事务”的场景做瘦身
有时候业务就是需要一个比较大的事务范围，比如“同时更新主单、更新明细、更新库存”。这种情况下，你需要做的是尽可能缩小锁定范围，具体可以从这几个方向切入：
- 控制数据量：不要在事务里
for循环一条条查再一条条改，尽量用批量SQL，减少往返次数和锁的持有时间。 - 保证索引有效：更新操作务必走索引，否则全表扫描时会在所有记录上加上锁，后果非常可怕。
- 统一锁顺序：如果两个方法分别需要更新A表和B表，尽量保持一致的加锁顺序。例如先更新A再更新B，避免两个事务互相持锁等待，形成死锁。
- 降低隔离级别：如果业务允许，可以把事务隔离级别从默认的可重复读降到
READ_COMMITTED。这个调整能显著减少间隙锁死锁的概率，代价是同一事务内可能读到其他事务已提交的新数据。我们当时处理订单自动确认收货的死锁问题，最终就是靠“走索引+降低隔离级别”双管齐下解决的。
4. 常见问题与排查技巧实录
在我带团队这几年里，关于@Transactional的排查问题，几乎每个月都能碰到一两个。下面我把一些高频问题和排查思路整理成速查表，方便大家直接抄作业。
4.1 高频问题速查表
| 问题现象 | 排查方向 | 常见根因 | 解决建议 |
|---|---|---|---|
| 方法抛异常后数据依然写入 | 检查是否被catch吞掉 | 异常没有抛到事务切面 | 要么外层抛异常，要么手动setRollbackOnly() |
| 事务完全没有生效 | 检查方法是否为public | Spring AOP只拦截public方法 | 改为public或者用TransactionTemplate |
| 同事内部调用事务失效 | 检查是否是this.xxx()调用 | 没有经过代理对象 | 注入自身代理或拆分到另一个Bean |
| 高并发下大量死锁 | 检查SQL是否走索引 | 间隙锁范围过大 | 优化索引、降低隔离级别、统一锁顺序 |
| 数据库连接池被打满 | 检查事务内是否有RPC | 事务持有时间过长 | 外部调用移出事务，异步化 |
| 批量操作很慢 | 检查是否一个事务包太多 | undo日志、锁竞争严重 | 分批提交，控制单事务数据量 |
4.2 排查事务失效的定位技巧
如果你怀疑某个@Transactional根本没生效，最快的验证方法是开debug日志观察spring的TransactionInterceptor有没有拦截到方法调用。配置如下：
logging.level.org.springframework.transaction.interceptor=DEBUG logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManager=DEBUG看到日志里有Creating new transaction with name [com.xxx.YourService.xxxMethod]，说明事务已经开启。如果没有任何输出，说明这个方法压根没走代理，先检查是不是public、是不是内部调用。这个方法在排查问题时比看代码快得多，我基本每次都会先用它确认方向。
4.3 从日志里捞死锁信息
死锁问题最麻烦的是你不知道它什么时候发生。MySQL在处理死锁时，会立刻回滚其中一个事务，并在错误日志里记录详细的死锁信息。我的排查习惯是打开死锁日志：
SHOW ENGINE INNODB STATUS\G重点看LATEST DETECTED DEADLOCK部分，里面会列出两个事务各自持有哪些锁、等待哪个锁，以及执行的SQL语句。看到 SQL 基本就能判断是哪段业务代码了，再配合业务日志里的请求参数，基本能定位到具体方法。
这里分享一个小技巧：我在定位一次订单系统死锁时，日志里显示两个事务都在操作order_status状态字段，一个更新的是“待发货”到“已发货”，另一个更新的是“待发货”到“已取消”。单独看都不觉得有问题，但打开执行计划后发现更新条件没走索引，全表扫描把锁散到了所有记录上，这才导致两个事务互相等待。后面给状态字段加了联合索引，死锁直接消失。
4.4 避免事务问题的一些设计习惯
除了上面这些排查手段，我更想分享的是几个能从根本上减少事务问题概率的设计习惯。
一是写操作的方法签名上不要带返回值之外的副作用。也就是说，一个事务方法只做数据变更，不做远程通知、不拼装大报文、不做复杂的JSON解析。这些脏活累活放到事务外面去。
二是在领域层区分“服务方法”和“基础设施方法”。领域服务里的方法可以放心用@Transactional，因为它处理的是纯粹的领域逻辑；但 Controller 层、Facade 层、RPC 入站接口层，这些方法里尽量别直接加事务，因为这一层往往涉及参数校验、多服务聚合，事务边界容易被拉大。
三是读写分离场景要格外小心。如果项目用了主从分离，默认情况下@Transactional会让整个方法绑定在主库上。哪怕你方法里只有一个查询操作，也会因为开启了事务而走了主库，把读压力全部压到主库上。很多人发现“为什么我的从库一点流量都没有”，很可能就是这个原因。解决办法是对于只读场景，显式指定事务为只读，或者干脆去掉事务。
5. 从“能不能用”到“怎么用对”：事务控制的进阶思考
聊了这么多，如果只记住“别用@Transactional”，那还是没理解透。这个东西不是毒药，只是很容易用错。我自己在项目里也经常用，但会在用之前问自己几个问题，这里整理出来供大家参考。
5.1 用之前先问自己四个问题
第一个问题：这个操作是不是必须原子生效？如果不是，那就别开事务。很多业务场景其实只是“顺序执行多个操作”，并不要求每个操作都成功，失败的话后面补偿就行。
第二个问题：事务范围能不能控制在纯DB操作内？如果方法里有任何非DB调用，那你需要重新审视这个方法的边界。记住一个原则：事务里只做数据操作，业务编排放在事务外。
第三个问题：这个事务的粒度是否够小？如果你要更新1万条数据，拆成每500条一个事务，远比一个事务包到底要好。这样如果中途失败，不需要回滚全部数据，锁竞争也小得多。
第四个问题：回滚之后，下游系统知不知道你回滚了？如果你的事务里发了MQ消息，事务回滚了但消息已经发出去了，消费方那边依然会执行。这种情况下，就算你用@Transactional包住了本地数据库，仍然无法保证全局一致性。
5.2 本地事务和分布式事务的边界意识
很多人对大厂不推荐@Transactional的另一个误解是：因为大厂都是微服务架构，所以单库事务没用了。这个说法不完全对。微服务架构下，每个服务内部依然有本地数据库事务，只是你不能再指望用本地事务去约束跨服务的数据一致性。
真正合理的架构是：本地事务管住自己的状态，跨服务的状态用可靠消息/事件驱动来同步。你可以把@Transactional用在“下单主流程”中，但它只管本地订单表和事件表的写入。至于下游的积分服务、优惠券服务、物流服务，都是通过事件异步触发的，不会和主事务放在同一个事务里。
有一个非常好的实践叫本地消息表。这个模式的核心就是利用本地事务，把业务操作和消息发送放在同一个事务里，事务提交后，消息表里的记录就是可靠的，后台任务再把消息发出去。这个方案既保证了本地数据的一致性，又为跨系统的最终一致性提供了基础。在这个模式里，@Transactional反而扮演了非常关键的角色。
5.3 谨慎使用REQUIRES_NEW：它不是银弹
事务传播行为里的REQUIRES_NEW经常被拿来当“局部事务独立提交”的解法。比如有人说：“我在外层事务里调用一个方法，希望它单独提交，即使外层回滚它也不受影响，那就用REQUIRES_NEW。”
这个思路在特定场景下是对的，但要特别谨慎。REQUIRES_NEW会挂起当前事务，开启一个新事务，新事务提交后再恢复原事务。这意味着这个方法的数据库操作和原事务不在同一个原子单元里，而且会额外占用一个数据库连接。
我见过有同学在循环中调用REQUIRES_NEW方法，结果连接池直接被打满。因为外层事务一直持有一个连接，内层的REQUIRES_NEW每循环一次就要从连接池拿一个新连接，即使连接池默认有20个连接，也不能这么造。如果你确实需要“部分数据独立提交”，优先考虑把这一部分抽到独立服务去调用，或者用事务同步钩子处理器（TransactionSynchronizationManager.registerSynchronization）在事务提交后异步执行。
6. 写在最后：事务是工具，但别让它替你思考
做技术这行久了，你会发现很多问题都不是“技术不够”导致的，而是“默认配置太方便，思考变懒了”导致的。@Transactional就是最典型的例子。它让你一行注解就拿到了事务能力，却也把事务的代价、边界、异常处理逻辑全部隐去了。当你面对的仅仅是“单表单库的简单CRUD”时，它确实省心。但一旦你的方法开始变得复杂，涉及外部调用、多表关联、批量处理、异步逻辑，这个注解就会变成一把没有安全栓的枪。
我自己现在的习惯是：新项目里默认不用@Transactional标注业务方法，而是根据实际场景去选。纯DB小操作，用TransactionTemplate或直接在Mapper层做；跨服务一致性，直接用可靠消息；只有那种“必须原子更新若干张表，且不掺杂任何外部动作”的场景，我才会把事务注解加上，并且严格限定rollbackFor、走索引、控制数据量。
最后送你一个排查口诀：看到事务先问边界，看到异常先看回滚，看到锁先查索引，看到慢先抓连接。这四个问题想清楚了，@Transactional对你来说就不再是玄学，而是一个真正可控的工具。
