准确获取底层异常需循环调用getcause()并判空、限深、防循环，因多数异常默认无cause；不同场景须区别处理，如executionexception必须调getcause()，而spring的transactionsystemexception需用getoriginalexception()。
直接调用 getcause() 并不能保证拿到底层核心异常——它只返回当前异常的“直接原因”，而真实场景中异常常被多层包装。准确追踪，关键在“判空 + 循环 + 限深 + 结合上下文”。
为什么 getCause() 经常返回 null？
不是代码写错了，而是很多异常根本没设 cause：
- 运行时异常（如
NullPointerException、IllegalArgumentException）用默认构造器抛出时，getCause()永远是null - 只有显式使用带
Throwable参数的构造器（如new RuntimeException("msg", e)），或容器/框架自动封装时，cause 才非空 - JDK 中仅少数异常（如
ExecutionException、InvocationTargetException）会自动包装原始异常
怎么安全获取最底层异常？
别只调一次 getCause()，要循环遍历并加保护：
- 始终先判空：
if (e == null || e.getCause() == null) return e; - 用 while 循环逐层下钻，但必须限制深度（建议 ≤10 层），防止自定义异常误设自身为 cause 导致死循环
- 推荐封装工具方法：
getRootCause(Throwable t)，内部用IdentityHashSet检测循环引用 - 注意：某些框架（如 Spring 的
TransactionSystemException）不走getCause()，得调getOriginalException()
不同场景下的正确用法
同一方法，在不同上下文逻辑不同：
-
Servlet 容器抛
ServletException：仅当它是new ServletException("xxx", e)构造，或 Tomcat/Jetty 自动封装（如 JSP 编译失败、forward 出错）时，getCause()才有效 -
Future.get()抛ExecutionException：getCause()是唯一入口，必须调用才能拿到你Callable里真正 throw 的异常；但InterruptedException或TimeoutException本身已是原始异常，不支持getCause() -
RestTemplate HTTP 错误：可能抛
HttpClientErrorException，其cause常为IOException，但也可能为空——此时需看response.getBody()或状态码，不能只依赖 cause
日志与诊断中的实战要点
光取到 root cause 不够，还要让它真正有用：
- 打印时别只写
e.getMessage()，那只是外层描述；应log.error("业务失败", rootCause)，让日志框架输出完整堆栈 - 做分类处理时，对
rootCause而非外层异常做instanceof判断（例如rootCause instanceof SQLException触发重试） - 避免二次包装丢失信息：不要
throw new RuntimeException(e)，而应throw new RuntimeException(rootCause)或保留其为 cause - 在 AOP 切面或全局异常处理器中，优先提取 root cause 再判断是否为系统级异常（如
SocketTimeoutException），决定是否跳过告警
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
