thenCompose 的核心作用是扁平化嵌套的 CompletableFuture，它接收返回 CompletableFuture 的函数，自动拆包合并，保持链式结构扁平、可读、可取消。
thenCompose 的核心作用是扁平化嵌套的 CompletableFuture
如果你写过 thenApply 返回另一个 CompletableFuture，就会发现结果类型变成 CompletableFuture<completablefuture>></completablefuture> —— 这不是你想要的。而 thenCompose 会自动“拆一层”，把返回的 CompletableFuture 合并进来，保持链式结构扁平、可读、可取消。
它和 thenApply 的关键区别在于：前者接收一个函数，该函数返回 CompletableFuture<u></u>；后者返回的是普通 U。一旦中间步骤本身是异步的（比如调用远程 API、查 DB），就必须用 thenCompose，否则后续任务拿不到真正的异步结果。
串行依赖任务的实际写法：每个步骤都返回 CompletableFuture
假设你要依次完成：用户登录 → 获取用户权限 → 根据权限加载配置 → 渲染页面。每一步都依赖上一步结果，且每步都是异步 IO 操作：
CompletableFuture<User> login = loginAsync("u1", "p1");
CompletableFuture<Permission> perm = login.thenCompose(user -> fetchPermissionAsync(user.getId()));
CompletableFuture<Config> config = perm.thenCompose(p -> loadConfigAsync(p.getScope()));
CompletableFuture<Page> page = config.thenCompose(c -> renderPageAsync(c.getTheme()));
// 最终获取结果（生产环境建议配合 timeout + exception handling）
page.join();
注意点：
-
thenCompose内部函数必须返回CompletableFuture，不能直接 return 一个对象，否则编译不过 - 如果某步可能失败（如网络超时），
thenCompose不会自动传播异常；需搭配exceptionally或handle显式处理 - 所有步骤默认在同一个线程池（ForkJoinPool.commonPool()）执行，若某步是 CPU 密集型，应显式指定线程池：
thenCompose(fn, executor)
常见踩坑：混用 thenApply 和 thenCompose 导致类型错乱或阻塞
错误写法示例：
// ❌ 错误：fetchPermissionAsync 返回 CompletableFuture，但用了 thenApply login.thenApply(user -> fetchPermissionAsync(user.getId())); // 类型是 CompletableFuture<CompletableFuture<Permission>>
这会导致后续 thenCompose 接收一个嵌套对象，调用 .join() 时实际只等外层完成，内层可能还在跑 —— 表现为“结果为空”“数据没加载”“页面卡住”。
另一个典型问题：在 thenCompose 函数里同步调用阻塞方法（如 JDBC DriverManager.getConnection()），会拖垮整个 commonPool，影响其他异步任务。此时必须：
- 把阻塞操作包装进
supplyAsync(..., blockingExecutor) - 或改用
thenComposeAsync(..., executor)指定专用线程池
复杂依赖场景下，避免回调地狱但别丢掉错误上下文
当链路变长（比如 5+ 步）、部分步骤需要条件跳过、或某些步骤要并行发起再合并，thenCompose 单独用会显得僵硬。这时可以：
- 用
thenCompose+CompletableFuture.allOf组合并行子流程（注意allOf返回CompletableFuture<Void>，需手动 collect 结果） - 对中间结果做判空或状态检查时，不要在
thenCompose里 throw 新异常，而是用failedFuture包装原始异常，保留堆栈 - 调试时加日志建议用
whenComplete((r, t) -> log.debug("stepX done", t))，比thenAccept更容易捕获异常路径
真正难的不是写对语法，而是理清哪一步该异步、哪一步该隔离线程、哪一步的异常必须中断整条链 —— 这些决策藏在业务语义里，而不是 API 文档里。
