CompletableFuture.get()会阻塞线程，切勿在主线程直接调用；应使用thenApply/thenAccept/whenComplete等非阻塞方式处理结果，必要时加超时；组合操作需分清thenCompose（扁平化链式异步）与thenCombine（合并两个独立结果）；异常需用exceptionally或handle显式处理；IO任务必须指定自定义线程池，避免耗尽ForkJoinPool.commonPool()。
CompletableFuture.get() 会阻塞线程，别在主线程里直接调用
很多人一上来就写 future.get()，结果发现 UI 卡死、HTTP 请求超时、线程池耗尽。这是因为 get() 是同步阻塞的，会一直等到结果返回或抛异常，期间当前线程无法做其他事。
正确做法是用非阻塞方式消费结果：
- 用
thenApply()/thenAccept()做后续计算或副作用（如更新 UI、写日志） - 用
whenComplete()统一处理成功/失败（适合兜底日志或资源清理） - 真要等结果，至少加超时：
future.get(3, TimeUnit.SECONDS)，并捕获TimeoutException
多个异步任务怎么串行/并行执行？看这几个组合方法
thenCompose() 和 thenCombine() 容易混淆，关键区别在于「是否返回新的 CompletableFuture」：
-
thenCompose()：上一个任务返回的是CompletableFuture<T>，你接着返回另一个CompletableFuture<R>（比如查完用户再查订单），它会自动扁平化，避免嵌套CompletableFuture<CompletableFuture<...>> -
thenCombine()：两个独立的CompletableFuture都已完成，你把它们的结果一起拿来算（比如合并用户信息和缓存配置） -
allOf()只返回CompletableFuture<Void>，不带结果；想拿到所有结果得手动join()每个子 future，或者用allOf(...).thenApply(v -> Stream.of(f1, f2, f3).map(CompletableFuture::join).collect(...))
异常处理不能只靠 catch，CompletableFuture 的 fail-fast 机制很关键
CompletableFuture 一旦某个阶段抛出未捕获异常，后续的 thenApply() 等函数不会执行，而是跳到最近的 exceptionally() 或 handle()。这点和普通 try-catch 不同，容易误以为“没写 catch 就不会报错”。
立即学习“Java免费学习笔记（深入）”；
-
exceptionally(Function<Throwable, T>)：只在异常时触发，返回默认值，但无法区分异常类型 -
handle(BiFunction<T, Throwable, R>)：无论成功失败都进这里，适合统一记录状态 + 返回 fallback 值 - 别在
thenApply()里 throw 新异常却不处理——这会让整个链路中断，下游收不到任何信号
线程池选错会导致性能崩盘，supplyAsync 默认用 ForkJoinPool.commonPool()
supplyAsync(() -> heavyWork()) 看似简单，但默认用的是 ForkJoinPool.commonPool()，这个池子大小等于 CPU 核心数，专为短小、CPU 密集型任务设计。一旦你丢进去耗时 IO 操作（比如 HTTP 调用、数据库查询），线程很快被占满，新任务排队，吞吐骤降。
- IO 类任务务必指定自定义线程池：
supplyAsync(() -> api.call(), ioExecutor) - 推荐用
ThreadPoolExecutor，核心线程数设为预期并发量，拒绝策略建议CallerRunsPolicy（让调用方自己执行，起到自然限流作用） - 别用
Executors.newCachedThreadPool()，它无限创建线程，容易 OOM
CompletableFuture 写得再链式也白搭。 
