本文详解为何直接使用 Retry.decorateCheckedSupplier() 无法触发重试，揭示 Spring Boot 环境中函数式配置与声明式注解的关键区别，并提供可立即落地的修复方案（含配置、Bean 注册与调用链路说明）。
本文详解为何直接使用 `retry.decoratecheckedsupplier()` 无法触发重试，揭示 spring boot 环境中函数式配置与声明式注解的关键区别，并提供可立即落地的修复方案（含配置、bean 注册与调用链路说明）。
在 Spring Boot 项目中采用 Resilience4j 的函数式编程配置（如 Retry.decorateCheckedSupplier()）时，一个常见误区是：仅创建 Retry 实例并装饰 Supplier，却未将装饰后的函数实际执行。这正是你遇到“单次报错、无重试”的根本原因。
回顾你的代码片段：
RetryConfig config = RetryConfig.custom()
.maxAttempts(6)
.waitDuration(Duration.ofMillis(100))
.build();
RetryRegistry registry = RetryRegistry.of(config);
Retry retry = registry.retry("name1");
// ❌ 错误：仅装饰，未执行！返回的是一个被包装的 Supplier，但你并未调用它
Retry.decorateCheckedSupplier(retry, myService::bar);
// ❌ 错误：直接调用原始方法，完全绕过重试逻辑
myService.bar();
Retry.decorateCheckedSupplier(...) 返回的是一个增强后的 CheckedSupplier
✅ 正确做法是：显式调用装饰后的函数，并妥善处理受检异常：
CheckedSupplier<string> decorated = Retry.decorateCheckedSupplier(retry, myService::bar);
try {
String result = decorated.get(); // ✅ 此处才会真正触发最多 6 次重试
log.info("Success: {}", result);
} catch (Exception e) {
log.error("All retries failed", e);
}</string>
⚠️ 更重要的是：Spring Boot 的自动配置与函数式手动配置不可混用。
若你已在 application.yml 中启用 @EnableRetry 或依赖 resilience4j-spring-boot2，则推荐优先使用 声明式注解方式，它更简洁、可维护性高，且天然集成 Spring AOP 代理：
-
配置 application.yml（定义命名实例）：
resilience4j: retry: instances: retry-bar: max-attempts: 6 wait-duration: 100ms enable-exponential-backoff: false -
在服务方法上添加 @Retry 注解：
@Service @Slf4j public class MyService { @Retry(name = "retry-bar") // ✅ 绑定配置实例 public String bar() throws InterruptedException { log.error("Bar is called"); Thread.sleep(3000); throw new RuntimeException("bar exception"); // 模拟瞬时故障 } } -
确保主类或配置类启用 AOP（Spring Boot 2.4+ 默认启用，低版本需显式添加）：
@SpringBootApplication @EnableAspectJAutoProxy // 若使用较老 Spring Boot 版本，请保留此注解 public class Application { ... }
? 关键注意事项：
- @Retry 仅对Spring 管理的 Bean 方法调用生效（即通过接口/代理调用），直接 new MyService().bar() 不会触发；
- 重试默认只捕获非业务异常（如 RuntimeException, IOException），若需重试特定业务异常，请在配置中通过 retry-exceptions 显式声明；
- 函数式配置适合单元测试、命令行工具等非 Spring 容器场景；在 Spring Boot Web 应用中，注解 + YAML 配置是官方推荐、最稳定的方式；
- 若坚持函数式风格，务必注意：decorateXXX 系列方法返回的是新函数对象，必须主动调用其 get() / apply() 等方法，否则装饰形同虚设。
总结：Resilience4j 的强大在于其灵活的组合能力，但“配置即生效”不等于“声明即执行”。理解装饰器模式的本质——装饰是为了替换原始调用点——是避免此类问题的核心。选择声明式注解，让 Spring 自动完成代理织入；若选函数式，则务必掌控执行链路，确保调用的是被装饰后的函数。
