thenCompose 的核心作用是将前一个 CompletableFuture 的结果作为参数传递给返回新 CompletableFuture 的函数，避免嵌套；必须用于链式异步依赖（如查用户→查订单→查物流），且应配合 thenComposeAsync 与专用 IO 线程池使用。
thenCompose 的核心作用：把一个 CompletableFuture 的输出“喂给”另一个异步任务
它不是简单地串接两个独立任务，而是让前一个任务的返回值（类型为 T）直接作为后一个函数的入参，该函数必须返回一个新的 CompletableFuture<u></u>。这和 thenApply 的关键区别在于：后者返回的是 U（普通值），而 thenCompose 返回的是 CompletableFuture<u></u>，避免了嵌套的 CompletableFuture<completablefuture>></completablefuture>。
什么时候必须用 thenCompose，而不是 thenApply
典型场景是「查用户 → 根据用户ID查其订单 → 根据订单ID查物流信息」这类链式依赖调用。每个环节都是远程 IO 操作，且后一步必须等前一步结果才能发起请求。
-
thenApply适合做同步转换，比如把User对象转成String或加个字段，不能发起新异步请求 -
thenCompose才能真正“续上”下一个异步阶段——你传进去的 lambda 必须返回CompletableFuture，否则编译不通过 - 如果误用
thenApply去调用返回CompletableFuture的方法（如findOrdersByUserId()），你会得到CompletableFuture<completablefuture>>></completablefuture>，后续join()会抛ClassCastException或阻塞在错误层级
真实代码中容易踩的线程模型坑
thenCompose 默认不带 Async 后缀，意味着它会在前一个阶段完成的**同一线程**中执行 lambda —— 如果前一个阶段是在 IO 线程池里完成的，那这个 lambda 也会在那个线程里跑；如果前一个阶段已经完成，它甚至可能在当前主线程里执行。这对 IO 密集型任务不安全，容易导致线程饥饿。
- 务必搭配
thenComposeAsync使用，并显式传入专用于 IO 的线程池，例如Executors.newCachedThreadPool()或自定义的ThreadPoolExecutor - 千万别依赖默认的
ForkJoinPool.commonPool()，它的线程数少、是守护线程、只适合 CPU 密集型计算 - 若上游是
supplyAsync(..., ioPool)，下游又用无 Async 版本，就等于把 IO 操作挤进了一个非 IO 友好的线程池
异常传播与 fallback 的实际处理方式
thenCompose 本身不捕获异常，上游抛出的异常会直接中断整个链路。你需要在合适位置加 exceptionally 或 handle，但要注意它们的作用范围：
-
exceptionally只接管上游异常，且返回值类型必须和原始CompletableFuture一致（比如上游是CompletableFuture<user></user>，fallback 也得返回User） -
handle更灵活，无论成功或失败都进，可返回任意类型（比如成功返回OrderDetail，失败返回null或ErrorResponse） - 常见错误：在
thenCompose后直接跟exceptionally，却忘了上游某个supplyAsync也可能失败——异常可能根本没传到thenCompose这一层，就已在前面中断了
最稳妥的做法是在整个链最外层套一个 handle，统一收口结果与异常，而不是靠多个 exceptionally 分散兜底。
