exceptionally仅捕获上游异常且必须返回同类型结果；handle则统一处理成功与异常两种情况，参数为BiFunction，支持结果清洗与日志聚合。
exceptionally 只捕获上游异常，且必须返回同类型结果
当你只关心“出错了怎么兜底”，不打算处理正常流程，exceptionally 是最轻量的选择。但它有个硬约束：参数只能是 Throwable，返回值类型必须和原始 CompletableFuture 的泛型一致——哪怕你只是想返回个默认值，也得手动 cast 或构造。
- 常见错误现象：
exceptionally里 returnnull导致下游join()报NullPointerException（尤其泛型是基本类型包装类时） - 使用场景：HTTP 调用失败时返回缓存值、降级响应，或统一打点后抛运行时异常
- 参数差异：它不接收正常结果，所以拿不到成功时的
String、Integer等值，纯异常通道 - 示例：
future.exceptionally(t -> { log.error("fetch failed", t); return "default"; })
handle 是真正的“结果/异常二合一”处理器
handle 的签名是 BiFunction<t throwable r></t>，两个参数始终存在：成功时 Throwable 为 null，失败时 T 为 null。这意味着你能写统一逻辑判断分支，也更容易做类型转换或日志聚合。
- 常见错误现象：误以为
handle中的Throwable非空就代表“一定失败”，其实上游可能主动返回了null结果 +null异常（极少见但合法） - 使用场景：需要根据成功/失败分别记录不同指标、做结果清洗（如把异常转成特定错误码）、或统一包装成
Result<t></t>类型 - 性能影响：比
exceptionally多一次函数调用开销，但几乎可忽略；关键是它强制你面对两种路径，不易漏判 - 示例：
future.handle((result, ex) -> ex != null ? "fallback" : result.toUpperCase())
别在 exceptionally 里 throw 新异常，除非你真想中断链式调用
exceptionally 的设计本意是“兜底并继续”，如果你在里面 throw 新异常，下游的 thenApply 会跳过，但再后面的 exceptionally 或 handle 仍能捕获——这容易造成异常处理逻辑分散，调试时找不到源头。
- 容易踩的坑：用
exceptionally做日志 + rethrow，结果发现异常没被上层try/catch捕获，因为CompletableFuture默认异步执行，异常会“掉进黑洞” - 正确做法：想中断就用
handle显式返回null或特殊标记，再由下游判断；真要抛异常，优先用whenComplete（它不改变结果类型，只做副作用） - 兼容性注意：Java 8 的
exceptionally无法处理CompletionException包裹的原始异常，需用getCause()解包才能匹配业务异常类型
handle 和 exceptionally 对下游链的影响完全一致
很多人以为 handle 会“吞掉”异常、让后续 thenApply 正常执行，其实不然：只要 handle 返回的是非异常结果，下游就收到该结果；如果 handle 自己抛了异常，或者返回 null（而泛型不可为空），下游照样走异常路径。这点和 exceptionally 行为对齐，但容易因命名产生误解。
- 关键细节：两者都**不会改变 CompletableFuture 的完成状态**——失败就是失败，成功就是成功，只是替换了结果值
- 调试建议：加
whenComplete((r, e) -> System.out.println(r + "/" + e))在链尾，一眼看清最终交付的是什么 - 真实陷阱：当上游是
supplyAsync(() -> { throw new RuntimeException(); })，handle的ex参数是CompletionException，不是原始RuntimeException，直接instanceof会失败
