空catch块会静默吞掉异常，导致日志无报错、监控无告警、业务逻辑莫名跳过；排查关键在于验证异常是否被丢弃、定位丢弃位置、确认影响范围，并通过日志断层、全局未捕获钩子、静态检查等手段卡死源头。
空 catch 块会让异常彻底消失，日志里没报错、监控没告警、业务逻辑莫名跳过——你根本不知道它曾经失败过。排查核心不是“找代码”，而是验证异常是否被静默丢弃、定位丢弃位置、并确认影响范围。
查日志里有没有异常痕迹
重点不是看有没有 ERROR 日志，而是看关键业务步骤是否缺失日志输出。例如：定时任务本该打印“开始发送消息”，但某天日志里完全没这行；用户提交后无“订单创建成功”日志，也无失败提示。这种“静默跳过”比报错更可疑。
- 搜索关键词如“读取配置”“写入数据库”“调用支付接口”，确认对应成功/失败日志是否成对出现
- 检查异步线程名（如 pool-1-thread-2）或协程 ID 的日志片段，异常若被吞，这部分日志会突然中断
- 对比正常时段与问题时段的日志行数和关键标记点，发现“断层”即可能有异常被吃掉
开全局未捕获异常钩子
Java 中设置 Thread.setDefaultUncaughtExceptionHandler，把所有未处理异常打到独立日志文件。如果问题期间这个日志里完全空白，说明异常不是逃逸，而是被 catch 块主动吞了；如果出现大量异常堆栈，则说明是异步场景中 try-catch 作用域没罩住真正抛出点。
- 在应用启动时注册：
Thread.setDefaultUncaughtExceptionHandler((t, e) -> log.error("未捕获异常: {}", t.getName(), e)); - 特别注意 @Async 方法、线程池 execute 提交的任务、CompletableFuture 的 thenApply 等异步路径
- Spring 事务方法里吞异常，会导致事务不回滚——此时查数据库写入时间戳与日志时间是否错位，可间接验证
扫代码里无效的 catch 块
不是所有 catch 都危险，但以下模式基本等于“主动埋雷”：
-
catch (Exception e) { }或catch (Throwable t) { }—— 没日志、没重抛、没兜底 - try-with-resources 里空 catch：
try (FileInputStream fis = new FileInputStream("x")) { ... } catch (IOException e) { }—— 资源关闭失败也被吞 - @Transactional 方法内 catch 后没抛出，或只 log.info() 不带异常对象参数
- IDE 通常会高亮空 catch 并提示 “Swallowed exception”，别点 ignore
用静态检查工具卡死源头
靠人眼 review 难杜绝，必须进 CI 流水线：
- 在 SonarQube 或 Checkstyle 中启用
IllegalCatchCheck，禁止空 catch 和裸 catch(Exception) - 配置规则：catch 块内必须包含日志记录（log.error + 异常对象）、重抛、或显式注释说明静默理由（如
// 兼容旧版空响应，不影响主流程） - 单元测试覆盖时，故意触发异常（如 mock 文件不存在），验证是否真有日志输出或异常传播
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
