空 catch 块会吞噬异常导致问题不可见，应记录日志、明确静默理由或抛出异常，配合静态检查工具拦截。
空 catch 块会让异常彻底消失
Java里写了个 catch (Exception e) {}，看起来“稳住了”程序不崩溃，实际是把错误信息、堆栈、上下文全吞了。线上出问题时，日志里没报错，监控没告警，业务逻辑莫名跳过某步——你根本不知道它曾经失败过。
常见现象：定时任务某天突然不发消息了；用户提交表单没反应但前端没报错；数据库写入偶尔丢失但事务没回滚。
- 异常对象
e一离开catch作用域就被 GC，连日志都来不及打 - IDE（如 IntelliJ）默认会高亮空
catch并提示 “Swallowed exception”，但很多人直接点 ignore - Spring 的
@Transactional方法里吞异常，会导致事务不回滚（因为 Spring 只对未捕获的异常触发 rollback）
怎么改才不算“吞”，又不至于炸锅
不是不能捕获异常，而是必须做有意义的处理。空块不行，但盲目 e.printStackTrace() 也不行——它输出到 System.err，线上环境通常没人看。
- 优先用日志框架记录：
log.error("订单支付回调验签失败", e)（注意：e要作为参数传入，不能只打字符串） - 如果真要“静默处理”，得有明确理由和注释，比如：
// 兼容旧版客户端空 body，忽略 IOException，不影响主流程 - 对可预期的异常（如
NumberFormatException），应提前校验或用更安全的方式转换，而不是靠catch补救 - 绝不吞掉
RuntimeException子类（如NullPointerException、IllegalArgumentException），它们往往暴露代码缺陷
try-with-resources 和空 catch 一起用更危险
资源自动关闭本身依赖异常传播机制。如果在 try 块里抛异常，又在 catch 里吞掉，资源可能没关干净，还掩盖了真正的关闭失败原因。
立即学习“Java免费学习笔记（深入）”；
示例：
try (FileInputStream fis = new FileInputStream("config.txt")) {
// 读取逻辑
} catch (IOException e) {
// 空块 → fis.close() 抛的异常也被吞了
}-
try-with-resources底层会在finally块调用close()，若该调用也抛异常，会压制try块里的原始异常 - 空
catch让压制关系完全不可见，你既看不到原始错误，也看不到资源关闭失败 - 正确做法：要么不捕获，让异常向上抛；要么捕获后至少记录，并考虑是否需要主动
close()或标记资源状态
CI/CD 里加一道卡口比靠人盯更靠谱
靠开发自觉不写空 catch 不现实。很多团队在线上翻车后才想起这事，但那时已经晚了。
- 用 SonarQube 规则
S1181（"Exception handlers should not be empty"）或 Checkstyle 的EmptyCatchBlock检查 - Gradle 中可配
checkstyle插件，在build阶段直接失败：checkstyleMain { exclude '.*Test.*' } - 注意绕过方式：有人写
catch (Exception e) { /* ignored */ }，这种注释式“伪处理”也要被规则识别并拦截
最麻烦的不是语法层面的空块，而是那种“看似处理了，实则没留线索”的变体——比如只记了一行 log.info("failed") 却没带异常对象和关键变量值。排查时你得靠猜，而生产环境最不缺的就是巧合。
