异常链通过保留原始异常的cause，使全局未捕获异常可读、可溯、可修；支持逐级回溯、精准分类、避免静默吞异常，并与安卓/服务端全局捕获机制形成闭环。
异常链本身不直接防止全局未捕获异常，但它让全局未捕获异常变得“可读、可溯、可修”——这是防范其演变为线上事故的关键前提。
让未捕获异常真正暴露根源，而非掩盖在包装层下
当一个异常在层层调用中被多次包装（如从 DAO 层的 SQLException 包装成 ServiceException，再包装成 BusinessException），若未使用异常链，原始堆栈和根本原因就会丢失。全局异常处理器捕获到的只是一个空泛的顶层异常，日志里看不到 Caused by:，开发者只能靠猜或翻代码去还原现场。
启用异常链后：
- 每层包装都通过
new ServiceException("DB操作失败", e)显式传入 cause - 全局处理器（如
Thread.setDefaultUncaughtExceptionHandler）拿到的异常，调用e.getCause()可逐级回溯 - 日志打印自动展开完整链路，IDE 调试时也能一键展开 cause 查看各环节上下文
支撑精准的全局异常分类与差异化响应
没有异常链，所有被包装过的异常类型都趋同（比如全是 RuntimeException 子类），全局拦截器无法区分是网络超时、参数校验失败，还是数据库连接池耗尽。结果只能统一弹 Toast 或上报通用错误码，失去业务语义。
有了异常链，就能结合 cause 类型做决策：
- 若最终 cause 是
SocketTimeoutException→ 触发重试或降级提示 - 若 cause 是
IllegalArgumentException→ 记录为客户端输入问题，不告警 - 若 cause 是
OutOfMemoryError→ 立即触发内存快照并终止线程
避免“静默吞异常”导致的问题延迟暴露
很多全局异常处理逻辑会写成：catch (Exception e) { logger.warn("忽略异常", e); }。表面看没崩溃，实则把关键线索抹掉了。
异常链迫使你在包装时必须明确“为什么换这个异常类型”。例如：
- 不能只写
throw new ServiceException("失败")—— 缺少 cause 就等于放弃溯源权 - 正确做法是
throw new ServiceException("用户余额不足", e)，让 cause 携带原始InsufficientBalanceException - 这样即使该异常最终未被捕获，全局处理器也能根据 cause 类型判断是否需紧急介入
与安卓/服务端全局捕获机制形成闭环
在安卓中，Thread.setDefaultUncaughtExceptionHandler 是兜底防线；在 Spring 中，@ControllerAdvice 是 Web 层统一出口。它们的价值高度依赖异常是否携带完整链路：
- 链路完整 → 日志能输出设备信息 + 堆栈 + Caused by 多层嵌套 → 定位从“某处报错”变成“LoginService 第23行调用 PaymentClient 时，底层 OkHttp 抛出 ConnectException”
- 链路断裂 → 所有分析退回人工拼接：查日志时间戳、翻调用链路、比对前后请求参数
- RPC 框架（如 gRPC）若保留 cause，下游服务也能看到原始业务异常，而不是一层层的 StatusRuntimeException
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
