应穿透 CompletionException 获取原始异常，优先用 exceptionally() 快速兜底，次选 handle() 统一处理结果与异常，避免阻塞调用 get()/join()；若必须阻塞，则需 getCause() 解包并设超时。
CompletionException 不是业务代码直接抛出的异常，而是 CompletableFuture 自动包装底层真实异常的“外壳”。处理它的核心不是捕获它本身，而是穿透这层包装，拿到原始异常，并在链式流程中做合理响应。
别 catch CompletionException，要 getCause()
直接 try-catch (CompletionException e) 或更宽泛的 Exception e，会导致日志里只看到 java.util.concurrent.CompletionException，完全丢失“空指针”“参数非法”等关键业务信息。正确做法是在异常回调里主动解包：
- 在 exceptionally()、handle() 或 whenComplete() 的参数中收到 Throwable t 时，先判断：
if (t instanceof CompletionException) t = t.getCause(); - 再对 t 做类型判断（如
t instanceof NullPointerException）或记录日志：log.error("原始异常", t); - 尤其注意：get() 或 join() 阻塞调用抛出的 CompletionException，也必须用
e.getCause()才能看到真正原因
用 exceptionally() 快速兜底，默认值优先
当你只需要一个简单 fallback——比如查缓存失败就查 DB、远程调用超时返回默认列表——exceptionally() 最清晰、最安全：
- 它只在上游任意 stage 抛异常时触发，不会干扰正常流程
- 参数是 Throwable，返回值必须和原始 CompletableFuture 泛型一致（例如
CompletableFuture<String>的 exceptionally 必须返回 String） - 示例：
.exceptionally(t -> { log.warn("fallback due to", t); return "default"; }) - 切记：不要在 exceptionally 里 throw 新异常，否则会中断整个链
用 handle() 统一收口，兼顾结果与异常
当需要同时记录耗时、区分异常类型做不同降级、或成功后还要补日志时，handle() 更灵活：
立即学习“Java免费学习笔记（深入）”；
- 它接收两个参数：
(result, throwable)，二者必居其一为 null - 成功时 result 非 null、throwable 为 null；失败时 result 为 null、throwable 非 null
- 务必判空，避免 NPE：
if (throwable != null) { ... } else { ... result ... } - 若在 handle 中处理了异常且未 re-throw，下游 thenApply 会照常执行——这是它和 exceptionally 的关键行为差异
避免阻塞，让异常自然流动
调用 get() 或 join() 是 CompletionException 最常见的暴露点，但这其实是设计倒退。异步链应尽量保持非阻塞：
- 用 thenAccept() 消费结果、thenCompose() 组合新异步任务，而不是中途打断去 get()
- 如果必须同步等待（如测试或老系统集成），确保外层有 try-catch + getCause()，并考虑加超时：
future.get(3, TimeUnit.SECONDS) - 阻塞调用不仅掩盖异常本质，还可能拖垮线程池，尤其在 commonPool 中混入 IO 操作时
