异常链通过Throwable的cause字段将多个异常串联，形成可追溯的因果关系；核心是新异常构造时传入旧异常，或调用initCause()绑定，且自定义异常必须提供含cause参数的构造器。
Java里的异常链，本质是把多个相关异常串成一条可追溯的线索链，让最外层抛出的异常能“记住”它是由哪个原始异常引发的。它不是语法糖，而是JVM内置的上下文保留机制——靠每个Throwable对象内部的cause字段实现。
异常链怎么形成的
核心就一句话：新异常在构造时显式传入老异常，JVM自动建立链接。这个“传入”有两种主流方式：
- 用带
Throwable cause参数的构造函数，比如new RuntimeException("操作失败", e)——这是最常用、最安全的做法 - 对已创建但没设cause的异常实例，调用
initCause(e)手动绑定；注意必须在fillInStackTrace()之前调用，否则会抛IllegalStateException
为什么不用异常链会丢关键信息
不传递cause，等于只报结果、不报原因。比如数据库操作失败，如果只抛new BusinessException("订单创建异常")，日志里就看不到底层是SQLException还是连接超时，更找不到具体SQL或错误码。而加上cause后，e.printStackTrace()会自动打印类似这样的结构：
imeout after 3000ms
自定义异常必须支持异常链
如果你写了OrderException或PaymentException这类业务异常，一定要提供含Throwable参数的构造方法：
- 继承
Exception或RuntimeException时，直接调用super(message, cause) - 不要只写单参构造器，否则上层代码想包装异常时只能用
initCause()，容易出错 - 所有业务层抛出的新异常，都应是原始技术异常（如
IOException、TimeoutException）的包装，而不是替代
异常链不是越深越好
真实系统中常见三层链：业务异常 → 框架异常 → 底层技术异常。超过四层往往说明设计有问题——比如中间某层无意义地捕获再重抛，或者把不同语义的异常强行串在一起。重点不是层数，而是每一层是否增加了有价值的上下文（比如“支付失败”比“HTTP调用异常”更贴近业务，“Redis连接拒绝”比“网络异常”更利于运维定位）。
