调用 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"));
    }
}</errorresponse>

这样返回的错误码、日志内容和堆栈都指向真正出问题的位置，而不是某次 supplyAsync 或代理调用的入口。