exceptionally() 提供异步链的兜底降级路径而非修复异常，仅在上游未处理异常时触发一次，需返回同泛型类型值，注意线程上下文与异常处理边界。
直接用 exceptionally() 捕获并返回降级值，就能让异步链不中断。它不是用来“修复异常”，而是提供一条安全的兜底路径。
exceptionally 的触发时机很明确
它只在上游某个阶段抛出未处理的异常时才执行，且仅执行一次：
- 上游正常完成 →
exceptionally被跳过，后续thenApply等照常执行 - 上游任意位置（
supplyAsync、thenApply、thenCompose等）抛出运行时异常 → 异常被包装为CompletionException，自动触发exceptionally - 如果已在前面用了
exceptionally，后续再抛异常，不会再次触发它（除非后面又接了新的exceptionally）
写法上注意参数和返回类型
exceptionally 接收一个 Function<Throwable, T>，必须返回与原始 CompletableFuture 相同泛型类型的值：
- 比如
CompletableFuture<String>的exceptionally必须返回String，不能返回void或Integer - 参数
Throwable ex是包装后的CompletionException，但它的getCause()才是原始业务异常（如RuntimeException、IOException），建议先打印或判断ex.getCause() - 常见写法：
.exceptionally(ex -> { log.warn("调用失败", ex); return "默认文案"; })
它不改变线程模型，但影响执行上下文
exceptionally 的执行线程取决于前一个阶段：
立即学习“Java免费学习笔记（深入）”；
- 若前一阶段是
thenApply（同步执行），则exceptionally在同一工作线程中同步执行 - 若前一阶段是
thenApplyAsync（异步），则exceptionally会从线程池取新线程执行 - 这意味着：不要在
exceptionally里做耗时阻塞操作（如远程调用），否则可能拖慢整个线程池；适合做日志、缓存读取、简单计算等轻量逻辑
别把它当成万能 try-catch
exceptionally 只捕获链中“已发生的异常”，无法预防或拦截后续阶段新抛的异常：
- 它对自身回调里再抛异常无保护 —— 如果你在
exceptionally里写了throw new RuntimeException()，这个异常会继续传播，可能最终崩掉join() - 它不覆盖
handle或whenComplete的功能：如果既要处理成功结果又要统一打日志，用handle更合适；如果只记录不改结果，用whenComplete - 真正健壮的做法是：关键环节单独加
exceptionally，而不是只在链尾加一个指望管全程
