Spring Boot中@Retryable与@Trace注解顺序是否影响功能生效？

Spring Boot场景下，仅针对基于AOP动态代理实现运行时增强的注解，声明顺序会直接影响功能生效逻辑；不依赖AOP增强的注解（如参数校验、路由映射类注解），声明顺序不会产生任何功能影响。

@Trace与@Retryable顺序差异导致链路日志丢失的现象，本质是Spring AOP拦截链的执行顺序规则导致的。

核心原理 #

Spring为方法生成AOP代理时，会将每个注解对应的增强逻辑封装为独立的方法拦截器，按照注解在方法上的声明顺序组装为洋葱圈结构的拦截链：

• 写在方法上方越靠前的注解，对应的拦截器越处在拦截链外层，执行时机越早，退出时机越晚
• 写在方法上方越靠后的注解，对应的拦截器越处在拦截链内层，执行时机越晚，退出时机越早

两种写法的执行逻辑差异 #

写法1：@Trace在前，@Retryable在后 #

@Trace
@Retryable(
        value = { ManagerException.class },
        backoff = @Backoff(delay = 100))
public Object dummy(@NotNull @Valid DummyObject dummyObject){
    // 业务逻辑
}

这种写法下@Trace对应的链路增强在拦截链外层，@Retryable对应的重试增强在内层：

• 调用方法时首先进入@Trace切面，初始化链路上下文、创建Trace span
• 之后进入@Retryable切面执行重试逻辑，重试过程中抛出的异常会被@Retryable内部捕获用于判断是否需要重试，不会透传到外层@Trace切面
• 所有重试触发的方法重入都发生在@Retryable切面内部，不会再次经过外层的@Trace拦截点，最终只会记录第一次调用的链路信息，重试过程的日志完全丢失，甚至会因为异常被内层吞掉导致Trace上下文断裂，出现无法获取链路日志的现象。

写法2：@Retryable在前，@Trace在后 #

@Retryable(
        value = { ManagerException.class },
        backoff = @Backoff(delay = 50))
@Trace
public Object dummy(@NotNull @Valid DummyObject dummyObject){
    // 业务逻辑
}

这种写法下@Retryable对应的重试增强在拦截链外层，@Trace对应的链路增强在内层：

• 调用方法时首先进入@Retryable切面，启动重试判断逻辑
• 包括首次调用在内的每一次重试执行，都会穿过外层的@Retryable拦截器，进入内层的@Trace切面完成链路上下文初始化、span记录、日志上报
• 所有调用过程都能被@Trace逻辑完整捕获，因此可以正常获取全部链路日志。

最佳实践 #

• 多层AOP注解叠加时，遵循「外层重试/限流/熔断，内层事务/日志/参数校验」的顺序原则，避免出现异常被吞、事务不回滚、日志丢失的问题
• 如果不希望依赖注解书写顺序控制执行优先级，可以为对应切面实现Ordered接口，或添加@Order注解明确指定优先级：数值越小，对应增强逻辑越处在拦截链外层。例如给Spring Retry的重试切面设置比Trace切面更小的order值，无论注解怎么写都能保证重试逻辑在外层。

内容的提问来源于stack exchange，提问作者Abhinav Singh