在 Spring 框架中，@Transactional 注解基于 AOP（面向切面编程）代理机制实现。如果配置或使用不当，事务可能 silently fail（静默失效），即不报错但也不回滚或不开启事务。

1. 同类内部方法调用（Self-Invocation）

这是最常见的失效场景。

‌现象‌：在一个 Service 类中，方法 A（无事务）直接调用方法 B（有 @Transactional）。

‌原因‌：Spring 的事务管理是通过代理对象（Proxy）实现的。当外部调用方法 A 时，经过代理，但方法 A 内部通过 this.methodB() 调用方法 B 时，是直接调用目标对象的方法，‌绕过了代理对象‌，因此事务拦截器无法介入。

‌代码示例‌：

@Service
public class OrderService {
    public void processOrder() {
        // 直接调用，事务失效
        updateStatus(); 
    }

    @Transactional
    public void updateStatus() {
        // 数据库操作
    }
}

‌解决方案‌：

1. ‌注入自身代理‌：在类中注入自身 Bean，通过代理对象调用。
2. ‌提取到另一个 Service‌：将方法 B 移到另一个 Service 类中，通过依赖注入调用。
3. ‌使用 AopContext‌：((OrderService) AopContext.currentProxy()).updateStatus()（需配置 exposeProxy=true）。

2. 方法修饰符非 Public

‌现象‌：@Transactional 标注在 private、protected 或默认（package-private）方法上。

‌原因‌：Spring 的 AOP 代理（无论是 JDK 动态代理还是 CGLIB）通常只能拦截 public 方法。对于非 public 方法，代理无法生成有效的拦截逻辑，注解会被忽略。

‌解决方案‌：确保标注 @Transactional 的方法是 public 的。

3. 异常被捕获或未正确配置回滚规则

‌现象‌：代码中抛出了异常，但事务没有回滚。

‌原因‌：

1. ‌异常被 Try-Catch 吞掉‌：如果在 @Transactional 方法内部捕获了异常且未重新抛出，事务管理器感知不到异常，认为执行成功，从而提交事务。
2. ‌异常类型不匹配‌：Spring 默认只在抛出 ‌unchecked Exception‌（运行时异常，如 RuntimeException）时回滚。如果抛出的是 ‌checked Exception‌（如 IOException、SQLException），默认不会回滚。

‌解决方案‌：

1. 不要在事务方法内部随意捕获异常，或在 catch 块中手动设置 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。
2. 指定回滚异常类型：@Transactional(rollbackFor = Exception.class)，建议对所有业务事务都加上此配置。

4. 数据库引擎不支持事务

‌现象‌：代码配置正确，但数据依然无法回滚。

‌原因‌：使用的数据库表存储引擎不支持事务。例如，MySQL 中使用 ‌MyISAM‌ 引擎，它不支持事务；必须使用 ‌InnoDB‌ 引擎。

‌解决方案‌：检查并修改数据库表的存储引擎为 InnoDB。

5. 传播行为（Propagation）配置错误

‌现象‌：期望新建事务或加入事务，但实际行为不符合预期。

‌原因‌：

• PROPAGATION_SUPPORTS：如果当前没有事务，则以非事务方式运行。
• PROPAGATION_NOT_SUPPORTED：如果当前有事务，则挂起事务，以非事务方式运行。
• PROPAGATION_NEVER：如果当前有事务，则抛出异常。

‌解决方案‌：根据业务需求选择合适的传播行为，默认通常使用 PROPAGATION_REQUIRED。

6. 多注解冲突或异步调用

‌现象‌：@Transactional 与 @Async、@Retryable 等注解组合使用时失效。

‌原因‌：

• ‌@Async‌：异步方法会在新的线程中执行，而 Spring 的事务上下文是绑定在当前线程（ThreadLocal）上的。新线程无法继承原线程的事务上下文，导致事务失效或部分提交。
• ‌@Retryable‌：如果重试机制位于事务之外或代理顺序不当，可能导致重试时事务状态混乱。

‌解决方案‌：

• 避免在同一个方法上同时使用 @Transactional 和 @Async。应将异步逻辑抽取到单独的方法或服务中，并注意事务边界。
• 调整 AOP 代理的顺序或确保重试逻辑在事务管理之外合理设计。

7. 数据源或事务管理器配置错误

‌现象‌：应用了多个数据源，但未指定正确的事务管理器。

‌原因‌：在多数据源场景下，如果没有明确指定 @Transactional(transactionManager = "xxxTransactionManager")，Spring 可能使用默认的事务管理器，导致操作的数据源与事务管理的数据源不一致。

‌解决方案‌：在多数据源配置中，明确指定事务管理器名称。