同类方法内部调用代理直接绕过了这是事务失效的头号原因占比超过一半。Spring事务依赖AOP动态代理只有通过代理对象调用方法时事务拦截器才会介入。在同一个类里用this.methodB()调用另一个标注了Transactional的方法this指向的是当前对象不是代理对象注解形同虚设。解决方案有三种注入自身实例、使用AopContext.currentProxy()、或者干脆把方法拆到另一个Service里。方法不是public注解被默默忽略Spring AOP默认只拦截public方法。把一个Transactional标在private或protected方法上注解会被无声地忽略掉不报错、不告警代码照常跑事务就是不生效。同样的情况也适用于final和static修饰的方法final方法无法被CGLIB子类重写static方法属于类而非实例代理机制对它们无能为力。异常被catch吞掉拦截器一无所知Spring判断是否回滚的唯一依据是异常有没有从目标方法抛出来。如果代码里用try-catch把异常吃掉了事务拦截器感知不到任何异常自然会当作成功来提交。很多人习惯在事务方法里包一层try-catch做日志记录然后忘了重新抛出数据就这样“静悄悄地”写进去了。正确的做法是在catch块中抛出RuntimeException或者手动调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。抛出受检异常默认不回滚Spring事务默认只对RuntimeException和Error执行回滚对Checked Exception如IOException不做处理事务照常提交。这是一个极易踩坑的设计。解决方法很简单在注解上指定rollbackFor Exception.class覆盖所有异常类型。数据库引擎不支持事务这一点常被忽略。如果MySQL表使用的存储引擎是MyISAM那么Spring配置得再完美也无济于事因为MyISAM本身就不支持事务操作。只有InnoDB引擎才具备事务能力。排查事务问题时先确认表的引擎是不是InnoDB这是最基础的检查项。多线程环境下事务与线程绑定Spring的事务上下文通过ThreadLocal与当前线程绑定。如果在事务方法里新起一个线程去执行数据库操作子线程拿到的数据库连接和主线程不是同一个自然也不在同一个事务里。主线程回滚了子线程的操作已经独立提交了。这个坑在异步处理场景中尤其常见需要手动传递事务上下文或采用其他方案。传播行为配置错误Spring事务的传播行为决定了方法之间如何共享或新建事务。比如REQUIRES_NEW会挂起当前事务、新建一个独立事务内层方法一旦提交外层回滚也影响不了它。如果对外层回滚有强要求却把内层配成了REQUIRES_NEW就会出现“外层失败但内层已落库”的情况。Bean没有被Spring管理最容易被忽视的一种情况类上没有加Service、Component等注解或者对象是通过new手动创建的。Spring的事务管理依赖容器对Bean的代理一个不受容器管理的对象就算方法上加了注解也不会被代理增强。排查事务失效有个实用口诀先看代理走没走再看异常抛没抛最后看引擎和配置。具体来说第一步确认调用是否经过代理对象第二步检查异常类型和是否被吞掉第三步核对数据库引擎和事务管理器配置。线上环境一旦出现数据不一致别急着怀疑代码逻辑先排查事务是否真的生效了往往问题就出在这些不起眼的细节里。