请教Spring @Retryable与WebFlux内置重试（如retryWhen）的差异

1. 编程模型适配性 #

• @Retryable是Spring Retry提供的注解，基于同步编程模型设计，靠AOP代理实现方法级重试。如果在返回Mono/Flux的WebFlux异步方法上使用，重试逻辑只会在订阅前的同步阶段触发，无法感知Reactor流的异步状态变化。
• retryWhen是Reactor框架原生操作符，完全适配响应式编程模型，直接作用于Mono/Flux流本身，能感知流的订阅、错误、背压等生命周期事件，重试逻辑是异步的，和整个响应式流水线深度融合。

2. 重试控制粒度 #

• @Retryable是方法级重试，只要方法抛出指定异常就触发重试，没法针对WebFlux客户端调用的特定错误（比如HTTP 5xx、连接超时）做精细化控制，除非在方法内手动捕获并抛出对应异常。
• retryWhen支持流级甚至请求级的精细化控制：比如用Retry.backoff()配置指数退避，用Retry.onlyIf()指定只重试特定错误（比如判断WebClient响应状态码），还能通过RetryContext记录重试次数、请求信息等上下文数据。

示例代码（retryWhen精细化控制）：

webClient.get()
         .uri("/api/data")
         .retrieve()
         .bodyToMono(Data.class)
         .retryWhen(Retry.backoff(3, Duration.ofSeconds(1))
                         .filter(ex -> ex instanceof WebClientResponseException && 
                                      ((WebClientResponseException) ex).getStatusCode().is5xxServerError()));

3. 错误处理能力 #

• @Retryable只能捕获方法抛出的同步异常，对于WebFlux客户端调用中异步产生的错误（比如流中发出的Error信号），处理能力有限，因为AOP代理无法拦截Reactor流内部的错误。
• retryWhen可以直接处理Reactor流中的异步错误信号，还能和onErrorResume、onErrorReturn等响应式操作符配合，实现重试失败后降级返回默认值等灵活的错误恢复策略。

4. 依赖与侵入性 #

• @Retryable需要引入spring-retry依赖，还要启用@EnableRetry注解，属于额外框架依赖，对代码有一定侵入性（需在方法上添加注解）。
• retryWhen是Reactor核心库自带功能，无需额外依赖，直接通过流操作符调用，代码侵入性低，更贴合响应式编程风格。

5. 背压支持 #

• @Retryable完全不支持背压，因为是同步重试逻辑，无法感知Reactor流的背压信号，重试时可能引发资源过载。
• retryWhen是Reactor原生操作符，完全支持背压机制，重试逻辑会和整个流的背压策略协同工作，避免资源耗尽。

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