本文详解为何直接使用 Retry.decorateCheckedSupplier() 无法触发重试，揭示 Spring Boot 环境中函数式配置与声明式注解的本质区别，并提供可落地的 Bean 注册方案与最佳配置范式。
本文详解为何直接使用 `retry.decoratecheckedsupplier()` 无法触发重试，揭示 spring boot 环境中函数式配置与声明式注解的本质区别，并提供可落地的 bean 注册方案与最佳配置范式。
在 Spring Boot 项目中集成 Resilience4j Retry 时，许多开发者会陷入一个典型误区：误以为手动调用 Retry.decorateCheckedSupplier() 即可自动生效。正如问题所示，即使已构建 RetryConfig、RetryRegistry 和 Retry 实例，并对 myService::bar 进行装饰，最终调用 myService.bar() 仍仅执行一次并抛出原始异常——重试逻辑完全未被触发。
根本原因在于：Retry.decorateCheckedSupplier() 仅返回一个被增强的 CheckedSupplier<T> 函数对象，它本身不会修改原始方法行为；你仍需显式调用该装饰后的 Supplier，而非原始方法。
来看原代码的问题所在：
Retry retry = registry.retry("name1");
// ❌ 错误：仅装饰，但未执行装饰后的逻辑
Retry.decorateCheckedSupplier(retry, myService::bar);
// ❌ 错误：仍调用原始方法，绕过所有重试逻辑
myService.bar(); // → 直接抛异常，无重试✅ 正确做法是：获取装饰后的 Supplier，并调用其 get() 方法：
Retry retry = registry.retry("name1");
// ✅ 正确：获取装饰后的 CheckedSupplier
CheckedSupplier<String> decorated = Retry.decorateCheckedSupplier(retry, myService::bar);
// ✅ 正确：执行装饰逻辑（此时重试生效）
try {
String result = decorated.get(); // 将按 maxAttempts=6、waitDuration=100ms 重试
} catch (Exception e) {
log.error("All retries failed", e);
}然而，在 Spring Boot 生态中，更推荐、更符合框架约定的方式是 声明式注解驱动 + 自动配置，而非纯函数式手动管理：
✅ 推荐方案：@Retry 注解 + YAML 配置（开箱即用）
-
确保依赖完整（关键！缺 spring-boot-starter-aop 注解将失效）：
<dependency> <groupId>io.github.resilience4j</groupId> <artifactId>resilience4j-spring-boot2</artifactId> <version>1.7.1</version> </dependency> <dependency> <!-- 必须！启用 AOP 代理 --> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</artifactId> </dependency>
-
YAML 配置命名实例（如 retry-bar）：
resilience4j: retry: instances: retry-bar: maxAttempts: 6 waitDuration: 100ms enableExponentialBackoff: false # 可选：精准控制重试异常类型 retryExceptions: - java.lang.RuntimeException ignoreExceptions: - com.example.MyBusinessException -
在 Service 方法上添加 @Retry 注解：
@Service @Slf4j public class MyService { @Retry(name = "retry-bar") // ← 关键：绑定 YAML 中定义的实例名 public String bar() throws InterruptedException { log.error("Bar is called"); Thread.sleep(3000); throw new RuntimeException("bar exception"); // 触发重试 } }
✅ 此时 Spring AOP 会在运行时代理该方法，自动注入重试逻辑——无需手动装饰、无需调用额外对象，语义清晰且线程安全。
⚠️ 注意事项与避坑指南（Resilience4j 1.7.x 版本）
- waitDuration 的生产陷阱：YAML 中设置 100ms 是合法的，但 1.7.0+ 版本对极短间隔（如 1ms）有底层最小值限制（约 50ms），且生产环境应避免 <100ms 配置，以防重试风暴；
- 异常分类必须精准：retryExceptions 应明确列出需重试的非业务异常（如 IOException, TimeoutException），切忌写 java.lang.Exception —— 否则业务校验失败也会被重试，引发数据重复或状态不一致；
-
函数式配置若坚持使用，须注册为 Bean：若需动态构建 RetryRegistry，必须通过 @Bean 声明并确保被 Spring 管理，否则 AOP 无法识别：
@Configuration public class Resilience4jConfig { @Bean public RetryRegistry retryRegistry() { RetryConfig config = RetryConfig.custom() .maxAttempts(6) .waitDuration(Duration.ofMillis(100)) .build(); return RetryRegistry.of(config); } }
总结
Resilience4j Retry 在 Spring Boot 中的“生效”，本质依赖于 AOP 代理机制 或 显式调用装饰函数。裸调 decorateSupplier() 而不执行它，就像造好汽车却不点火——结构完整，但毫无动力。优先采用 @Retry + YAML 配置模式，既符合 Spring Boot “约定优于配置”哲学，又能规避手动管理生命周期的风险；仅在需要运行时动态策略或非 Spring 环境时，才深入函数式 API 并严格遵循 decorate → execute 流程。
