SpringBoot 的Transactional看起来像是一个加在方法上就能完事的魔法开关但真相是这枚开关背后埋着无数颗地雷踩中一颗你的数据一致性就碎成渣。我见过太多在开发环境里跑得欢、一上线就被并发打爆的事务代码也见过深夜被数据错乱电话吵醒的技术人。今天不聊教科书上的概念只谈那些你大概率踩过、或者正在踩的坑以及怎样在代码里提前给自己留条命。事务失效的第一现场你以为你开了其实没开最常见的翻车姿势就是同一个类里的方法调用Transactional方法。比如 ServiceA 里的 methodA 调用了同类中的 methodB而 methodB 标注了事务注解。你满心以为 methodB 会开启事务实际上 Spring 的代理机制只对“外部调用”生效内部this.methodB()直接穿透代理事务注解形同虚设。更隐蔽的是如果 methodA 本身没有事务注解那么 methodB 里万一抛了异常连回滚都做不到。另一个高频漏网之鱼是Transactional加在了非 public 方法上。Spring 默认只能代理 public 方法private 或包级方法上的注解会被默默忽略连警告都没有。你写的那行注解就像贴在玻璃窗上的符咒好看但没用。尤其当你用了 Spring Boot 的 CGLIB 代理时私有方法根本不会进入拦截逻辑。规避方式把需要事务的逻辑单独放到另一个 Service Bean 中或者通过ApplicationContext.getBean(...)拿到代理对象再去调用。同时把你的事务注解当成“只能修饰 public 方法”的纪律来遵守。另外建议在测试时故意抛个异常看看数据是否真回滚别等上线了再验证。异常被吞事务比你想象中更迟钝事务回滚的前提是异常能传播到 Spring 的拦截器。但很多人喜欢在 service 内部try-catch把异常吃掉然后返回一个Result.success(false)。异常被吞掉的那一刻事务就永远不可能回滚因为拦截器看到的是“正常返回”。更危险的做法是 catch 里打印一行日志然后继续往下执行数据已经写了一半后半段逻辑却用了错误的数据。还有一种情况抛出的异常不是RuntimeException或Error。Spring 默认只对这两类异常回滚如果你在方法里抛了个IOException受检异常事务照样提交。你以为的“兜底”其实是“裸奔”。这背后是 Spring 的设计哲学受检异常往往代表业务可处理的异常默认不强制回滚。务必记住除非你有极强的理由否则在事务方法内部不要捕获任何异常把异常交给 Spring 处理。如果你必须捕获请在 catch 块里throw new RuntimeException(...)或TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()手动标记回滚。同时显式指定rollbackFor Exception.class彻底消除受检异常的灰色地带。这是事务设计中最廉价却最有效的保险。事务的传播属性玩脱了就是连锁反应Spring 提供了七种传播级别大多数人只用了默认的REQUIRED但现实生产环境远比默认值复杂。比如你有一个PROPAGATION_REQUIRES_NEW的方法调用了另一个REQUIRED方法原本想“各回各的”结果因为外层方法已经开启事务内层方法共享了同一个事务内层异常可能导致外层整体回滚或者外层提交把内层的半成品也提交了。典型场景是在一个事务里循环发送消息或调用外部接口——外部调用失败整个库存扣减却被回滚用户订单却已生成。更隐蔽的是PROPAGATION_NESTED和PROPAGATION_REQUIRES_NEW的区别。NESTED 是保存点回滚如果内层异常被捕获外层可以继续但 REQUIRES_NEW 会挂起外层事务内层独立提交一旦外层后续失败内层已经提交的数据永远无法跟着回滚。很多人把 NESTED 当成“子事务”用理解错了两个级别的语义结果在复杂的嵌套调用中产生脏数据。规避建议先把传播属性在团队内做一次圆桌评审把常用的三种REQUIRED、REQUIRES_NEW、NESTED的语义和适用场景写在规范里。每多一个事务嵌套你的回滚边界就多一份不确定性。能用无嵌套的扁平化设计就绝不要为了代码组织而搞出五层深的事务调用。隔离级别的烟幕弹你设置的读已提交可能根本不生效SpringBoot 默认用数据库的隔离级别MySQL 默认是REPEATABLE_READPostgreSQL 默认是READ_COMMITTED。很多人在Transactional上写了isolation Isolation.READ_COMMITTED满心以为自己规避了幻读却忽略了事务方法一旦开启了连接池中的已有连接隔离级别是否真的被切换取决于连接池的配置。比如 HikariCP 默认会执行setTransactionIsolation但如果你手动配置了连接初始化 SQL 覆盖了隔离级别那注解上的设置可能被冲掉。更常见的是长事务与隔离级别叠加的慢性毒药。当一个事务在READ_COMMITTED下跑了 5 秒期间其他会话修改了这 5 秒内你读过的数据你后续基于早期读取的值做更新就会产生“丢失更新”。有人试图用SELECT FOR UPDATE加锁但锁本身是比事务更复杂的野兽——忘了在事务内使用锁锁会在该语句所在事务提交后立即释放下一次读又拿到旧值。真正该做的事先确认数据库默认隔离级别再决定注解里到底写不写。如果你的业务真的需要SERIALIZABLE请先想一想是不是设计有问题——高并发下序列化级别几乎等价于自残。多花点时间在减少事务粒度上这比盲目调隔离级别有效 100 倍。长事务慢 SQL 只是表面拖垮的是整个连接池一个导致脏读、超时和死锁的恶性循环往往始于一个“只读”的长事务。有人在事务里执行大量无关查询或者调外部 API 等响应事务会长时间占用数据库连接而连接池总量有限。一旦连接被占满后面的请求全部排队等连接系统整体 RT 飙升最终雪崩。更致命的是长事务会让数据库层面出现很长的undo log链导致历史版本数据无法清理写入性能持续劣化。看到过最离谱的代码在一个Transactional方法里 for 循环一万次每个循环都进行一次select和insert整个事务时长达到十几秒。开发还说“没问题反正数据能一次性提交”。可这十几秒里其他请求在等待连接数据库锁冲突概率指数上升高峰期直接打挂库。规避策略事务方法只做必要的数据修改和读取把业务计算、外部调用、文件操作放到事务外。如果必须批量操作用REQUIRES_NEW每 N 条提交一次或者改用批处理框架。同时给所有事务方法设置超时时间timeout 3之类的值用硬性手段防止“失控事务”。记住事务不是保护伞而是资源的监牢你锁得越久别人死得越快。多数据源与分布式事务你为单体写的事务在微服务里全是笑话SpringBoot 里配置多个数据源时Transactional默认只绑定在主数据源的事务管理器上。如果你在方法里同时操作主库和从库注解只管得住主库那一份从库的写入要么没有事务要么自己提交。很多人以为 Spring 会“智能地”管理所有数据源这是天大的误解。更麻烦的是如果你用了DataSource或动态数据源切换切换发生在事务开启之后那么切换后的数据源根本不在当前事务管理器的控制范围内事务就变成了“部分提交”。而当微服务架构出来你调用远程服务时本地数据库事务和远程服务的事务天然是分裂的。你不可能用一个本地事务去控制一个远程调用的事务这是分布式环境下最基本的物理现实。有的人尝试在本地事务里调用远程接口把远程调用纳入本地级联事务的幻想中结果就是网络超时导致本地回滚远程却已经执行成功两边数据从此分道扬镳。正解多数据源场景下要么明确“一个事务只管一个库”要么引入分布式事务框架如 Seata但必须接受其带来的复杂度和性能开销。对绝大多数业务而言放弃强一致采用最终一致 补偿机制才是最成熟的做法。你有没有想过为什么银行转账也要等一会儿才到账因为他们在故意牺牲瞬时一致性换取系统稳定。事务与线程池异步任务里的“事务”其实是薛定谔的SpringBoot 里经常有人用Async方法或者新起一个线程去执行一段“受事务保护”的代码。异步方法里的Transactional能生效但事务边界和调用方的事务隔离。如果调用方有一个事务新线程会启动一个新的事务因为不同线程上下文两个事务互不可见即使子线程抛异常父线程也无法感知更无法回滚。于是你看到主流程返回成功后台线程写入了一半数据后失败留下一坨半成品。更隐蔽的问题是TransactionSynchronizationManager是基于线程局部变量的当你在线程池中复用线程时如果上一个线程的事务上下文没被清理干净新任务可能读到脏的同步状态导致事务边界错乱。这绝不是危言耸听在 Tomcat 线程池与业务线程池混用的场景下很容易碰到“莫名其妙回滚”或“事务不生效”的诡异 Bug。规避方案异步任务里不要依赖注解事务要么自己显式编程式事务TransactionTemplate要么把异步任务拆成独立的、可幂等重试的作业。对于需要与主事务保持一致的异步逻辑建议用本地消息表 定时任务投递而不是指望一次线程调用就搞定一致性。事务设计的终极拷问你真的需要事务吗最后走到一个反直觉的陷阱很多代码把事务当作万能胶水什么逻辑都往事务里塞但事务本身也有成本、有副作用。比如你只是想插入一条日志却开了个大事务你只是想查一份报表却用了Transactional(readOnly true)它只是优化提示并不保证快照隔离。事务的本质是“为了不可分割的原子操作付出代价”如果某个操作允许短暂的不一致那么放弃数据库事务换取更高的吞吐和可用性是更聪明的架构选择。比如交易流水和账户余额可以设计成先写流水独立事务再通过异步任务更新余额若失败则补偿。而不是把所有操作揉进一个事务里让两个高频更新互锁。伟大架构师与平庸码农的区别往往不是会不会用事务而是知道哪里有勇气不用事务。记住这句话事务是最后一道防线不是第一选择的武器。在 SpringBoot 的世界里注解是糖但糖吃多了会蛀牙。事务陷阱的本质不是语法不懂而是对边界、语义和并发机制的敬畏不够。希望这篇长文能成为你排查事务问题时的镜子——当你下次在Transactional里看到 try-catch或者在一个长方法里堆了无数操作请停下来想一想这些代码在 100 个并发请求下会怎么死到那时你已经比一半的开发更接近真相了。