Java异常日志“吞没”本质是规范缺失，须禁用空catch和printStackTrace；应记录带异常对象的日志、分层捕获具体类型、统一异常处理并工具卡点。
Java 异常日志“吞没”问题，本质不是技术难点，而是规范缺失导致的系统性静默。只要让每一条异常在发生时有迹可循、有责可追、有据可查，就能从源头阻断它。
禁止空 catch 和仅 printStackTrace
这两类写法是吞异常最直接的入口：
- 空 catch（catch (Exception e) { }）等于主动屏蔽错误信号，调用方完全无感知
- e.printStackTrace() 输出到 System.err，在容器、K8s、日志平台中基本不可见，且无时间戳、线程名、业务ID等上下文
正确做法：所有 catch 块必须至少做一件事——记录带异常对象的日志、包装重抛、或明确兜底并注释原因。例如：
logger.error("读取用户配置失败，userId={}", userId, e);
立即学习“Java免费学习笔记（深入）”；
强制日志携带原始异常对象
只写 logger.error("失败") 或 logger.error("失败：" + e.getMessage())，都会丢失堆栈和 cause 链，根因无法定位。
关键细节：
- 异常对象必须作为日志方法的最后一个参数传入，如 log.error("msg", e)，才能触发日志框架自动打印完整堆栈
- 避免字符串拼接，防止未达日志级别时仍执行 toString() 或 getter（影响性能且可能抛新异常）
- 敏感字段（如密码、手机号）严禁出现在日志消息或异常 message 中
捕获具体异常类型，禁用泛捕 Exception/Throwable
catch (Exception e) 看似省事，实则把 NullPointerException、OutOfMemoryError、ThreadDeath 全部一锅端，掩盖了本该暴露的严重问题。
应按语义分层处理：
- 外部调用失败 → 单独 catch IOException | TimeoutException，做重试或降级
- 数据库异常 → 捕获 SQLException，根据 SQLState 区分连接中断 vs 唯一键冲突
- 配置缺失 → catch FileNotFoundException，加载默认值并 warn 日志
- 中间层（Service/DAO/Util）禁止出现 catch (Exception e)，CI 流水线应直接拦截
统一收口 + 工具卡点，不靠人盯
靠开发自觉记不住规则，要靠机制落地：
- Web 层用 @RestControllerAdvice 统一处理异常：业务异常转友好提示，系统异常记全栈日志，受检异常映射 HTTP 状态码
- 在 SonarQube 或 SpotBugs 中启用硬性规则：RSPEC-1166（空 catch）、RSPEC-2583（日志缺异常参数）、RSPEC-1149（finally 含 return/throw）
- IDE 配置 Live Template，输入 tc 自动展开为标准 catch 块（含 SLF4J 日志 + re-throw）
- 所有 AutoCloseable 资源必须用 try-with-resources，避免 close() 失败压制主异常
