Resilience4j装饰器不显式使用PECS，因其专注执行控制而非集合操作；PECS在下游消费其返回类型或自定义扩展（如fallback、事件总线、批量工具）时才生效，需按“读用? extends、写用? super”原则设计。
PECS 原则在 Resilience4j 中不直接暴露于 API 表面，但它深刻影响着装饰器方法（如 decorateSupplier、decorateCallable）的泛型设计逻辑——尤其体现在如何安全地封装和传递业务函数的输入输出类型。
为什么 Resilience4j 的装饰器没显式写 ? extends / ? super
Resilience4j 的核心装饰方法签名通常为：
public static <T> Supplier<T> decorateSupplier(CircuitBreaker circuitBreaker, Supplier<T> supplier)
这里用的是具体泛型参数 <T>，而非通配符。原因很实际：装饰器本身不“读取”或“写入”集合，而是包装并代理执行一个函数。它的职责是控制执行流程（熔断、重试等），而非对函数的输入/输出集合做泛型操作。所以不需要 PECS —— 它面向的是单值计算契约，不是容器数据流。
立即学习“Java免费学习笔记（深入）”；
但 PECS 在你调用装饰后的真实场景中起作用
当你把装饰后的 Supplier<T> 结果存入或传给其他组件时，PECS 才真正生效。例如：
- 你用
decorateSupplier(cb, () -> new PayOrder())得到Supplier<PayOrder>； - 若下游方法定义为
void process(Iterable<? extends Order> orders)，你可以安全地把Arrays.asList(decorated.get())传进去——因为PayOrder是Order子类，符合? extends Order； - 若你要把结果批量写入日志收集器
void logAll(Collection<? super Event> events)，而PayOrder实现了Event接口，那logAll(list)也能通过编译。
换句话说：Resilience4j 不强制你用 PECS，但它生成的类型必须能被下游按 PECS 原则安全消费。
真正需要 PECS 的地方：自定义容错回调与聚合工具
当你扩展 Resilience4j（比如写通用 fallback 工具、批量熔断适配器）时，PECS 就成了关键设计依据：
-
作为生产者（读取 fallback 结果）：若 fallback 返回多种子类型（
DefaultOrder、MockOrder），而主逻辑只关心Order接口，则应声明Supplier<? extends Order>，保证可安全调用order.getId()； -
作为消费者（写入降级事件）：若你设计一个统一错误事件总线
void emit(ExecutionFailedEvent event)，而希望它能接收TimeoutEvent、CircuitBreakerOpenEvent等所有子类，就该用Collection<? super ExecutionFailedEvent>作为缓冲区参数； -
组合场景：批量重试工具
<R> void retryAll(List<? extends Callable<R>> tasks, Collection<? super R> results)—— 任务列表只读（? extends），结果容器只写（? super）。
小结：PECS 是你用 Resilience4j 时的隐性契约
Resilience4j 自身泛型简洁直接，因为它专注“执行控制”。但你在构建上下游数据流时，必须主动区分：
- 谁从结果里取值？→ 用
? extends T，放宽读取来源； - 谁往结果里塞值？→ 用
? super T，放宽写入目标； - 别让一个参数既 get 又 add —— 这不是 Resilience4j 的问题，是你接口职责模糊的信号。
