CompletableFuture异常易被隐藏，需通过日志排查、handle兜底、检查rootCause、禁用join/get改用异步回调等方式提前显形。
CompletableFuture 的异常容易“藏起来”——不抛、不打印、不中断主线程，只在 get() 或 join() 时才突然爆发，而且堆栈常被 JDK 内部帧掩盖。排查关键不是等它报错，而是提前让异常“显形”。
看日志里有没有 silent fail 的痕迹
异步任务失败但没日志，是第一信号。重点检查：
- 所有
supplyAsync、thenApply等 lambda 是否漏了 try-catch，尤其涉及 IO、JSON 解析、数据库操作等易抛受检异常的地方 - 是否用了空的
exceptionally（比如只写ex -> null）或吞掉异常的whenComplete((r, ex) -> {}) - 日志框架是否配置了异步 appender？某些情况下异常日志会丢失，建议临时改用同步 ConsoleAppender 验证
用 handle 统一兜底，强制暴露异常
handle 是最可靠的“异常探针”，它不管成功失败都会执行，且能拿到结果和异常两个参数：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 在链路末端加一层
.handle((result, ex) -> { if (ex != null) log.error("链路异常", ex); return result; }) - 比
exceptionally更全面：它不会跳过正常流程，也不会因上游已处理异常而失效 - 适合放在聚合点（如
allOf后）或对外返回前，作为最后一道异常观测口
检查 CompletionException 的原始 cause
CompletableFuture 把所有异常都包装成 CompletionException，但真正有用的堆栈在 getCause() 里：
立即学习“Java免费学习笔记（深入）”；
- 调用
future.get()捕获到ExecutionException后，别直接打印它；要递归调用getCause()直到拿到非CompletionException的业务异常 - 常见陷阱：IDE 调试时只展开第一层，看不到
cause里的NullPointerException或SQLException - 可在全局异常处理器中封装一个工具方法：
Throwable rootCause = ExceptionUtils.getRootCause(ex)（Apache Commons Lang）
禁用 join/get，改用 thenAcceptAsync + 自定义线程池观察
阻塞调用会掩盖执行路径，也容易引发死锁，间接导致异常无法触发：
- 把
future.join()改成future.thenAcceptAsync(System.out::println, debugPool)，其中debugPool是独立的单线程池（如Executors.newSingleThreadExecutor()） - 这样一旦某阶段抛异常，线程池会打印未捕获异常（JVM 默认行为），立刻暴露问题
- 配合 JVM 参数
-Djava.util.concurrent.ForkJoinPool.common.exceptionHandler=xxx可捕获 commonPool 中的静默异常
