应递归解包InvocationTargetException、ExecutionException、CompletionException等包装异常，获取最内层业务异常；使用unwrapThrowable工具方法，并在日志中以logger.error(msg, throwable)格式输出以保留完整堆栈。
在异步线程池中（如 ThreadPoolExecutor 或 CompletableFuture），当任务通过反射调用（如 Method.invoke()）抛出异常时，JVM 会自动将原始异常包装为 InvocationTargetException。此时直接捕获该异常本身没有意义——关键是要**解包并还原最内层的业务异常**（即 getTargetException()），且需确保在线程池上下文中不丢失堆栈和类型信息。
为什么异步环境下容易丢失元原因
异步执行中，异常可能经过多层封装：
-
Method.invoke()→ 包装为InvocationTargetException - 提交到
ExecutorService.submit()→ 返回Future，异常被封装进ExecutionException - 若用
CompletableFuture+thenApply等链式调用 → 异常可能再被包进CompletionException
如果不逐层解包，日志里只看到 InvocationTargetException，根本看不到 NullPointerException 或 SQLException 这类真实问题。
精准提取元原因的通用解包方法
核心原则：**从外向内、递归解包，直到拿到非包装类异常**。推荐一个健壮的工具方法：
立即学习“Java免费学习笔记（深入）”；
示例代码：
public static Throwable unwrapThrowable(Throwable t) {
while (t != null &&
(t instanceof InvocationTargetException ||
t instanceof ExecutionException ||
t instanceof CompletionException)) {
t = t.getCause();
}
return t == null ? new RuntimeException("Unknown error") : t;
}
使用方式：
- 在
future.get()后调用：unwrapThrowable(future.get()) - 在
CompletableFuture.exceptionally()中：unwrapThrowable(throwable) - 在
Thread.UncaughtExceptionHandler中统一处理
在 CompletableFuture 中避免二次包装
CompletableFuture 默认会把 InvocationTargetException 再包成 CompletionException，但它的 cause 仍是原 InvocationTargetException。所以仍需解包：
CompletableFuture.supplyAsync(() -> {
try {
return someMethod.invoke(obj, args); // 可能抛 NPE/IllegalArgumentException
} catch (Throwable e) {
throw e; // 不要 catch Exception 而忽略 Error/Throwable —— 反射可能抛出任意 Throwable
}
}).exceptionally(t -> {
Throwable root = unwrapThrowable(t);
log.error("业务异常：{} {}", root.getClass().getSimpleName(), root.getMessage(), root);
return null;
});
注意：不要用 catch (Exception e) 捕获反射调用——Error 和 RuntimeException 子类（如 OutOfMemoryError）也会被 invoke() 包进 InvocationTargetException，必须用 catch (Throwable)。
保留原始堆栈的实践建议
解包后，原始异常的堆栈默认保留，但要注意两点：
- 如果手动 new 新异常并 setCause，记得调用
initCause()或构造函数传入 cause，否则堆栈会丢失 - 日志框架（如 Logback/Log4j2）打印异常时，确保用
logger.error(msg, throwable)形式，而非logger.error(msg + " " + throwable)，后者只输出 toString()，丢弃堆栈 - 若需增强异常信息（如添加 traceId），建议用装饰器模式包装，而不是新建异常丢弃 cause
