空catch块是异常吞噬的头号元凶，它让异常彻底消失：日志无痕迹、监控无指标、调用方收不到失败信号，导致问题潜伏、状态损坏、排障失能。
空 catch 块不是“稳住程序”，而是主动关掉报警器——异常被彻底吞掉，日志没痕迹、监控无指标、调用方收不到失败信号，问题在生产环境潜伏成灾。
静默吞异常，会让系统“带病运行”
异常是 JVM 发出的明确故障信号，比如数据库连接中断、JSON 解析失败、文件权限不足。一旦写成 catch (Exception e) { }，这些信号就消失了：
- 程序看似继续执行，但状态可能已损坏：订单未创建、缓存未更新、事务未回滚
- 后续逻辑基于错误前提运行，比如对 null 对象调用方法，最终报出更难定位的
IllegalStateException - 用户看到的是“按钮没反应”“页面空白”，而你连哪行代码出错都查不到
线上排障会彻底失能
没有堆栈、没有类型、没有上下文，等于抹掉了所有诊断线索：
- 日志里查不到错误时间、类名、行号，运维只能靠猜路径、加日志、反复重启
- 监控系统错误率显示为 0，但业务成功率实际下滑，告警形同虚设
- Spring 的
@Transactional方法里吞掉异常，事务不会回滚，数据不一致风险陡增 - 异步任务中忽略
InterruptedException，线程中断信号丢失，任务无法被优雅终止
正确记录日志：三要素缺一不可
记录不是目的，可追溯、可决策才是关键。每条异常日志必须包含：
立即学习“Java免费学习笔记（深入）”；
-
有意义的描述性消息：说明发生了什么，而不是“出错了”。例如
"支付回调验签失败"，而非"处理失败" -
关键业务上下文：如
orderId、userId、reqId，用占位符传入，避免字符串拼接 -
完整的异常对象
e作为最后一个参数：确保日志框架自动输出堆栈和 cause 链。写成logger.error("msg", e)，不是logger.error("msg: " + e.getMessage())
示例：
logger.error("订单支付回调验签失败, orderId={}, reqId={}", orderId, reqId, e);什么时候可以不抛出？但绝不能不处理
空 catch 永远不合法。如果确定某异常可忽略（极少数场景），必须同时满足：
- 捕获具体类型，如
catch (FileNotFoundException e)，禁用catch (Exception e) - 添加清晰注释，说明为什么可忽略，例如：
// 忽略：配置文件不存在属于预期行为，使用默认值 - 仍需记录日志，至少用
logger.debug(..., e)留痕，方便未来审计或调试 - 若返回默认值或降级结果，要确保上游能识别失败语义（如 HTTP 返回 503 而非 200）
