异常链的核心作用是确保错误根源可追溯，必须通过Throwable带cause构造方法构建、日志中递归打印getCause()、自定义异常显式委托cause参数，任一环节缺失都会导致根因丢失。
异常链的核心作用是：让“谁导致了这个错误”可追溯，而不是只看到最后一层抛出的异常。 它不是锦上添花的功能，而是你在排查生产环境 NPE、SQL 异常、Feign 调用失败时，能否 3 分钟内定位到数据库连接池耗尽还是配置写错了的关键。
Throwable 构造方法里传 cause 是最常用也最安全的方式
Java 所有异常类（Exception、RuntimeException 等）都继承自 Throwable，而它提供了带 cause 参数的构造方法——这是构建异常链的「黄金路径」。
- 推荐始终优先使用
new XxxException("业务失败", originalException)，比如：throw new ServiceException("订单创建失败", e); - 不要用
initCause()后置设置——它只能调用一次，且若异常已初始化过（如被序列化或打印过堆栈），会直接抛IllegalStateException； - 注意：如果原始异常是
NullPointerException或IllegalArgumentException这类运行时异常，且你包装成新的RuntimeException，链依然有效；但若包装成受检异常（如IOException），需确保方法签名 throws 正确类型； - JDK 7+ 支持
try-with-resources自动添加 suppressed 异常（非 cause），别把它和 cause 混为一谈——getCause()只返回一个，getSuppressed()返回数组。
日志里不打 getCause() 就等于白建异常链
很多团队写了包装异常，却在日志里只调 e.toString() 或 e.getMessage()，结果日志里永远只有“服务调用失败”，看不到底层是 ConnectException: Connection refused。
- SLF4J / Logback 默认
logger.error("xxx", e)会自动递归打印整个 cause 链（包括 nested exception），这是最省心的用法； - 如果手动拼日志，务必用
e.printStackTrace(new PrintWriter(stringWriter))或调用e.getStackTrace()+e.getCause()循环展开； - Spring Boot 默认日志已支持嵌套异常展开，但如果你用了自定义
ErrorController或全局@ExceptionHandler，返回 JSON 时容易只序列化顶层异常——记得显式加e.getCause() != null ? e.getCause().getMessage() : null字段。
自定义异常类必须显式委托 cause 构造方法
很多人写自定义异常时只重载了 String message 构造方法，忘了把 Throwable cause 也接住，结果链在第一层就断了。
public class BizException extends RuntimeException {
public BizException(String message) {
super(message);
}
// ❌ 缺少这个构造方法 → 包装时 cause 丢失
public BizException(String message, Throwable cause) {
super(message, cause); // ✅ 必须显式调用父类带 cause 的构造器
}
}
- IDEA 可以快捷生成所有构造方法（Alt+Insert → Constructors → 勾选含 Throwable 的）；
- 如果用了 Lombok 的
@AllArgsConstructor，它不会自动识别Throwable为 cause 参数，仍需手写或改用@SuperBuilder+ 显式构造； - Spring 的
ResponseStatusException支持 cause，但它的子类（如HttpRequestMethodNotSupportedException）不一定透传，谨慎包装。
真正难的不是写对那行 new XxxException(msg, e)，而是整条调用链上每个中间层都保持这个习惯——漏一层，根源就沉底。线上查问题时，最痛的不是没日志，而是日志里只有一半链。
