吞掉异常最直接的后果是故障“消失”却依然存在：日志缺失、监控告警失效、根因被掩盖、开发判断被误导。它让系统看似稳定，实则隐患丛生，破坏可观测性与健壮性。
吞掉异常（Swallow Exception）最直接的后果是让故障“消失”在系统里——它没被记录、没被传播、没被响应，但问题本身依然存在。线上出问题时，你查日志看不到报错，监控收不到指标，告警静默，调用链断在某一层，而业务表现却是“前端没反应”“定时任务停了”“数据突然少了一块”。这不是系统稳定了，是异常被悄悄抹掉了。
日志缺失：第一道防线彻底失守
空 catch 块或只写 e.printStackTrace() 的做法，等于主动关闭了故障可见性入口。生产环境通常不打印堆栈到控制台，printStackTrace() 会落到未知位置甚至被丢弃；而空 catch 连一行日志都不留。结果就是：
- 数据库写入失败，事务却没回滚（尤其在
@Transactional方法中） - HTTP 接口返回 200 + 空响应，前端以为成功，实际后端已抛出
SQLException - 异步线程吞掉
InterruptedException，中断信号丢失，任务卡死无法终止
监控与告警失效：问题从“可感知”变成“不可见”
现代运维依赖异常指标驱动告警（如每分钟异常数突增）。一旦异常被吞：
- APM 工具（如 SkyWalking、Pinpoint）捕获不到异常事件，调用链中标记为“成功”
- ELK 或 Loki 中搜不到对应异常关键词，排查时连怀疑方向都没有
- 自定义告警规则（如 “
ERROR日志含Exception”）完全命中不了
掩盖真实根因：一个错误引发连锁雪崩
异常不是孤立发生的。吞掉一个底层异常，往往导致上层做出错误决策：
- 资源未正确关闭：try-with-resources 的
close()若抛异常，又被外层空 catch 吞掉，原始业务异常和关闭异常双双丢失 - 状态不一致：支付回调中吞掉验签失败异常，后续仍执行发货逻辑，造成钱货不匹配
- 重试机制瘫痪：Spring Kafka 消费者若在业务逻辑里吞异常，容器无法感知失败，不会触发 seek 或重试，消息永久丢失
误导开发判断：把 bug 当功能，把缺陷当流程
当 NullPointerException 或 IllegalArgumentException 被 catch 后静默处理，等于向团队传递错误信号：“这个输入可以忽略”“这个空值是预期行为”。久而久之：
- 参数校验被弱化，防御性编程退化
- 本该修复的逻辑缺陷，被包装成“兼容性处理”长期存在
- 新同学看代码以为“这里就该这么写”，复刻坏习惯
不复杂但容易忽略：异常不是噪音，是系统在说话。让它说出来，比让它安静更重要。
