异常链是Throwable类内置的因果追踪机制，通过带cause参数的构造函数创建，用于跨层封装、补充上下文和受检转非受检异常，日志需用logger.error(msg, e)才能显示Caused by。
异常链不是Java的“新功能”，而是从 Throwable 类诞生起就内置的因果追踪机制：一个异常可以明确声明“我是由另一个异常引起的”，并通过 getCause() 逐层回溯，最终在日志里呈现为带 Caused by: 的嵌套堆栈。
怎么创建异常链？只用对构造函数传参
最可靠、最常用的方式，就是使用带 Throwable cause 参数的异常构造函数：
-
new RuntimeException("业务失败", e)—— 推荐，JDK 所有标准异常都支持，内部自动调用initCause(e) -
new MyException("订单处理异常", e)—— 前提是你的自定义异常类显式提供了该构造方法，并把cause传给super(message, cause) - 避免手动调用
initCause(e)：它要求在fillInStackTrace()之前执行，而这个时机难控制，容易静默失败或抛IllegalStateException
什么场景必须用异常链？三类不包装就丢根的问题
不是所有 catch 都要包装，但以下情况不用异常链，等于主动抹掉故障定位线索：
-
跨技术层级封装：比如 DAO 层抛出
SQLException，Service 层转成BusinessException，不传e就只剩 “操作失败”，连 SQL 错误码、连接超时还是语法错误都看不到 -
补充关键业务上下文：原始异常是
SocketTimeoutException，你包装成PaymentTimeoutException("支付超时，订单ID=ORD-20260112-889")，日志里一眼锁定问题单据 -
受检异常转非受检：方法签名不能声明
IOException，又不能吞掉它，就用RuntimeException("加载配置失败", ioEx)包装后抛出，既合规又保信息
为什么日志里没看到 Caused by:？常见失效原因
异常链“建了但看不见”，基本是这几个低级但高频的坑：
立即学习“Java免费学习笔记（深入）”；
-
throw new RuntimeException(e.getMessage())—— 只取了消息字符串，e的类型、堆栈、SQLState 全丢了 - 自定义异常漏写
MyException(String, Throwable)构造器，别人一包装就退化成普通异常 - 重复包装同一异常：A 层已用
ServiceException("xxx", sqlEx)包了一次，B 层又接住它再包成ApiException("yyy", serviceEx)，结果堆栈里出现两层Caused by:，第二层其实是包装异常本身，不是根源 - 日志打印方式不对：只写
logger.error("出错了", e.getMessage())，正确姿势是logger.error("出错了", e)（Logback/SLF4J 会自动输出全链）
public class ServiceException extends Exception {
public ServiceException(String message) {
super(message);
}
public ServiceException(String message, Throwable cause) {
super(message, cause); // 必须这行！否则链断
}
}
异常链真正的难点不在“会不会用”，而在“在哪停”——链太短，信息不足；链太深（超过 3 层），反而掩盖真正根源。多数时候，只在抽象边界（DAO→Service→API）和语义跃迁（技术异常→业务异常）处包装一次就够了。
