应在最外层或业务边界（如Controller、全局异常处理器）统一记录异常，中间层仅封装抛出或降级处理，避免重复日志；推荐使用logger.error("msg", e)自动打印堆栈，禁用e.printStackTrace()。
在 catch 块中记录日志后直接 throw e 或 throw new RuntimeException(e)，容易导致同一异常被多层 catch 重复捕获、重复记录，最终日志里出现大量重复堆栈。核心问题不是“能不能记录”，而是“在哪一层记录才合理”。
明确异常处理职责：只在最外层或业务边界处记录
异常传播链中，应只由真正“处理”异常的位置负责记录日志——通常是系统入口（如 Controller、main 方法）或明确要兜底的业务边界。中间层 catch 到异常，若不终止流程，就不该打日志，只需按需包装或补充上下文后抛出。
- ✅ 正确做法：Controller 层 catch 并记录；Service 层只抛出或封装，不记日志
- ❌ 常见错误：Service 捕获后
log.error("xxx", e); throw e;，Controller 又捕获并记录一次 - ? 补充上下文推荐用
throw new BusinessException("订单创建失败", e)，保留原始 cause，日志由上层统一输出
用 logger 的 warn/error + 异常参数，避免手动打印堆栈
如果确实需要在中间层记录（如做监控、审计），必须确保不会和上层冲突。关键点是：用 SLF4J / Logback 等标准日志框架的 logger.error("msg", e) 形式，它会自动打印完整堆栈，且不依赖 e.printStackTrace() —— 后者易被多次调用造成重复。
- ? 避免：
log.error("xxx: " + e.getMessage()); e.printStackTrace(); - ✅ 推荐：
log.warn("调用下游超时，降级处理", e); // 不 throw，已降级或log.debug("忽略非关键异常", e); - ⚠️ 注意：warn/debug 级别通常不触发告警，适合中间层“观察性记录”
统一异常处理器接管全局未捕获异常
Spring 等框架支持全局异常处理器（如 @ControllerAdvice + @ExceptionHandler），这是最干净的方案：所有 controller 抛出的异常都会被集中捕获、记录、转换响应。中间 service 层完全不用 try-catch，更无需日志。
立即学习“Java免费学习笔记（深入）”；
- 这样 service 可专注业务逻辑，异常自然向上冒泡
- 全局处理器中用
log.error("API 调用失败: {}", requestInfo, ex)记录一次，精准、无重复 - 配合 MDC 可自动注入 traceId、userId，让每条日志可追溯
必要时用 try-with-resources 或 finally 清理资源，而非靠 catch 记录
有时开发者在 catch 里记日志，其实是想确认“这里出错了”。但更健壮的做法是：把关键动作（如关闭连接、回滚事务）放在 finally 或 try-with-resources 中；日志则留给顶层统一输出。
- 例如数据库操作失败，连接关闭逻辑放 finally，异常本身交给全局 handler
- 避免为“留痕”而在每个 catch 里写日志，那是日志系统的职责，不是业务代码的负担
