排查java异常需协同使用getcause()和getstacktrace()：前者递归获取root cause定位根本错误，后者提取根因栈帧揭示调用路径，配合日志结构化输出可高效定位问题。
排查 Java 异常问题，单靠 getCause() 或 getStackTrace() 都不够——前者帮你往下挖根因，后者帮你往上定位现场。二者配合，才能既看清“错在哪一层”，又知道“谁调的、怎么走到这的”。
getCause() 解决“到底是什么错了”
很多异常是层层包装的：比如一个 HTTP 调用失败，外层可能是 RuntimeException，中间是 FeignException，再里面才是真正的 SocketTimeoutException。只看最外层，你会以为是业务逻辑出错；而 getCause() 是唯一能一级级向下穿透的入口。
- 必须递归调用，直到返回
null，才算找到 root cause（如ConnectException） - 不能只调一次：一次
getCause()只跳一层，容易漏掉第三、第四层的真实错误 - 注意自引用风险：某些自定义异常误设
initCause(this)，遍历时要加cause != current判断 - 优先用
ExceptionUtils.getRootCause(e)（Apache Commons Lang），它已内置循环防护和 null 安全
getStackTrace() 解决“怎么走到这一步的”
getStackTrace() 返回的是当前异常对象“被抛出时”的调用栈，反映的是“谁触发了这个异常”。它不随 getCause() 变化——每个 Throwable 实例都有自己的栈，包括嵌套异常。
- 外层包装异常的栈，通常只到代理层或框架入口（如
ReflectiveMethodInvocation），看不出业务代码 - root cause 的栈才包含真实出错点（如
JdbcClient.query(...)或OkHttpClient.newCall(...)） - 生产环境别直接调
e.printStackTrace()，改用StringWriter + PrintWriter转成字符串，再交由日志框架异步输出 - 栈帧太多会撑爆日志，建议只取前 5–10 行关键调用，避开 JDK 内部和 AOP 代理类
两者配合的典型日志结构
一条高信息密度的异常日志，应同时体现“根因类型+消息”和“根因栈顶几行”，而不是堆砌整条链或只记外层。
- 格式示例：
[traceId=abc] RootCause: java.net.SocketTimeoutException: timeout → at okhttp3.internal.http2.Http2Stream$StreamTimeout.newTimeoutException(Http2Stream.java:649) - 先用
getRootCause(e)拿到最内层异常 - 再对它调用
getStackTrace()，提取第 0 行（抛出点）和附近 1–2 行（上下文方法） - 避免拼接完整栈字符串——开销大、难检索，交给 Logback 的
%ex{5}或异步 Appender 渲染更稳妥
绕不开的常见陷阱
实际排查中，这两个方法经常“失效”，不是 API 有问题，而是上下文没对齐。
-
getCause()返回null？多数情况是异常没被显式包装（如throw new RuntimeException("msg")），原始异常已丢失 -
getStackTrace()看不到业务方法？说明异常在中间层被重新抛出且未保留原栈（如throw new ServiceException(e)但忘了调e.fillInStackTrace()） - 异步场景（
CompletableFuture）下，外层是CompletionException，它的getStackTrace()是 CompletableFuture 内部线程的，真正业务栈藏在getCause()的下一层 - 日志框架默认只打印外层栈，“Caused by”是它自己解析的文本，并非调用了
getCause()；若你只记录e.toString()，整条链就消失了
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
