AOP切面与@Transactional注解执行顺序如何确定？

Question

在Spring应用中，常遇到AOP切面（如自定义@LogExecutionTime）与@Transactional注解共存时事务未按预期生效的问题：例如切面中抛出异常却未触发事务回滚，或事务已提交后切面仍执行后续逻辑。根本原因在于**Spring AOP代理链中通知（Advice）的执行顺序由切面优先级（@Order或Ordered接口）和通知类型共同决定，而@Transactional本质是通过TransactionInterceptor（一个Around Advice）实现，其默认优先级为Ordered.LOWEST_PRECEDENCE（即最低优先级，最后执行）**。若自定义切面未显式指定@Order，其优先级默认为0，将先于事务拦截器执行——导致事务上下文尚未开启时切面已介入，或异常被切面吞没而未传播至TransactionInterceptor。如何准确控制二者执行次序（如确保日志切面在事务开启后、业务方法执行前切入），成为分布式事务与可观测性协同落地的关键难点。

Answer 1

```html

一、现象层：典型故障场景还原

• 日志切面吞没异常：@LogExecutionTime 中捕获 RuntimeException 并仅记录，未 re-throw → TransactionInterceptor 无法感知异常 → 事务不回滚
• 事务后置逻辑误执行：@AfterReturning 切面在 @Transactional 方法成功提交后仍执行清理逻辑，但数据库已不可见变更（因隔离级别或二级缓存）
• 事务上下文为空：@Around 切面中调用 TransactionSynchronizationManager.isActualTransactionActive() 返回 false，即使目标方法标注了 @Transactional

二、机制层：Spring AOP代理链执行时序模型

Spring 的代理链本质是 Advice 的责任链（Chain of Responsibility）。关键事实如下：

组件	通知类型	默认 Order 值	执行阶段
@LogExecutionTime（无@Order）	Around	0	早于事务拦截器
TransactionInterceptor	Around	Ordered.LOWEST_PRECEDENCE（2147483647）	最外层包裹
@Retryable 切面	Around	Ordered.HIGHEST_PRECEDENCE（-2147483648）	最内层包裹

三、诊断层：四步定位法

1. 启用 AOP 调试日志：logging.level.org.springframework.aop=TRACE
2. 打印代理链顺序：在配置类中注入 Advised 并调用 getAdvisors() 输出 order 值
3. 断点追踪：在 TransactionInterceptor.invoke() 和自定义 MethodInterceptor.invoke() 设置条件断点
4. 验证事务活性：在切面中插入 TransactionSynchronizationManager.getCurrentTransactionName() 断言

四、解法层：精准控制执行次序的三种范式

// ✅ 方案1：日志切面后置（事务开启后、业务前）
@Aspect
@Order(Ordered.LOWEST_PRECEDENCE - 1) // 紧邻 TransactionInterceptor 内侧
public class PostTransactionLoggingAspect {
  @Around("@annotation(org.springframework.transaction.annotation.Transactional) && execution(* *(..))")
  public Object logAfterTxStart(ProceedingJoinPoint pjp) throws Throwable {
    // 此时 TransactionStatus 已激活，可安全读取 isActive()
    return pjp.proceed();
  }
}

五、架构层：可观测性与事务协同设计原则

graph LR A[客户端请求] --> B[RetryableAdvice
Order=-2147483648] B --> C[ValidationAdvice
Order=-1000] C --> D[TransactionInterceptor
Order=2147483647] D --> E[Business Method] E --> F[LogExecutionTime
Order=2147483646] F --> G[MetricsExportAdvice
Order=2147483645] G --> H[响应返回]

六、避坑层：高频反模式清单

• ❌ 在 @Before 中抛出异常 → 绕过 TransactionInterceptor，事务不启动即失败
• ❌ 使用 @Order(0) 的日志切面 → 默认优先级高于 TransactionInterceptor，导致事务上下文未建立
• ❌ @AfterThrowing 捕获 Exception 但未 re-throw → 异常终止于切面，TransactionInterceptor 不触发 rollback
• ❌ 在 @Around 中使用 try-catch 吞掉所有异常且无 throw → 彻底破坏事务传播契约

七、演进层：Spring Boot 3.x + Jakarta EE 9+ 的新约束

自 Spring Framework 6.0 起，TransactionInterceptor 的 order 值被锁定为 Integer.MAX_VALUE（即 2147483647），且 @Transactional 的元注解 @Role(BeanDefinition.ROLE_INFRASTRUCTURE) 明确禁止用户覆盖其 Advice 实例。这意味着：

• 任何自定义切面若需“包裹”事务逻辑，必须显式声明 @Order(value = Integer.MAX_VALUE - 1)
• 基于 AspectJ LTW 的编译期织入不再影响 Spring AOP 代理链顺序（二者正交）
• Spring AOP 与 Spring Transaction 的耦合度进一步降低，但对 Order 控制精度要求更高

八、验证层：单元测试黄金脚本

@Test
@Sql("/test-data.sql")
void whenLogAspectAfterTransaction_thenTxActiveInsideAspect() {
  assertThatThrownBy(() -> service.doWithTxAndLog())
      .isInstanceOf(RuntimeException.class);
  // 验证：事务回滚后数据库无残留
  assertThat(jdbcTemplate.queryForObject("SELECT COUNT(*) FROM orders", Integer.class)).isEqualTo(0);
  // 验证：日志切面确实收到事务上下文
  assertThat(logCapture.getEvents()).anyMatch(e -> e.getMessage().contains("tx-active:true"));
}

```