调用 getCause() 是为了穿透多层包装异常获取原始根因；需循环剥离 CompletionException、InvocationTargetException 等包装类，结合类型判断保留业务异常或受检异常，并在全局异常处理器中基于根因分类响应与日志。
在全局异常处理器中调用 getCause() 是为了穿透多层包装异常（如 ExecutionException、CompletionException、RuntimeException 包装的业务异常），最终获取最原始、最具诊断价值的那个“真实报错”。但直接调用一次 getCause() 往往不够——因为异常可能被嵌套多层。
理解异常嵌套的本质
Java 中常见场景会导致异常层层包裹：
- CompletableFuture 异步执行失败 → 抛出
CompletionException，其cause才是业务异常 - 反射调用（
Method.invoke）出错 → 包装为InvocationTargetException，真实异常在getTargetException() - Spring AOP 或事务代理 → 可能将原始异常再包一层
UndeclaredThrowableException或自定义运行时异常 - 手动 throw new RuntimeException(e) → 原始异常成为 cause，但需递归提取
用循环 getCause() 剥离到根因
不依赖固定层数，而是持续检查 getCause() != null 并跳过已知的“包装器类型”：
public static Throwable getRootCause(Throwable t) {
while (t != null && t.getCause() != null) {
// 跳过常见的包装类，避免无意义的穿透（例如某些日志框架会再包一层）
if (t instanceof CompletionException ||
t instanceof ExecutionException ||
t instanceof InvocationTargetException ||
t instanceof UndeclaredThrowableException) {
t = t.getCause();
} else {
break;
}
}
return t;
}
注意：不要无条件循环到底，否则可能陷入 Cyclically nested causes（JDK 8+ 已默认防护，但自定义异常仍需留意）。
结合异常类型做精准识别
仅靠 getCause() 不够，还需判断是否为“业务关心的真实异常”。建议策略：
- 优先保留非
RuntimeException的受检异常（如SQLException、IOException），它们通常更贴近问题根源 - 对
RuntimeException子类，过滤掉框架/中间件专用包装类（如ResponseStatusException、HttpClientErrorException），保留自定义业务异常（如InsufficientBalanceException） - 记录原始异常栈（
getRootCause(e).getStackTrace()）而非外层包装栈，便于排查
在 Spring @ControllerAdvice 中实践
全局异常处理器中，应先剥离再分类处理：
@ExceptionHandler(Exception.class)
public ResponseEntity<ErrorResponse> handleAllExceptions(Exception e) {
Throwable root = getRootCause(e);
if (root instanceof BusinessException) {
return ResponseEntity.badRequest().body(new ErrorResponse("BUSINESS_ERROR", root.getMessage()));
} else if (root instanceof SQLException) {
log.error("DB error occurred", root); // 记录根因
return ResponseEntity.status(500).body(new ErrorResponse("DB_ERROR", "Database unavailable"));
} else {
log.error("Unexpected error", root); // 关键：传 root，不是 e
return ResponseEntity.status(500).body(new ErrorResponse("UNKNOWN_ERROR", "Service error"));
}
}
这样返回的错误码、日志内容和堆栈都指向真正出问题的位置，而不是某次 supplyAsync 或代理调用的入口。
