Spring事务不生效的8类常见原因：类未被Spring管理、方法非public、this调用绕过代理、异常未抛出或未配置回滚、数据库不支持事务、传播行为错误、异步/多线程破坏上下文、final/static方法或未开启事务管理。
Spring事务不生效，不是代码写错了，而是“没被Spring真正管到”——事务基于AOP代理，只要调用链脱离了代理上下文，或者配置/环境踩了坑，事务就形同虚设。下面挑最常见、最易忽略的8类场景说清楚。
类没被Spring管理
事务方法所在的类必须是Spring容器中的Bean，否则代理根本不会生成。比如：
- 忘了加 @Service、@Component 等注解
- 用 new 关键字手动创建对象（绕过IoC容器）
- 配置类未被 @Configuration 标记或未被扫描到
解决办法：确保类由Spring托管，且能通过 @Autowired 正常注入。
方法访问权限不对
@Transactional 只对 public 方法生效。Spring默认用JDK动态代理或CGLIB，它们都只能拦截public方法调用：
- private / protected / package-private 方法上加 @Transactional → 无任何效果
- 官方文档明确说明：非public方法标注后不会报错，但事务设置完全不生效
如真需在非public方法用事务，得切换为AspectJ静态织入（不推荐，增加复杂度）。
同一类中this调用导致代理失效
这是高频陷阱。事务靠代理对象触发，而 this.methodB() 是直接调用目标对象，绕过了代理：
- 方法A（无@Transactional）调用本类的 methodB（有@Transactional）→ methodB 事务不生效
- 即使A自己也有@Transactional，this调用依然不走代理
正确做法：让Spring注入自身（@Autowired this），再通过注入的引用调用；或改用ApplicationContext获取代理Bean。
异常处理不当，事务不回滚
事务是否回滚，取决于“有没有把异常抛给事务切面”：
- 默认只对 RuntimeException 和 Error 回滚，抛出 IOException、SQLException 等检查异常 → 不回滚
- 方法里 try-catch 住异常又没重新抛出 → 切面收不到异常，认为执行成功
对策：
– 配置 @Transactional(rollbackFor = Exception.class)
– 或在catch里调用 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()
数据库或数据源不支持事务
再完善的Spring配置，也救不了底层不支持事务的环境：
- MySQL使用 MyISAM 引擎 → 无事务能力（InnoDB才支持）
- 未配置 PlatformTransactionManager Bean（比如漏了 @Bean 声明）
- 多数据源时，只配了一个事务管理器，但业务跨了多个数据源
注意：Spring Boot自动配置会帮你配好DataSourceTransactionManager，但自定义多数据源时务必手动配齐。
事务传播行为配置错误
传播机制决定事务如何“嵌套”或“挂起”，错配会导致事务意外终止或隔离失败：
- Propagation.NOT_SUPPORTED：挂起当前事务，以非事务方式运行 → 本该回滚的操作可能提交
- Propagation.REQUIRES_NEW：新建事务，但若外层已异常，内层成功提交 → 数据不一致风险
- 默认 REQUIRED 最稳妥，嵌套调用通常应保持它
异步或多线程操作破坏事务上下文
Spring事务依赖 ThreadLocal 绑定当前事务状态：
- 用 @Async 或 new Thread() 启动子线程 → 子线程拿不到事务上下文
- 主线程事务已提交，子线程还在操作DB → 脏写、丢失更新
不能靠“加事务注解”解决，得换思路：用消息队列+最终一致性，或引入Seata等分布式事务框架。
其他容易忽略的点
这些虽不总出现，但一旦发生就很难排查：
- final 或 static 方法 上加 @Transactional → 无法被代理覆盖，事务失效
- 未开启事务管理：@EnableTransactionManagement 漏配（尤其在非Boot项目）
- AOP切面顺序冲突：比如自定义日志切面在事务切面之前，且吞掉了异常
基本上就这些。核心就一条：Spring事务不是魔法，它严格依赖代理机制和上下文传递。抓住“谁调用、怎么调、抛什么、在哪跑”这四个关键点，90%的失效问题都能快速定位。
