getCause() 返回 null 是因为异常链需显式构建，仅当使用带 Throwable 参数的构造函数（如 new RuntimeException(msg, cause)）时才会设置原因；否则默认为 null。
为什么 getCause() 返回 null 而不是原始异常？
因为 Java 异常链不是自动构建的——只有显式调用带 Throwable 参数的构造函数，才会把原因异常设进链里。比如 new RuntimeException("msg", cause) 或 new IOException(cause)；直接 new RuntimeException("msg") 抛出，再用 getCause() 查，必然返回 null。
常见错误现象：catch 住一个异常后，只用新消息包装再抛出，却忘了传入原异常：
catch (SQLException e) {
throw new ServiceException("DB operation failed"); // ❌ 没传 e，链断了
}
正确做法是：
- 始终使用带
cause参数的构造函数重新包装 - 若用 Lombok 的
@SneakyThrows或 Spring 的RuntimeException子类，确认其构造逻辑是否保留 cause - 避免在日志中只打印
e.getMessage()，它不包含链信息；应打印e整体或调用e.printStackTrace()
如何安全遍历整个异常链找到根因？
getCause() 只返回直接原因，但真实问题往往埋在第三、第四层（比如 JDBC 驱动抛出 SQLTimeoutException，其 cause 是 SocketTimeoutException，再下一层才是网络层 IOException）。手动 while 循环容易漏判 null 或陷入循环（某些框架会把自身设为 cause）。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
实操建议：
- 用 Apache Commons Lang 的
ExceptionUtils.getRootCause(e)，它内置了循环检测和 null 安全 - 自己写遍历时，必须检查
cause != null && cause != e，防止自引用 - 不要依赖
toString()输出判断层级——有些异常重写了它，只显示当前层
getCause() 在不同 JDK 版本下的行为差异
JDK 7 引入了 addSuppressed()，但 getCause() 语义没变；真正影响行为的是异常类本身的实现。比如：
-
InvocationTargetException的getCause()返回被反射调用方法抛出的异常，这是它唯一用途 -
CompletionException（CompletableFuture 中常见）的getCause()可能返回NullPointerException，但实际根因是上游supplyAsync里的空指针——得继续往下查 - JDK 19+ 对某些内部异常做了优化，
getCause()可能返回null即使有上下文，此时需结合getStackTrace()和getSuppressed()综合判断
日志系统里怎么让 getCause() 信息不丢？
很多日志框架（如 Logback、Log4j2）默认只记录最外层异常的堆栈，getCause() 链被截断。你看到的 “Caused by: …” 是框架解析出来的，不是 getCause() 自动展开的。
关键点：
- SLF4J 的
logger.error("msg", e)会完整输出链，但前提是e真的携带了 cause —— 否则还是只有一层 - 如果用
logger.error(e.getMessage(), e)，第二参数e才触发完整堆栈打印；只写logger.error(e.toString())就彻底丢失链 - ELK 或 Sentry 类系统依赖结构化字段，需手动把
getCause()链提取成 JSON 数组，不能只依赖默认序列化
异常链不是魔法，它靠人一环环接上；少一次 new XxxException(msg, cause)，后面排查就多三分钟。
