Java异常链通过Throwable的cause机制串联异常，推荐用new XxxException("msg", e)构造，避免丢原始堆栈；适用于跨层封装、补充上下文、受检转非受检场景；生效标志是日志中出现“Caused by”嵌套堆栈。
Java异常链是一种把多个相关异常串联起来的技术，核心是保留原始异常的上下文信息，让最终看到的异常堆栈里能清晰显示“谁引发了谁”。它不是额外加的功能，而是Java从Throwable类就内置的机制——每个异常对象都可以持有一个cause（原因异常），通过getCause()就能一层层往上追溯。
异常链怎么形成的？
关键在构造异常时传入原始异常作为cause参数。JDK中大多数异常类（如Exception、RuntimeException）都提供了带Throwable cause的构造方法。只要用了这个构造方式，链就自动建立了。
- 推荐写法：直接用
new XxxException("msg", e)，构造器内部会自动调用initCause(e) - 不推荐写法：先
new XxxException("msg")，再手动initCause(e)——容易因调用时机不对（比如已在fillInStackTrace()之后）导致失败或静默忽略 - 注意：
cause本身也可以有cause，所以链可以多层，但一般2~3层足够，过深反而难读
什么情况下必须用异常链？
不是所有异常都要包装，但以下三类场景不用就容易丢关键信息：
-
跨层封装时：比如DAO层抛出
SQLException，Service层想统一转成BusinessException，必须带上原异常，否则数据库错误细节全没了 -
补充业务上下文时：原始异常只说“连接超时”，你包装成
PaymentFailureException("支付下单失败，订单ID:20251208001")，日志里就能立刻定位到具体哪笔单 -
受检异常转非受检时：像
IOException不能直接往上抛（方法签名没声明），又不想吞掉它，就用RuntimeException("读取配置失败", ioEx)包装后抛出
常见误区和避坑点
异常链听着简单，实际用错反而让问题更难查：
立即学习“Java免费学习笔记（深入）”；
-
只记
e.getMessage()不传e：比如throw new RuntimeException(e.getMessage())——原始堆栈、异常类型、甚至SQL状态码全丢了 - 重复包装同一异常：A捕获e→包装为AEx；B又捕获AEx→再包装为BEx。结果堆栈里出现两层“Caused by”，但第二层cause其实是第一层包装异常，不是原始问题
-
自定义异常忘了支持cause构造器：如果自己写的
MyException只有MyException(String)，没写MyException(String, Throwable)，那别人就无法用它构建链
怎么看异常链是否生效？
运行时报错时，标准输出或日志里会出现明确的Caused by:段落。例如：
at com.example.UserService.register(UserService.java:45)
Caused by: java.sql.SQLIntegrityConstraintViolationException: Duplicate entry 'alice' for key 'users.email'
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:117)
只要看到“Caused by”后面跟着另一段堆栈，就说明链建成功了。生产环境建议配合日志框架（如Logback）开启%ex格式化，完整打印嵌套异常。
基本上就这些。异常链不是炫技，是让错误信息不打折地传到该看到的人手里——写对一行构造参数，省下半小时排查时间。
