基于前文对 Spring 事务传播机制、@Transactional 注解配置及"自调用失效"陷阱的讨论，@Transactional 失效通常源于 AOP 代理机制的限制 或 运行时环境配置不当。以下是导致事务失效的常见场景及原因分析：
一、代码结构导致的失效（最常见）
同类自调用（Self-Invocation）
现象：类内部方法 A 直接调用带 @Transactional 的方法 B。
原因：Spring 事务基于 AOP 代理。内部调用使用的是 this 对象（目标对象），绕过了代理对象，导致事务切面无法拦截。
解决：将方法 B 移至另一个 Service 类，或通过注入自身代理对象调用。
方法非 public
现象：注解标注在 private、protected 或默认权限方法上。
原因：Spring AOP 默认只拦截 public 方法。非 public 方法不会被代理增强。
解决：确保事务方法为 public。
异常被捕获未抛出
现象：方法内使用 try-catch 捕获了异常，且未在 catch 块中重新抛出或手动设置回滚。
原因：Spring 只有在接收到未捕获的异常时才会触发回滚。若异常被"吞掉"，Spring 认为方法正常执行，从而提交事务。
解决：在 catch 块中抛出异常或调用 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。
二、配置与类型导致的失效
数据库引擎不支持
现象：MySQL 使用 MyISAM 引擎。
原因：MyISAM 不支持事务。无论 Spring 如何配置，底层数据库无法执行回滚操作。
解决：将表引擎修改为 InnoDB。
异常类型不匹配
现象：方法抛出受检异常（Checked Exception，如 IOException），但未配置 rollbackFor。
原因：Spring 默认只对 RuntimeException 和 Error 进行回滚。受检异常默认触发提交。
解决：使用 @Transactional(rollbackFor = Exception.class) 指定回滚异常类型。
Bean 未被 Spring 管理
现象：类未添加 @Service、@Component 等注解，或未在 XML 中配置。
原因：若对象不是由 Spring 容器创建的 Bean，则不会生成 AOP 代理，事务注解自然无效。
三、其他特殊场景
异步方法调用
现象：在 @Async 方法中使用事务，或主线程调用异步方法。
原因：异步方法由独立线程执行，若未正确配置事务管理器或线程池，可能导致事务上下文丢失。
多数据源配置错误
现象：项目中存在多个数据源，但未指定正确的 transactionManager。
原因：Spring 默认使用名为 transactionManager 的事务管理器。若未明确指定，可能使用了错误的数据源事务管理器，导致对特定数据库的操作未纳入事务。
四、总结
核心原因：代理绕过（自调用、非 public）、异常处理不当（捕获未抛出、类型不匹配）、底层不支持（MyISAM）。
排查建议：优先检查自调用和异常捕获逻辑，其次确认数据库引擎和 Bean 管理状态。
关联前文：理解这些失效场景有助于更准确地应用前文所述的传播行为（如 REQUIRES_NEW），避免因代理失效导致独立事务预期落空。