应记录可预期但不可控的外部异常（如IOException、SQLException），而非NullPointerException等逻辑错误；RuntimeException除非可恢复，否则应抛出并保留异常链；日志仅在全局处理器中记录一次，级别依业务影响而定，且需配置%ex输出堆栈。
该捕获的异常必须记录日志，不该捕获的别硬吞
Java里不是所有异常都适合记录日志。比如 NullPointerException、IllegalArgumentException 这类 RuntimeException，通常是代码逻辑缺陷导致的，上线后应暴露为错误而非静默记录——日志写了也解决不了问题，反而掩盖真实 bug。真正该记日志的是那些**可预期但不可控的外部异常**：如 IOException（文件读写失败）、SQLException（数据库连接中断）、HttpClientErrorException（第三方接口返回 4xx）等。
实操建议：
- 在 service 层或 gateway 层捕获受检异常（
Exception及其子类，但非RuntimeException），用log.error("msg", e)记录完整堆栈 - 对
RuntimeException，除非你明确知道它是业务可恢复的（比如某次重试失败），否则不要catch，让它向上抛出甚至触发全局异常处理器 - 避免在 DAO 层或工具方法里用
log.warn吞掉SQLException后返回 null——调用方无法区分“查无结果”和“查崩了”
继续抛出时要保留原始异常链，别用 throw new RuntimeException(e.getMessage())
常见错误是把原始异常“降级”成新异常，丢掉堆栈和类型信息。比如这样写：throw new RuntimeException(e.getMessage())，会导致上层完全丢失出错位置、SQL 语句、HTTP 状态码等关键上下文。
正确做法是：
立即学习“Java免费学习笔记（深入）”；
- 用带 cause 的构造函数：
throw new ServiceException("订单创建失败", e) - 如果只是透传，直接
throw e（针对受检异常需声明 throws） - Spring 项目中，优先用
@ResponseStatus或全局@ExceptionHandler统一处理，而不是每层都 try-catch-rethrow
日志级别不能一概而论：error 不等于“要告警”
很多团队把所有 catch 都打 error 级别，结果监控系统天天告警，最后没人看。实际上是否该告警，取决于异常发生的**业务影响面**和**可恢复性**。
判断参考：
-
error：影响主流程、不可自动恢复（如支付扣款时银行接口超时且无降级）、需人工介入（如库存扣减失败导致订单状态不一致） -
warn：可降级或重试成功（如查询用户头像 CDN 失败，回退到默认头像）、不影响核心路径（如埋点上报失败） - 绝不用
info记录异常——它不包含堆栈，查问题时毫无价值
全局异常处理器里别再手动记录一遍日志
Spring Boot 的 @ControllerAdvice + @ExceptionHandler 是集中处理异常的好地方，但容易犯一个重复劳动的错误：在 controller 里已经 log.error 过一次，又在全局处理器里再记一次。
推荐结构：
- controller/service 层只负责「识别异常并包装业务语义」，例如：
throw new OrderException("库存不足", e) - 全局处理器统一做三件事：记录日志（仅此处记一次）、设置 HTTP 状态码、返回标准化错误体
- 确保日志格式包含 traceId、method、path、异常类名、message —— 堆栈在
log.error(msg, e)里自然输出，不必额外 toString()
最常被忽略的一点：日志框架（如 Logback）的 %ex 模式必须显式配置，否则即使写了 log.error("", e)，控制台或文件里也看不到堆栈。
