CompletableFuture.thenApply 返回 null 是因它原样传递上游返回值，不处理异常或null；需确保上游明确返回非null值，或改用thenApplyAsync+exceptionally组合。
CompletableFuture.thenApply 为什么返回 null 而不是预期结果
常见现象是调用 thenApply 后，后续链路拿到 null，尤其在上游任务抛异常或返回 null 时。它不会自动包装异常，也不会跳过 null —— 它只是原样把上游的返回值传给你的函数。
实操建议：
- 确保上游
supplyAsync或thenApply的 lambda 体明确返回非null值，或主动处理null场景 - 若上游可能失败，改用
thenApplyAsync+exceptionally组合，而不是依赖thenApply捕获异常 -
thenApply是同步执行（在前一个任务完成的同一线程中调用），若函数体耗时长，会阻塞整个链路；高延迟场景优先用thenApplyAsync
如何让多个异步任务并行执行再汇总结果
别用 thenCompose 串行拼接，那是为“上一个结果驱动下一个任务”设计的。并行汇总得靠 CompletableFuture.allOf 或 CompletableFuture.<font color="red">join</font> 配合 stream().map(CompletableFuture::join).collect()。
实操建议：
-
allOf返回CompletableFuture<Void>，不携带结果 —— 必须手动从原始 future 列表里join()取值 - 更推荐：用
Stream.of(f1, f2, f3).map(CompletableFuture::join).toList()，语义清晰且可直接获得泛型结果列表 - 注意
join()会阻塞当前线程直到完成，若在 WebFlux 或 Netty 线程中调用，可能引发响应延迟；应确保只在计算线程池（如ForkJoinPool.commonPool()或自定义Executor）中使用
异常传播为什么在 thenAccept 中消失了
thenAccept 和 thenRun 这类消费型方法，**完全不处理异常**：上游抛异常，它们直接跳过，后续链路收不到通知，也拿不到异常信息。
实操建议：
- 只要需要感知失败，就必须显式接入
exceptionally、handle或whenComplete -
handle最灵活：接收(result, throwable)两个参数，无论成功失败都进这个回调，适合统一日志或兜底转换 -
exceptionally只在异常时触发，且必须返回与原始 future 相同类型的值（比如上游是CompletableFuture<String>，你就得返回一个String），否则编译不过
线程切换不生效？检查 executor 参数是否被忽略
thenApplyAsync 默认用 ForkJoinPool.commonPool()，但如果你传了自定义 Executor 却发现没生效，大概率是因为：上游任务本身还没结束，而你误以为“async 就一定新开线程”。实际上，thenApplyAsync 的线程切换只发生在“前一个任务已完成”的前提下。
实操建议：
- 确认上游是否真的已完成：加
whenComplete((r, t) -> System.out.println("done: " + (t == null)))观察 - 避免在
thenApplyAsync里写阻塞操作（如Thread.sleep、JDBC 查询），它会拖垮整个线程池；该用thenCompose+supplyAsync(..., dbExecutor)拆离 - Spring 环境下，别直接 new
ThreadPoolTaskExecutor后忘记initialize()，否则execute()会静默失败
thenAccept 根本没跑。 
