异常链断裂导致根因丢失，使日志仅剩表层错误：数据库连接池耗尽只报“操作失败”，redis超时被掩盖为“缓存异常”，空指针被隐藏成“数据格式错误”，前端收到模糊500而无法差异化处理。
异常链被切断，最直接的后果就是日志里只剩“表层报错”，原始根因彻底消失。这不是理论风险，而是线上高频踩坑现场。
数据库连接池耗尽却只报“操作失败”
支付中台项目曾出现大批交易超时，日志统一显示 “业务操作失败”。开发在 catch 块里写了：throw new RuntimeException("操作失败");
完全没传原始异常。实际根因是 HikariCP 连接池已满，底层抛出的是 SQLException: Connection is not available。因为异常链断裂，运维查了 4 小时才人工翻到数据库监控发现连接数打满——而只要保留 cause，堆栈第一行就会明确打出连接获取失败的完整路径。
Redis 超时被掩盖成“缓存异常”
某电商商品详情页大量 500，错误日志只有：
“缓存读取异常”
对应代码是：catch (JedisConnectionException e) { throw new ServiceException("缓存异常"); }
真实原因可能是网络抖动、Redis 实例 OOM 或哨兵切换失败。但新异常没带 cause，所有线索归零。后来补上 new ServiceException("缓存异常", e)，再出问题时堆栈立刻暴露出是 java.net.SocketTimeoutException: Read timed out，定位时间从小时级降到分钟级。
文件解析失败却隐藏空指针
一个 CSV 导入功能报 “数据格式错误”，排查时发现是某字段为 null 后调用 .trim() 触发了 NullPointerException。但上游封装方法捕获后只抛：throw new BizException("数据格式错误");
原始 NPE 被吞掉，导致测试反复复现却无法确认是哪一行、哪个字段为空。加上 cause 后，堆栈清楚显示：第 127 行、user.getPhone().trim() —— 根本不用加日志就能直击问题。
前端收到十几种“失败”却不知如何处理
订单、库存、用户模块各自定义异常：OrderException、StockBizException、UserOperationException
每个都只抛无 cause 的新异常，HTTP 响应体里全是模糊的 {"code":500,"msg":"操作失败"}。前端无法区分是库存不足（需提示用户）、还是网络超时（可重试）、或是权限不足（需跳登录）。统一用 BaseException("业务异常", cause) 并规范 code，前端才能真正按类型做差异化交互。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
