静默失败是catch块中未记录完整异常信息或未重新抛出，导致业务出错却无感知；典型如空catch、仅打无关日志、printStackTrace()等，引发数据不一致与监控失真。
静默失败长什么样？catch 里空着就完事了
Java 中的静默失败，本质是异常被吞掉了——catch 块里什么也不做，或者只打一行无关痛痒的日志（比如 logger.info("something happened")），连异常类型、堆栈、上下文参数都不留。它不会中断流程，但业务逻辑已经出错：转账没成功、缓存没更新、消息没发出去，调用方却收到“操作成功”响应。
- 典型写法：
try { doSomething(); } catch (Exception e) { }或catch (IOException e) { logger.debug("ignored"); } - 高危场景：异步任务、定时任务、过滤器（Filter）、Spring AOP 切面、Jackson 反序列化回调（如
@JsonCreator） - 后果不是立刻崩，而是数据不一致、下游超时、监控指标失真——等你发现时，可能已积压数小时脏数据
为什么 Thread.setDefaultUncaughtExceptionHandler 抓不到所有静默失败
这个 handler 只管未捕获的异常，而静默失败恰恰是“已被捕获但被丢弃”的异常。它对 try-catch 吞异常完全无感，也覆盖不了 CompletableFuture.supplyAsync 里没 exceptionally() 的情况，更抓不住 Optional.orElseGet() 里抛出却被忽略的 Supplier 异常。
- 真正要监控的是“被捕获但未记录完整信息”的异常点
- JVM 层面无法自动识别“静默”，必须靠代码规范 + 工具介入
- 某些框架（如 Spring WebMvc）默认会吃掉控制器里未声明的异常，返回 500 却不记全栈——这算半静默，比纯空
catch更难察觉
用 Throwable.printStackTrace() 不等于解决问题
有人觉得只要加了 e.printStackTrace() 就不算静默，其实不然。标准错误流输出在生产环境基本不可见，且没有上下文（请求 ID、用户 ID、入参摘要），日志系统收不到，ELK 查不到，告警也触发不了。
- 正确做法：用 SLF4J 等日志框架，带 MDC 上下文，且至少用
logger.error("failed to process order {}", orderId, e) - 禁止在生产代码中出现
System.out或System.err - 注意
logback.xml中%ex配置是否开启——很多团队关了它，导致日志里只有 “java.lang.NullPointerException” 而无堆栈
如何用字节码插桩低成本发现静默点
人工扫 catch 块效率低还易漏，推荐用 Byte Buddy 或 OpenTelemetry Java Agent 配合规则检测：扫描所有 catch 块，检查其 body 是否含日志语句、是否调用 throw、是否包含 rethrow 模式（如 throw new RuntimeException(e)）。
立即学习“Java免费学习笔记（深入）”；
- 开源工具参考：
error-prone的CatchAndLog检查项，或 SonarQube 规则S1166（"Exception handlers should preserve the original exception"） - 关键识别特征：
catch块内不含logger.、不含throw、不含return（除非明确是兜底返回值） - 注意泛型擦除影响：像
catch (final Exception e)和catch (final RuntimeException e)都得覆盖，别漏掉子类捕获
最难的不是找到空 catch，而是说服团队接受“所有异常必须携带至少一个业务上下文字段并进入结构化日志”。这点一旦松动，监控再全也白搭。
