CompletableFuture异常降级核心是用对方法、选好时机、返回合理值：exceptionally用于最简兜底，仅异常时触发并返回同类型默认值；handle统一收口成功与失败双路径；allOf需手动检查各子任务状态；务必配合超时与线程池隔离保障降级生效。
CompletableFuture 处理异步任务异常降级，核心是用对方法、选好时机、返回合理值——不是简单“捕获就完事”，而是让失败有兜底、链路不中断、业务可感知。
用 exceptionally 做最简降级
这是最常用也最直接的异常降级方式。它只在上游抛异常时触发，接收 Throwable，必须返回与原始结果类型一致的值，从而把异常“转成”一个可用结果。
- 适合场景：网络请求失败时返回缓存、空数据或默认文案
- 注意点：它只响应前一级异常；后续再出错需再次加 exceptionally
- 示例：.exceptionally(ex -> { log.warn("订单查询失败", ex); return Order.empty(); })
用 handle 统一收口，兼顾成功与失败
handle 接收两个参数：结果（可能为 null）和异常（可能为 null），二者必居其一。你得自己判空，但换来的是完全可控的双路径处理逻辑。
- 适合场景：HTTP 调用后统一解析状态码 + 异常；需要根据错误类型做不同降级
- 关键细节：throwable != null 时 result 一定为 null；throwable == null 时 result 可能为 null，不能直接调用 toString()
- 示例：.handle((order, ex) -> ex != null ? fallbackOrder() : enrich(order))
组合 allOf/anyOf 时的异常策略
allOf 并不会因为某个子任务失败就停止执行——其他任务照常跑，但整体 future 状态变为异常。这意味着你不能靠“没报错”判断全部成功。
立即学习“Java免费学习笔记（深入）”；
- 正确做法：先 allOf 汇总，再 individually 获取每个子 future 的结果（用 join 或 get），手动检查是否完成或异常
- 降级建议：对单个失败服务单独 fallback（如库存查不到就标“暂无库存”），不影响其他字段展示
- 避免陷阱：不要对 allOf 结果直接 .join() 后再 try-catch，那会掩盖哪个子任务挂了
配合线程池与超时，让降级更可靠
异常降级的前提是任务真能“失败”。如果下游卡死不响应，CompletableFuture 会一直等下去，降级逻辑根本没机会执行。
- 务必设置超时：用 orTimeout(3, TimeUnit.SECONDS) 或 completeOnTimeout(...) 主动中断等待
- 线程池隔离：别用 commonPool，自定义业务线程池，防止一个慢任务拖垮全局
- 异常重试慎用：CompletableFuture 本身不支持自动重试，需手动封装（如 while 循环 + delay），但要防雪崩
