Java异常链需显式传入cause，单参构造函数仅接收String，双参构造或特定Exception子类的单参构造才支持cause；自定义异常须调用super(cause)或super(message, cause)，initCause()风险高且受限。
Java中Throwable的链式构造必须显式传入cause
Java异常链不是自动建立的，不手动传参就不会保留原始异常。哪怕你用throw new RuntimeException(e)，如果e是Exception类型，它也不会自动成为cause——因为RuntimeException的单参构造函数是把参数当message用的，不是当cause。
- 必须用双参构造：
new RuntimeException("msg", e)或new RuntimeException(e)（仅限Exception子类的单参构造，且该构造明确声明接受cause） -
Error和RuntimeException的单参构造只接收String，传Exception进去会调用toString()转成消息，原始堆栈彻底丢失 - 自定义异常要支持链式，必须在构造函数里显式调用
super(cause)或super(message, cause)
哪些构造函数真正支持cause？看JDK源码最准
别靠名字猜，比如IllegalArgumentException(String, Throwable)有，但IllegalArgumentException(Throwable)没有（JDK 17之前根本不存在这个重载）。常见误区是以为“带Throwable参数就一定设cause”，其实得看具体签名和实现。
- 标准做法：优先用
new XxxException(message, cause)形式，兼容性最好 - 慎用无
message的单cause构造——很多类没提供，或行为不一致（如NullPointerException根本不支持设cause） - 检查方法：点进IDE里的构造函数声明，看参数类型是不是
Throwable，且javadoc是否写明“the cause”
用initCause()补救？风险很大
这个方法只在cause为null时才允许调用一次，而且不能在构造过程中用（因为父类构造未完成），更不能对已设过cause的实例再调。实际场景中几乎没机会安全使用。
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 典型误用：
ex.initCause(originalEx)放在catch块里，但ex可能已在构造时设过cause，此时抛IllegalStateException - 它不改变
printStackTrace()的输出结构，但会让getCause()返回值不稳定（取决于是否成功调用） - 替代方案更可靠：直接重构为用双参构造新建异常
日志和调试时，getCause()可能返回null，但不代表没链
有些框架（如Spring AOP代理、某些RPC客户端）会在包装异常时漏掉cause传递，或者用Suppressed机制代替链式。这时候getCause()是null，但原始异常其实在getSuppressed()里，或藏在detailMessage里被字符串化了。
立即学习“Java免费学习笔记（深入）”；
- 排查链断裂：用
Throwable.printStackTrace()看完整堆栈，比只查getCause()更靠谱 - 记录日志时别只打
e.getMessage()，要用org.slf4j.Logger.error(String, Throwable)这种带Throwable参数的重载 - 自定义异常若重写了
toString()或getMessage()，务必确保不覆盖cause信息
异常链不是写个throw new Xxx(e)就完事的，每个构造函数的行为差异、每个框架的包装逻辑、每次日志输出的方式，都会悄悄吃掉原始异常。留心那些没报错但堆栈突然变短的时刻——那往往就是链断了。
