核心区别在于执行线程：thenComposeAsync 强制异步且默认用 ForkJoinPool.commonPool()，thenCompose 可能同步执行于上游线程，易阻塞IO线程。
thenComposeAsync 和 thenCompose 的核心区别在哪
关键看是否需要显式指定线程池。thenComposeAsync 强制异步执行，且默认用 ForkJoinPool.commonPool()；而 thenCompose 是同步调用——上游完成时，如果返回的是已完成的 CompletableFuture，它可能直接在当前线程触发下游，不切换线程。这在强顺序依赖场景下容易出问题：比如上游在 IO 线程完成，下游若也挤在同一个线程里跑 CPU 密集逻辑，会阻塞整个线程池。
所以「强顺序依赖」不是指逻辑先后，而是指下游必须等上游结果、且**不能共享上游执行线程**——尤其当上下游任务类型差异大（如上游是 HTTP 调用，下游是 JSON 解析+DB 写入）时，thenComposeAsync 才是安全选择。
- 默认不传
Executor时，thenComposeAsync用ForkJoinPool.commonPool()，注意该池大小 = CPU 核数，不适合 IO 任务 - 若下游含阻塞操作（如 JDBC 查询、文件读写），务必传自定义线程池，例如
Executors.newCachedThreadPool()或专用IO_EXECUTOR -
thenCompose返回的CompletableFuture若本身是未完成状态，行为仍异步；但若上游刚完成就立即返回已完成 future，它就退化为同步调用
链式调度中如何避免 CompletableFuture 的“扁平化陷阱”
常见错误是把 thenComposeAsync 当成 thenApplyAsync 用：传入一个返回普通值的 lambda，导致编译失败或隐式包装成 CompletableFuture.completedFuture(...)，丧失真正异步性。强顺序链要求每个环节都返回 CompletableFuture，否则依赖断裂。
典型反例：future.thenComposeAsync(x -> doSomething(x)) —— 如果 doSomething(x) 返回 String，那整个链会在当前线程同步执行，且无法被下游等待。
- 必须确保 lambda 返回类型是
CompletableFuture，例如x -> CompletableFuture.supplyAsync(() -> heavyCalc(x), cpuPool) - 嵌套调用时别漏掉
thenComposeAsync：比如 A → B → C，B 的结果要喂给 C，就得用A.thenComposeAsync(a -> B(a)).thenComposeAsync(b -> C(b))，而不是thenApplyAsync+thenComposeAsync - 如果中间某步可能为空（如 Optional），别用
thenComposeAsync直接解包，先用thenApplyAsync转成CompletableFuture，再用> thenComposeAsync(opt -> opt.map(v -> CompletableFuture.completedFuture(v)).orElse(CompletableFuture.failedFuture(new NullPointerException())))
异常传播与重试逻辑怎么嵌进 thenComposeAsync 链里
thenComposeAsync 本身不处理异常，上游抛异常会直接终止链，下游不会执行。强顺序依赖意味着“前一步失败，后一步绝不能跑”，但你也得让失败可捕获、可重试、可降级。
正确做法是在每个 thenComposeAsync 的 lambda 内部做 try/catch，或者统一用 handleAsync / exceptionally 拦截。但要注意：exceptionally 返回的是普通值，若要继续链式异步，得手动包成 CompletableFuture。
- 推荐模式：
upstream.thenComposeAsync(x -> CompletableFuture.supplyAsync(() -> callService(x), ioPool).handleAsync((res, ex) -> { if (ex != null) throw new RuntimeException("fallback failed", ex); return res; }, fallbackPool)) - 重试不要在
thenComposeAsync外层裸写 for 循环，应封装成独立方法返回CompletableFuture，例如retryAsync(() -> apiCall(), 3, Duration.ofSeconds(1)) - 慎用
whenCompleteAsync做日志或监控——它不改变结果，但若在里面抛异常，会静默吞掉，下游收不到原始异常
为什么有时链跑着跑着就“卡住”没反应
最常见原因是线程池耗尽或 future 未完成。比如用了 commonPool 跑大量 IO 任务，线程全 blocked 在 socket read 上，后续 thenComposeAsync 拿不到线程，一直 pending；或者某个环节忘了调 complete() / completeExceptionally()，future 永远不会触发下游。
调试时优先检查：上游是否真的 completed？下游的 executor 是否有空闲线程？有没有未 catch 的 unchecked exception 导致 future silent fail？
- 给每个
CompletableFuture加超时：future.orTimeout(5, TimeUnit.SECONDS)，避免无限等待 - 用
CompletableFuture.allOf组合多个链时，注意它不聚合结果，只等全部完成；要取结果得自己join()每个，且任一失败会导致 allOf 报CompletionException - 日志打点别只打“start”和“end”，要在每个
thenComposeAsync入口记录线程名（Thread.currentThread().getName()），确认线程切换是否符合预期
强顺序链的脆弱点不在语法，而在执行环境——线程池配置、异常路径覆盖、超时控制，这三个地方漏一个，整条链就可能静默失效。
