绝大多数情况下catch块需记录日志，但仅在异常真正落地或不可恢复时（如Controller入口、定时任务主逻辑）打ERROR日志；避免层层重复打印，应由顶层统一拦截；输出堆栈须用log.error("msg", e)保留完整异常链。
异常捕获时要不要记录日志
绝大多数情况下，catch 块里必须记录日志，但不是所有异常都该在 catch 处打日志。关键看谁负责处理、谁负责上报：如果当前层能完全消化异常（比如重试成功、降级返回默认值），就不该再打 ERROR 级别日志；
throw new ServiceException("查询失败", e)），日志应留给顶层统一拦截，否则会重复打印。
常见错误是层层 log.error("xxx", e)，导致同一异常在日志里出现 3–4 次，堆栈还被截断。建议原则：只在异常真正“落地”或“不可恢复”时记录日志，例如：服务入口（Controller）、定时任务主逻辑、消息消费方法体。
- Web 层用
@ControllerAdvice+@ExceptionHandler统一捕获并记录 - 非 Web 场景（如批处理）在最外层
try-catch记录，内部只抛不记 - 对
RuntimeException子类（如IllegalArgumentException），通常属于编程错误，可设为 WARN 级别，避免刷屏
日志中怎么输出异常堆栈才有效
直接 log.error("msg", e) 是对的，但很多人忽略两件事：一是没保留原始异常上下文，二是堆栈被日志框架截断。SLF4J 默认会输出完整堆栈，但某些旧版 Logback 配置可能启用了 %ex{short}，导致只打第一行。
确保堆栈完整的关键是：始终把异常对象作为第二个参数传给日志方法，而不是拼接 e.toString() 或 e.getMessage()。后者会丢失堆栈和 cause 链。
log.error("数据库查询超时", e); // ✅ 正确：完整堆栈+cause链
log.error("数据库查询超时: " + e.getMessage()); // ❌ 错误：无堆栈，无嵌套异常信息
- 若需自定义堆栈深度（如排除 Spring AOP 代理层），可用
%ex{5}控制行数，但不要设为 0 或 1 - 敏感字段（如密码、token）要在
toString()或日志前脱敏，不能依赖堆栈自动过滤 - 异步线程中抛出异常，需确保日志 MDC 上下文已正确传递（如用
Logbook或自定义ThreadLocal绑定 traceId）
如何区分 ERROR / WARN / DEBUG 日志级别
ERROR 不代表“只要出错就打”，而是表示「系统当前无法按预期完成业务动作，且无有效补救措施」。比如 DB 连接池耗尽、远程服务永久不可达、核心数据校验失败且无法跳过。
WARN 更适用于「异常发生但业务可继续」的情形，例如缓存失效后回源成功、第三方通知回调失败但已进重试队列。DEBUG 则用于定位问题，比如打印 SQL 参数、HTTP 请求头、状态机流转前后的变量值。
- 不要在生产环境开启 DEBUG 级别全量日志，应按包控制：如
logging.level.com.example.order=DEBUG - 避免在循环里打 WARN/ERROR（如逐条解析 CSV 出错），改用计数器 + 汇总日志（“共 12 条记录解析失败，样例：…”）
- 自定义异常类建议覆写
getLocalizedMessage()，方便日志中快速识别语义（如InsufficientBalanceException返回“余额不足，需充值”而非“null”）
日志与异常链路追踪怎么对齐
单体应用里靠 traceId 关联请求和异常就够了，但微服务场景下，异常堆栈里的 Caused by 可能跨服务，原始 traceId 在下游已丢失。这时候光靠日志时间戳对不上。
解决方案是：在异常传播时，把上游 traceId 显式注入到新异常的 message 或 cause 属性中。Spring Cloud Sleuth 已自动支持，但自研 RPC 或 HTTP 客户端需手动透传。
throw new BusinessException("订单创建失败", e)
.withAttribute("upstreamTraceId", MDC.get("traceId"));
- 不要依赖日志时间戳做跨服务问题定位——网络延迟、机器时钟偏差都会导致错乱
- ELK 或 Loki 中检索时，优先用
traceId聚合全部日志，再结合异常关键词过滤 - 若使用
CompletableFuture异步调用，异常默认不传播到主线程，需显式exceptionally()捕获并记录，否则traceId会丢失
log.error("兜底日志", e)。
