1. 从一次线上事故说起Transactional 的“省心”假象前阵子帮一个团队排查线上数据异常现象很典型用户下单后库存偶尔会被多扣订单状态却显示未支付。查了一圈代码逻辑没问题SQL 没问题最终定位到一个被 Transactional 包裹的 Service 方法上。方法里有两步操作先扣库存再调远程接口生成物流单。远程接口超时了异常抛了出来按理说事务应该回滚库存不该变。但实际结果是库存扣了事务没回滚。问题就出在声明式事务的“省心”上。很多人把 Transactional 当成一个万能开关以为加上注解就等于上了保险。但 Spring 的声明式事务本质上是基于 AOP 代理实现的它的生效条件比你想象的苛刻得多。一旦遇到方法自调用、异常被吞、代理失效这些场景注解就变成了摆设而且它失效的时候往往不会报错数据就这么安安静静地错了。这篇文章不是劝你完全不要用 Transactional而是要告诉你什么时候它靠得住什么时候它就是定时炸弹以及比它更可控的编程式事务应该怎么用。如果你在项目里写过Transactional开头的代码或者正在为一个诡异的数据问题焦头烂额这篇文章值得你花十分钟读完。2. 注解背后的代理机制为什么一行注解会坑到你2.1 代理机制的隐藏前提Transactional 之所以能工作靠的是 Spring 容器在启动时为 Bean 生成代理对象。你调用的是代理对象代理会先开启事务再调用你写的真实方法。听起来很顺滑但这个机制有一个致命前提你调用的必须是代理对象。代码里最容易踩的坑就是自调用。假设类里有这么一段Service public class OrderService { public void createOrder(OrderDTO dto) { // 调用同类中的另一个方法 this.doProcess(dto); } Transactional public void doProcess(OrderDTO dto) { // 扣库存、写订单 } }createOrder里的this.doProcess()是直接调用真实对象的方法根本没有经过代理对象。Spring 里那套事务拦截逻辑都写在代理里你绕过了代理事务自然就不生效。这是一个非常经典的隐性 Bug本地测试可能根本测不出来因为 A 方法直接调 B 方法的场景到处都是没人会去检查“这个方法是不是从代理进的”。除了自调用下面这些场景都可能导致事务悄悄失效方法被 private、final、static 修饰。Spring 的 CGLIB 代理无法代理 final 类和方法private 方法则压根不会被代理感知。方法在this引用上被调用绕过了代理。异常被 try-catch 吞掉事务感知不到异常于是正常提交。异常类型不是 RuntimeException同时没有指定 rollbackFor默认是不会触发回滚的。其中“异常被吞”是最隐蔽的。很多业务代码里都有这样的习惯Transactional public void updateStatus() { try { changeData(); } catch (Exception e) { log.error(更新失败, e); } }你的本意是“出了错不用中断主流程记录下来就行”。但在事务眼里这个方法正常执行完了没有异常抛出来那就提交吧。结果就是数据改了但事务实际上只提交了半个流程。这类问题在代码评审里非常难发现因为每个人看自己的代码都觉得没问题。2.2 默认回滚规则带来的意外Transactional 默认只对 RuntimeException 和 Error 回滚对受检异常Checked Exception不回滚。这就导致一个特别常见的场景你在方法里调了一个声明了throws Exception的远程接口它抛出了 IOException你的库存扣了远程调用失败了事务却选择“原谅它”——提交。很多人是在生产环境炸了之后才知道有这个默认规则。要处理受检异常必须在注解上声明 rollbackForTransactional(rollbackFor Exception.class)可是加了这个就一定安全吗不一定。如果你调用的远程接口在某个第三方 SDK 里已经帮你把异常转成了自定义异常而这个自定义异常不是 RuntimeException 的一个子类你又没在注解里加对应配置那依旧不回滚。这类问题不是“查一下文档就能避开”的它需要你真实了解每个依赖里抛出的异常类型。说白了Transactional 把事务的“开”和“关”交给了框架但你期望的语义“我这方法要么全成要么全不成”和框架的实际行为“只要不抛运行时异常我就当成功”之间存在很大的解释空间。这个空间一旦被业务代码填充就容易出事故。2.3 代理失效后不会报错最气人的地方是Transactional 失效后不会抛任何异常代码照样跑日志照样打接口照样返回正常。你的数据是在一个错误的、无保护的状态下被改掉的系统却没有任何迹象。等你事后排查翻代码、翻日志、翻监控都找不到线索。这是我见过太多团队踩坑后的真实感受用注解声明事务就是拿系统稳定性换代码整洁度一旦格式不匹配它就变成一颗哑弹。不是不能用而是要清楚的知道它在什么条件下才有效。3. 事务粒度失控注解把“边界”交给了习惯3.1 长事务的连锁反应除了失效问题Transactional 的另一个大问题在于它把事务边界的控制权交给了“方法”。开发者的习惯是什么一个 Service 里放多项业务操作时最简单的方式就是在方法头上加注解。问题是方法的粒度往往不等于事务应该覆盖的粒度。举个典型例子。一个定时任务方法里调了一个远程接口再批量更新数据库你直接给整个方法加上 Transactional。如果远程接口平均耗时 3 秒那数据库连接就被这个事务攥在手里 3 秒。高并发场景下数据库连接池里的连接被耗尽后面所有请求都排队等连接接口响应时间从 100ms 变成 5s最后雪崩。这类问题在压测阶段不容易暴露因为压测一般不会模拟真实的远程依赖延迟抖动。等到线上流量上来一个慢接口就能把整个服务拖垮。键人处理过的一个真实案例是一个加了 Transactional 的批处理方法内部循环调了外部查询接口单次循环可能要等 2 秒50 条数据循环下来事务被攥了 100 秒数据库连接池直接打满。长事务还带来另一个隐患持有的数据库锁时间变长。如果事务体内的所有写操作集中在同一个表的不同行InnoDB 的行锁会被覆盖大范围一旦并发事务要更新同一批行就会出现锁等待进一步加剧死锁风险。数据库死锁的本质原因往往是“事务时间过长 锁范围过大”而这两个变量在 Transactional 里几乎完全不受控。3.2 业务代码和事务边界的强耦合用注解声明事务本质上就是把“事务边界”和“方法边界”绑死。一个方法里如果有一半的代码不需要事务比如查配置、调缓存、组装数据你也必须把它们全部塞进事务里因为注解管不了方法内部的细分。这种强耦合带来的直接后果是事务边界被无意识扩大。很多人写代码时根本不会去区分“哪些操作必须在一个事务里”和“哪些操作根本不需要事务”随手一个注解就把方法打成一个大事务。代码能跑性能却一点点被侵蚀。更麻烦的是维护阶段。三个月后另一个人改了这段代码在一个本来只做读操作的方法上顺手加了几行写操作为了保险又补了一个 Transactional。没人会去评估事务范围也没人会去思考新增的写操作是否应该独立提交。注解是个低门槛工具正因为门槛低谁都会加导致事务边界越来越膨胀直到某天线上出问题。3.3 团队协作中的隐性规范风险Transactional 还有一个非常现实的问题它对团队的代码约束能力极差。编译期不检查、评审时不显眼、测试时难覆盖加上 Spring 官方文档默认推荐声明式事务于是人人都敢写。可“人人都会写”和“人人都写对”是两回事。我在多个团队见过同样的场景代码评审时大家几乎不怎么看 Transactional 有没有条件满足只看有没有加。框架里那么多注意事项普通开发者根本不会逐条对着文档自查。经验丰富的工程师提醒一句“这里不能用注解”新人往往会反问“为什么不用官方文档就推荐这么写啊”。这种认知差在团队里反复出现很难通过几场培训根治。所以与其期待每个人都能精准掌握注解的适用边界不如把事务管理的权力从“习惯”手里收回来交给更直白、更可控的代码。4. 编程式事务翻身TransactionTemplate 的正确用法4.1 TransactionTemplate 的核心写法如果你对事务边界有精确要求或者已经吃过 Transactional 的亏编程式事务是你的更优解。Spring 提供的 TransactionTemplate 用起来很简单Service public class OrderService { private final TransactionTemplate transactionTemplate; public OrderService(TransactionTemplate transactionTemplate) { this.transactionTemplate transactionTemplate; } public void createOrder(OrderDTO dto) { // 事务外代码校验、组装、调远程查询都没有问题 boolean result transactionTemplate.execute(status - { try { // 事务内代码扣库存、写订单表 deductStock(dto.getSkuId(), dto.getQuantity()); insertOrder(dto); return true; } catch (Exception e) { // 手动回滚 status.setRollbackOnly(); log.error(创建订单失败事务回滚, e); return false; } }); // 事务外代码发送消息、记录审计日志 if (result) { notifyAfterOrderCreated(dto); } } }这段代码的关键价值在于事务边界一目了然地区分为“事务内”和“事务外”。需要在一个原子操作里完成的部分放进execute回调不需要的部分放外面。你可以精确控制事务开始时点也能在 catch 里决定要回滚还是要继续执行其他逻辑。在此基础上隔离级别和传播行为仍然可以按需设置transactionTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED); transactionTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);这些设置和 Transactional 里的属性一一对应但它是通过代码显式控制的谁阅读代码都能看懂事务的边界和规则不需要去猜“这个注解有没有生效”。4.2 和 Transactional 用相同的事务管理器需要强调一下TransactionTemplate 和 Transactional 在底层使用的是同一个事务管理器两者之间不存在“一个真一个假”的区别。它们只是事务的两种编程接口同一个线程里混用也不会冲突。这意味着你可以在项目里渐进式迁移先在新代码中用 TransactionTemplate老代码里的 Transactional 慢慢改过来两个方式可以共存。我自己的习惯是凡是方法里只做一次单表写操作的用 Transactional 没问题凡是涉及两步以上写操作、或者方法里存在外部调用、或者事务内包含循环处理的一律用 TransactionTemplate。这能最大程度避免“事务边界比业务边界大”的问题。4.3 编程式事务的追溯性优势程序式事务在看代码时就能直接说清楚“哪一步开始算事务哪一步结束”对事故分析意义很大。生产问题排查时第一件事就是确认事务到底覆盖了哪些操作。Transactional 的场景下你必须先把代理机制、自调用、异常处理全部过一遍才能确定事务有没有按预期生效。而 TransactionTemplate 的代码里execute的边界就是事务的边界不存在“代理有没有走到的思维负担”。另外在代码评审时TransactionTemplate 的可读性也更好。reviewer 能在 diff 里直接看到事务的范围而不是扫一眼方法头有没有注解。对于大事务、长事务的诊断编程式事务能显著减少排查成本。4.4 性能层面的对比事务的性能差异不在“用什么方式声明”而在于“事务里塞了多少操作、持锁多久”。但从控制角度TransactionTemplate 能更精细地压缩事务范围。同一个业务里把外部调用、非核心写入挪出事务块事务时间可能从 2 秒缩到 20 毫秒吞吐和连接占用自然都会变好。这种优化在 Transactional 里很难落地因为它的边界是方法本身。5. 什么时候还能用 Transactional什么时候千万别用5.1 还能用注解的场景直接在方法上启用场景我总结了一些条件方法只做一次数据库写入比如单表状态更新且该方法不会被同类内部直接调用。事务的处理时间很短整体耗时在几十毫秒级别不会有长事务风险。方法内没有远程调用、网络等待、批量循环等可能拉长事务的操作。明确了异常处理规则异常会原样抛出不会在方法内被吞掉。如果你是独立开发一个小型服务代码量少、调用链短用 Transactional 确实能减少模板代码量写起来也快。但要记住这建立在“你对这个方法的所有执行路径都清楚”的前提下。比如一个最典型的简单场景Transactional public void updateUserStatus(Long userId, Integer status) { userDao.updateStatus(userId, status); }这个场景事务时间极短、代码路径唯一、异常会直接抛出用注解完全合理。这类代码哪怕被自调用通常也只会影响单行更新不会引发连锁问题。5.2 必须避开注解的场景以下几类场景我强烈建议不要用 Transactional第一类方法体内有多个写操作且存在依赖关系。比如先插入订单主表再插入订单明细表任何一个失败都要全部回滚。这类场景虽然 Transactional 也能做但一旦哪天方法被拆成两步调用事务就会失效隐患很大。用 TransactionTemplate 更稳。第二类事务内有外部调用。无论是调远程接口还是走消息队列只要事务内的操作要等待外部响应就别用注解。长事务带来的锁竞争和连接耗尽问题会让整个服务雪崩。第三类批处理场景。定时任务、数据迁移、批量导入这类处理一次可能涉及上千行数据。如果整体用一个事务上万行数据全部成功还好中途失败必须花费巨大代价回滚。正确的做法是分批提交每批一个小事务然后用补偿记录或重试策略来处理失败批次。Transactional 会把所有批次捆在一个事务里完全违背批处理的初衷。第四类事务内存在不可控的用户输入或外部系统状态。比如在事务内等待用户点击确认这是极其危险的设计。数据库连接一直占着用户一直不点连接池就满了。这类场景必须把事务放在“用户点确认后的短暂业务处理”里而不是放在前面等待的漫长流程里。5.3 一个实用的决策流程我建议团队内部用这个简单的流程来判断事务该怎么写先问这个方法是不是一个“纯单点写操作”如果是且方法不会被同类内部直接调用可以加 Transactional。再问方法里有没有非数据库的操作有的话把重复操作和资源占用部分移出事务事务里只留必须原子化的数据库操作。然后问方法会不会被同类方法直接调用会的话想办法避免自调用或者直接改成 TransactionTemplate。最后问这个方法失败后数据的脏状态是否有兜底机制如果没有请务必使用 TransactionTemplate 并显式捕获异常把回滚逻辑写在看得见的地方。这套流程不复杂但能帮你避掉绝大多数事务失效和长事务问题。它最大的好处是迫使你思考“事务的边界到底是什么”而不是无脑加注解。6. 踩坑实录从“全注解”迁移到“混合模式”的经验如果你已经在项目里用了一堆 Transactional现在想改我建议别搞大拆大改而是按风险等级分阶段来。第一步先把批处理和定时任务里的注解改掉。这些场景既是长事务高发地又不会影响在线用户的手动操作改错了顶多是任务失败重跑风险可控。用 TransactionTemplate 分批提交每批处理完记录进度下次执行从上次位置继续。第二步把事务内有远程调用的方法改掉。这类方法的执行路径里只要有第三方抖动事务时间就会被拉长。改完之后盯一段时间监控看看连接池的等待曲线有没有变化。我见过一个服务改完这类方法后数据库连接池使用率从 80% 降到了 40%效果非常明显。第三步把多表写入、关键链路中的 Service 方法改掉。这类改动对代码逻辑影响大建议配合充分的测试和回归。改的时候只动事务声明方式不动业务逻辑尽量把 diff 控制在事务代码本身。迁移过程中有一个小技巧在事务方法里加一个日志埋点打印事务状态。比如transactionTemplate.execute(status - { log.info(事务开始, 传播行为: {}, status.isNewTransaction()); // 业务代码 });这样做不是给系统自找麻烦而是为了在线上出问题时能直接从日志里看到事务到底有没有生效、是不是新建事务、回滚标志有没有被设置。你可以把这些日志暂时留着跑一段时间没问题之后再降级到 DEBUG 级别。改完一批之后老代码里的 Transactional 可以留着只要它满足前面说过的“简单场景”不急着大规模替换。项目里存在两种事务写法并不丢人只要能说清楚每段代码选了哪种方式及原因代码维护就不会乱。最后再分享一个偏门技巧如果某个 Transactional 方法被同类调用导致事务失效而你暂时来不及改成 TransactionTemplate最简单的临时修复是把被调用方法移到另一个类里通过注入代理 Bean 来解决。但这种方式要避免陷入设计的混乱所以最终建议还是用 TransactionTemplate 一劳永逸地把事务的控制权回到代码手理。事务这个事儿本质上是边界管理。注解给你提供了便利也把边界藏进了框架的行为里。想清楚“哪些操作必须同时成功或同时失败”然后用最直白的代码写出来你的系统就不会再被“明明加了注解为什么还是出错”这类问题缠住。