降级必须由各子Future自行封装，anyOf不感知异常也不触发fallback；每个子Future需独立配置exceptionally、超时和熔断；线程池须隔离I/O任务并设CallerRunsPolicy；结果应统一为包装类Result<T>避免ClassCastException。
在基于 CompletableFuture.anyOf 的多流合并场景中，线程池本身不直接参与降级逻辑，但它的配置和使用方式深刻影响降级的可靠性与可观测性。关键在于：降级不是等任务失败后补救，而是在任务启动时就为每个分支独立准备兜底路径；anyOf 只负责“取最快完成者”，它不感知异常、不触发 fallback，所有降级必须由各子 Future 自行封装。
每个子 Future 必须自带降级，不能依赖 anyOf 统一处理
anyOf 返回的是 CompletableFuture<Object>，它只监听完成状态（正常或异常），但不会拦截异常、也不会调用 exceptionally 或 handle。如果某个子 Future 异常完成，它仍会被 anyOf “选中”——此时你拿到的是一个 CompletionException 实例，而非业务结果。
- 错误做法：把降级逻辑写在
anyOf(...).exceptionally(...)里 → 这只能捕获anyOf自身的构造异常（极少见），无法覆盖子任务失败 - 正确做法：每个
supplyAsync都配好exceptionally或handle，确保无论成功或失败，都返回一个可用的业务类型值（如String、User） - 示例：
CompletableFuture<String> f1 = CompletableFuture.supplyAsync(() -> callA()).exceptionally(t -> "fallback-A");
CompletableFuture<String> f2 = CompletableFuture.supplyAsync(() -> callB()).exceptionally(t -> "fallback-B");
CompletableFuture<Object> fastest = CompletableFuture.anyOf(f1, f2);
线程池选择影响降级响应速度和资源隔离
默认使用 ForkJoinPool.commonPool() 存在风险：I/O 密集型任务（如 HTTP 调用）会长时间占用公共线程，导致其他异步任务饥饿，间接使降级延迟甚至失效。
- 必须为 I/O 类子任务指定自定义线程池，例如
Executors.newCachedThreadPool()或专用的ThreadPoolExecutor - 不同服务来源可分配不同线程池（如支付流用 pool-pay，查询流用 pool-read），避免单点故障拖垮全部分支
- 线程池拒绝策略建议用
CallerRunsPolicy，让调用方线程执行任务，既防止丢任务，又自然限流
超时 + 熔断需在子任务粒度实现，anyOf 不提供这些能力
anyOf 没有超时、重试、熔断机制。若希望“任一响应在 800ms 内返回，否则走兜底”，必须对每个子 Future 单独加 orTimeout 并配合降级：
立即学习“Java免费学习笔记（深入）”；
supplyAsync(..., ioPool).orTimeout(800, MILLISECONDS).exceptionally(...)- 熔断开关（如
AtomicBoolean）也必须按子服务维度维护，不能共用一个全局开关 - 注意：
orTimeout不终止底层线程，只是标记该 Future 失败；真正耗时操作仍可能继续运行，需靠上层服务自身支持中断（如HttpClient设置 connect/read timeout）
结果类型统一是安全合并的前提
anyOf 返回 Object，因为各子 Future 类型可能不同（String、Integer、Exception）。若未提前降级，运行时强转极易抛 ClassCastException。
- 推荐方案：所有子 Future 统一返回包装类（如
Result<T>），包含 status、data、error 字段，降级时也返回同结构实例 - 避免用
thenApply(Object::toString)等粗暴转换，会掩盖真实失败原因 - 调试时可通过
fastest.handle((r, t) -> { log.info("anyOf result: {}, error: {}", r, t); return r; })观察原始结果形态
