基于前文对 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），但未配置 r
