exceptionallyCompose 不是 CompletableFuture 的标准方法；正确实现异步回退需组合 exceptionally 与 thenCompose，前者捕获异常并返回 CompletableFuture，后者扁平化嵌套结构，确保最终返回 CompletableFuture。
exceptionallyCompose 不是 CompletableFuture 的标准方法 —— 它根本不存在于 Java 8/11/17/21 的任何官方 JDK 版本中。
你可能混淆了以下三个真实存在的 API：
-
exceptionally：接收Function<throwable t></throwable>，返回同类型默认值，不支持异步任务 -
handle：接收BiFunction<t throwable r></t>，统一处理成功/异常，可返回新类型，但仍是同步计算 -
whenComplete/whenCompleteAsync：仅做副作用（如日志、清理），不能改变结果值
如果你的目标是「在上游失败后，触发一个新的异步任务作为回退（fallback），且该任务本身也返回 CompletableFuture」，那么正确解法是：
用 exceptionally + thenCompose 组合实现异步回退
-
exceptionally必须返回一个 已完成的CompletableFuture（比如用completedFuture包装兜底值） - 但若你想执行真正的异步回退逻辑（例如查缓存、调降级服务），就得在
exceptionally里手动启动新异步任务，并用thenCompose扁平化它
CompletableFuture<String> primary = supplyAsync(() -> {
if (Math.random() > 0.5) throw new RuntimeException("primary failed");
return "from-db";
});
<p>CompletableFuture<String> fallback = primary
.exceptionally(ex -> {
// 注意：这里不能直接 return supplyAsync(...) —— 类型不匹配！
// 因为 exceptionally 要求返回 String，而 supplyAsync 返回 CompletableFuture<String>
return null; // 编译报错
});
✅ 正确写法（手动补全类型 + 扁平化）：
CompletableFuture<String> fallback = primary
.exceptionally(ex -> CompletableFuture.completedFuture("default"))
.thenCompose(cf -> cf); // cf 是 CompletableFuture<String>，thenCompose 才能解开
<p>// 更实用的模式：失败后真正发起异步降级请求
CompletableFuture<String> resilient = primary
.exceptionally(ex -> {
log.warn("Primary failed, triggering async fallback", ex);
return supplyAsync(() -> callFallbackService(), fallbackExecutor);
})
.thenCompose(Function.identity()); // 把 CompletableFuture<CompletableFuture<String>> 扁平成 CompletableFuture<String>
⚠️ 容易踩的坑：
-
exceptionally的 lambda 返回类型必须和原始CompletableFuture泛型一致（如CompletableFuture<string></string>就只能返回String） - 想在异常分支里跑新异步任务？必须用
supplyAsync或completedFuture构造一个CompletableFuture，再靠thenCompose接住 - 如果忘了
thenCompose，会得到CompletableFuture<completablefuture>></completablefuture>，后续join()拿到的是未完成的内层 CF，极易阻塞或 NPE - 自定义线程池（如
fallbackExecutor）没设UncaughtExceptionHandler，内层异步任务抛异常会被静默吞掉
为什么不用 handle 替代？
handle 确实能同时看到结果和异常，但它仍是同步执行的函数。如果你在 handle 里写 supplyAsync，一样要面对返回类型不匹配问题，最终仍需 thenCompose 扁平化：
.handle((result, ex) -> {
if (ex != null) {
return supplyAsync(() -> "async-fallback", fallbackExecutor); // ❌ 类型错
}
return result; // ✅ String
})
.thenCompose(x -> x instanceof CompletableFuture ? (CompletableFuture<String>)x : completedFuture(x));
这种写法不仅难读，还引入运行时类型判断，不推荐。
真正需要异步回退时，更清晰的写法是提取为工具方法
public static <T> CompletableFuture<T> withAsyncFallback(
CompletableFuture<T> origin,
Function<Throwable, CompletableFuture<T>> fallbackFn,
Executor fallbackExecutor) {
return origin
.exceptionally(ex -> fallbackFn.apply(ex).toCompletableFuture()) // 先包一层
.thenCompose(Function.identity());
}
但注意：这个方法的前提是 fallbackFn 内部已用 supplyAsync 或类似方式构造了新的 CompletableFuture。
复杂点在于——异常分支的异步性不是自动继承的，必须显式调度、显式扁平、显式类型对齐。没有“开箱即用”的 exceptionallyCompose，是因为 JDK 设计上把「异常恢复」和「异步编排」拆成了两个正交职责。
