异常链是Java内置的cause机制，通过Throwable(String, Throwable)构造器自动构建Caused by:嵌套堆栈，用于跨层封装、补充业务上下文、受检转非受检三类场景，避免丢弃关键线索。
异常链就是 Throwable 的 cause 机制，不是“新功能”，而是 Java 自带的因果追踪能力
Java 异常链的本质，是每个 Throwable 实例都可以持有一个 cause（原因异常），通过 getCause() 向上追溯。它不依赖第三方库，也不需要手动维护链表——只要你在构造新异常时传入原始异常，JVM 就自动帮你串起来。
- 生效标志非常明确：日志或控制台输出中出现
Caused by:嵌套堆栈段落 - 链可以多层（
e.getCause().getCause()），但一般 2～3 层足够；过深反而干扰主因定位 - 所有标准异常（
Exception、RuntimeException等）都内置了Throwable(String, Throwable)构造器，开箱即用
必须用异常链的三种典型场景
不用异常链，等于主动丢掉关键线索。以下三类情况一旦跳过 cause，问题排查就会卡在“知道失败，不知为何失败”：
-
跨层封装：DAO 层抛
SQLException，Service 层转成BusinessException时没传原异常 → 数据库错误码、SQL 状态、具体驱动报错全消失 -
补充业务上下文：原始异常只说
"Connection timed out"，你包装成PaymentFailureException("支付下单失败，订单ID:20260204001")→ 日志里一眼锁定问题单据 -
受检异常转非受检：方法签名不能声明
IOException，又不能吞掉它 → 用RuntimeException("读取配置失败", ioEx)包装后抛出，既合规又保信息
最常踩的三个坑：丢堆栈、重复包装、自定义异常不支持 cause
这些错误不会编译失败，但会让日志失去价值：
-
只记
e.getMessage()不传e：throw new RuntimeException(e.getMessage())—— 原始堆栈、异常类型、甚至 SQLState 全丢光 -
重复包装同一异常：A 捕获
e→ 包装为AEx；B 又捕获AEx→ 再包装为BEx→ 堆栈里出现两层Caused by:，但第二层cause是AEx而非原始e -
自定义异常忘了加 cause 构造器：如果
MyException只有MyException(String)，没有MyException(String, Throwable)，别人就无法用它构建链，等于废掉整个机制
正确写法就一条：优先用 new XxxException("msg", e)
这是 JDK 内置保障最稳的方式。构造器内部会安全调用 initCause(e)，且严格避开 fillInStackTrace() 之后的时机风险。
