CompletableFuture异常不会自动传播，需显式处理：用handle统一收口、exceptionally降级、whenComplete做副作用；受检异常须包装为RuntimeException；thenCompose内层异常需内部防护；禁用get/join观测异常。
CompletableFuture 的异常不会自动向下游传播，一旦某个阶段抛出异常且未显式处理，整个链就会“断掉”——后续的 thenApply、thenAccept 等回调根本不会执行，也没有日志、不报错、不中断，表现为静默失败。避免这个问题，关键不是“兜住所有异常”，而是建立可观察、可降级、有痕迹的异常处理习惯。
必须在链末端显式注册异常处理回调
不能依赖“上游会处理”或“反正有日志框架”。只要异步链中任意一环可能失败，就必须在链的某个位置插入异常感知逻辑：
-
用
handle()统一收口：它接收(result, throwable)两个参数，无论成功或失败都执行，适合记录日志 + 返回兜底值 -
用
exceptionally()做降级：只在上游失败时触发，返回替代结果，让后续thenApply能继续运行 -
用
whenComplete()做副作用：比如打点监控、发告警、清理资源，不改变结果值
别让受检异常在编译期就绕过异常处理机制
CompletableFuture 的函数式接口（如 Supplier、Function）不支持声明抛出受检异常。如果你在 supplyAsync 里直接 throw new IOException()，代码根本编译不过——但这不代表问题消失，而是让你误以为“没异常”。正确做法是主动包装：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 在 lambda 内用
try-catch捕获受检异常，转为RuntimeException并保留原始异常作cause - 例如：
throw new RuntimeException("读取配置失败", e) - 这样包装后的异常才能被
exceptionally或handle正确捕获，并通过ex.getCause()还原真实原因
警惕 thenCompose 中的异常“折叠”陷阱
当使用 thenCompose 返回一个新的 CompletableFuture 时，如果内层 future 执行失败，外层不会立即感知该异常，而是把它“塞进”内层 future 的 outcome 字段。此时 exceptionally() 只能捕获外层调用本身的异常，对内层失败无感。
立即学习“Java免费学习笔记（深入）”；
- 解决方案：在
thenCompose的 lambda 内部，就对返回的 future 做异常防护，比如用handle包一层再返回 - 示例：
.thenCompose(r -> dbCall(r).handle((v, ex) -> ex != null ? fallback() : v)) - 或者改用
thenComposeAsync配合自定义线程池，便于隔离和监控
禁用 get() / join() 作为日常异常观测手段
靠 future.get() 或 join() 触发异常并捕获，属于“事后补救”，且会阻塞线程，破坏异步模型。更危险的是，它掩盖了链式结构本身是否健壮的问题。
- 真正可靠的异常可观测性，来自非阻塞的回调链设计
- 若必须调试，优先用
handle输出完整ex.printStackTrace()到日志，而不是在控制台get()看堆栈 - 生产环境应配合监控埋点：比如统计
handle中ex != null的调用频次，形成异常水位看板
