异常链由Throwable的cause字段实现，通过带Throwable参数的构造器建立，每层需提供有效上下文，避免冗余包装。
异常链就是 Throwable 的 cause 字段在起作用
Java 里的异常链不是语法糖，也不是框架加的特性，而是从 Throwable 类就内置的机制：每个异常对象内部都持有一个 cause 字段（类型为 Throwable），用来记录“这个异常是由哪个原始异常引发的”。调用 e.getCause() 就能拿到它，e.printStackTrace() 会自动展开并显示 Caused by: ... 块——这就是你日志里看到嵌套堆栈的底层原理。
- 没有显式设置
cause时，getCause()默认返回null（不是自身） -
cause可以是任意Throwable子类，包括Error、Exception，甚至另一个包装了cause的异常 - JVM 不限制链长，但超过 4 层通常说明设计冗余——比如中间层只做
catch+throw new XxxException(...)却没加任何业务上下文
必须用 new XxxException("msg", e) 构造，别碰 initCause()
绝大多数时候，你应该用带 Throwable 参数的构造器来建立异常链，而不是事后调用 initCause()。后者不仅多写两行，还容易踩坑：
-
initCause()只能在fillInStackTrace()之前调用，而构造器一执行就默认调用了它；所以对已创建的异常再调initCause()，大概率抛IllegalStateException - 自定义异常如果没提供含
cause的构造器，上层代码就只能被迫用initCause()，等于把风险甩给调用方 -
标准库所有主流异常（
RuntimeException、IOException等）都支持双参构造，直接复用即可
try {
Files.readAllBytes(Paths.get("missing.txt"));
} catch (IOException e) {
throw new RuntimeException("读取配置失败", e); // ✅ 正确：cause 自动绑定
}
自定义异常不加 cause 构造器 = 主动丢根因
如果你写了 OrderException 或 PaymentTimeoutException 这类业务异常，却只提供了单参构造器：public OrderException(String message)，那别人想包装底层 SQLException 或 TimeoutException 时，就只能绕路用 initCause()，或者干脆放弃传递——结果就是线上报错只有 “订单创建异常”，看不到 SQL 错误码或超时时间。
- 正确做法：继承
Exception或RuntimeException后，显式提供两个构造器 - 双参构造器必须调用
super(message, cause)，不能自己实现空逻辑 - 别为了“统一风格”删掉双参构造器——业务异常的核心价值，就是既说清现象，又留住根因
public class OrderException extends RuntimeException {
public OrderException(String message) {
super(message);
}
public OrderException(String message, Throwable cause) {
super(message, cause); // ✅ 必须这行，否则链断了
}
}
异常链不是越深越好，关键看每层是否加了有效上下文
真实系统里健康的异常链通常是三层：业务语义层 → 框架适配层 → 技术根因层。例如：
立即学习“Java免费学习笔记（深入）”；
-
PaymentFailedException: 支付下单失败（业务层，告诉前端/运营发生了什么） - →
FeignException: HTTP POST /pay timeout after 5s（RPC 框架层，说明调用哪条链路卡住了） - →
SocketTimeoutException: Read timed out（JDK 底层，暴露网络细节，供运维查连接池或网关）
如果中间混进一个无意义的 WrapperException: 包装异常，或者把数据库异常和 Redis 异常强行串在一起，链就变成了干扰项。记住：每一层异常存在的唯一理由，是它比上一层更贴近业务，或比下一层更利于定位——不是为了“看起来专业”。
