thenCompose 的核心作用是扁平化嵌套的 CompletableFuture，将返回的 CompletableFuture 压平为同一层级，保持链式调用类型一致；它适用于串行依赖任务，要求下游必须使用上游结果作为参数触发，否则应选 thenCombine 或 allOf。
thenCompose 的核心作用是“扁平化嵌套的 CompletableFuture”
如果你写了 thenApply 返回一个 CompletableFuture，结果得到的是 CompletableFuture，这没法直接链式调用后续操作。而 thenCompose 就是专治这个——它把返回的 CompletableFuture “压平”进当前链，保持类型为 CompletableFuture。
常见错误现象：thenApply 里 new 了个 CompletableFuture.supplyAsync(...)，之后调用 thenAccept 报错：找不到匹配的方法（因为参数类型是 CompletableFuture 而非 T）。
- 必须用
thenCompose接收返回CompletableFuture的函数 - 传入函数签名必须是
Function，不能是> Function - 如果上游异常，
thenCompose不会执行；想兜底要用handle或exceptionally
串行依赖任务的典型写法：每个任务依赖前一个的结果
比如：查用户 → 根据 userId 查订单 → 根据 orderId 查物流信息。三者必须顺序执行，且后一步需要前一步的返回值。
CompletableFuture<user> userF = CompletableFuture.supplyAsync(() -> dao.findUser(123));
CompletableFuture<order> orderF = userF.thenCompose(user ->
CompletableFuture.supplyAsync(() -> dao.findOrder(user.getId()))
);
CompletableFuture<tracking> trackingF = orderF.thenCompose(order ->
CompletableFuture.supplyAsync(() -> dao.findTracking(order.getId()))
);</tracking></order></user>
注意：每个 supplyAsync 都在独立线程执行，但执行时机受前序完成约束；整个链仍保持异步非阻塞。
- 不要在
thenCompose函数体内直接调用同步方法并包装成completedFuture，除非你明确要避免线程切换 - 若某步可能为空（如用户不存在），需提前
filter或用thenCompose(u -> u == null ? CompletableFuture.failedFuture(...) : ...) - 所有
supplyAsync默认使用ForkJoinPool.commonPool()，高并发下建议显式传入自定义线程池
和 thenCombine / thenAcceptBoth 混用时容易混淆的边界
thenCompose 是单输入、单输出、串行依赖；而 thenCombine 是双输入、单输出、并行等待两个 CompletionStage 完成。有人试图用 thenCompose 合并两个独立任务，结果逻辑卡死或类型不匹配。
错误示例：cf1.thenCompose(x -> cf2) —— 这里 cf2 不依赖 x，属于滥用；应改用 cf1.thenCombine(cf2, (x, y) -> ...)。
- 只有当下游任务**必须用上游结果作为参数构造或触发**时，才用
thenCompose - 若两个任务无数据依赖，只是想等都做完再处理，选
thenCombine或allOf+join -
thenCompose不会自动传播异常到下游，下游get()时才会抛出原始异常（这点和thenApply一致）
异常传递与恢复的实操要点
thenCompose 自身不捕获异常，上游失败会导致整个链中断，后续 thenCompose 不执行。恢复逻辑必须显式插入。
userF
.thenCompose(user -> CompletableFuture.supplyAsync(() -> dao.findOrder(user.getId())))
.exceptionally(err -> {
log.error("order query failed", err);
return fallbackOrder();
})
.thenCompose(order -> CompletableFuture.supplyAsync(() -> dao.findTracking(order.getId())));
注意：第一个 exceptionally 返回的是 Order，所以能继续 thenCompose；但如果它返回的是 CompletableFuture，类型就不匹配了。
-
exceptionally返回值类型必须和上游成功时的泛型一致（这里是Order） - 若想在异常后仍走异步路径，得用
handle((result, ex) -> ex != null ? CompletableFuture.failedFuture(ex) : CompletableFuture.completedFuture(...)) - 多个
thenCompose链中任意一环未处理异常，最终join()会抛出最上游的原始异常，堆栈可能丢失中间环节信息
实际写长链时，最容易被忽略的是线程上下文丢失（比如 ThreadLocal 中的 traceId）和异常类型的隐式转换（如将 SQLException 包装成 CompletionException）。这两点不体现在语法上，但线上排查时往往卡很久。
