异常该记录日志当且仅当当前层真正处理了它；若仅捕获后重抛则不应记日志，避免重复污染；已降级、兜底或告警时必须记录并标注上下文，技术异常应抛出或转业务异常，不可恢复错误不应捕获。
异常该不该记录日志，取决于它是否被当前层真正“处理”了
Java里不是所有异常都该记日志。记日志的本质是“留痕”，但只有当异常在当前方法中被决定不再向上抛、而是由本层承担后果（比如降级、重试、返回默认值）时，才需要记录——否则就是重复记录、污染日志。常见错误是：在 catch 块里只写 logger.error("出错了", e) 然后 throw new RuntimeException(e)，这等于既没处理又白记了一条。
- 如果 catch 后直接 re-throw（含包装后抛出），通常不该记日志；让最终捕获并处理它的那一层去记
- 如果 catch 后返回兜底值（如
return Collections.emptyList()）、触发告警、或做业务补偿，则必须记日志，并明确标注“已降级”“已忽略”等上下文 - 对
RuntimeException子类（如IllegalArgumentException），若属于调用方传参错误，通常不记 error 日志，而应记 warn 或直接抛出——避免把客户端错误当成系统故障
哪些异常适合继续抛出，哪些必须当场消化
核心判断标准是「责任边界」：当前类/模块是否拥有修复或决策能力。例如 DAO 层遇到 SQLException，它无法决定重连还是切库，只能抛出；而 Service 层收到这个异常后，可根据业务场景选择重试三次、切换读库、或返回用户“稍后再试”。
- 底层技术异常（
IOException、SQLException、TimeoutException）一般要抛出或转为更语义化的业务异常（如PaymentTimeoutException） - 可预期的业务异常（如
InsufficientBalanceException）应定义为 unchecked 异常并抛出，由上层统一拦截返回友好提示 - 不可恢复的编程错误（
NullPointerException、ArrayIndexOutOfBoundsException）不应被捕获——它们该暴露出来，而不是被吞掉或掩盖
log.error() 里传 Throwable 和不传的区别很大
很多团队用 logger.error("查询失败", e)，却没意识到如果只写 logger.error("查询失败")，堆栈就丢了。但反过来，如果在已经包装过的异常上还传原始 e，会导致重复堆栈，日志里出现两层嵌套的 cause。
- 必须传
Throwable参数才能打印完整堆栈；只传字符串消息会丢失调试关键信息 - 如果做了异常包装（如
new ServiceException("支付失败", e)），log 时只需传新异常对象，不要额外再传原始e - 在异步线程或 Filter/Interceptor 中捕获异常时，注意 MDC 上下文可能未传递，需手动绑定 traceId 再记录
Spring Boot 项目里常见的异常处理陷阱
很多人依赖 @ControllerAdvice 统一处理，却忽略了它无法覆盖所有场景。比如 AOP 切面里抛出的异常、@Scheduled 方法中的未捕获异常、或者 CompletableFuture 异步回调里的异常，都不会进入全局异常处理器。
立即学习“Java免费学习笔记（深入）”；
try {
CompletableFuture.supplyAsync(() -> riskyOperation())
.exceptionally(ex -> {
logger.error("异步任务失败", ex); // 必须手动记日志
return null;
});
} catch (Exception e) {
// 这个 catch 永远不会执行，因为 supplyAsync 是异步的
}
-
@Scheduled方法内必须自行 try-catch，否则异常会被静默吞掉 -
CompletableFuture的异常需用exceptionally或handle显式处理，不能靠外围 try-catch - Filter 中抛出的异常若未被 Spring 的 DispatcherServlet 拦截（如发生在 doFilter chain 之前），也会绕过 @ControllerAdvice
catch 时想清楚：此刻我是问题的终结者，还是只是中转站。多数人错在把中转站当终点站，既记了日志又抛了异常，最后查问题时看到十条重复堆栈，却找不到真正做决策的那一行。 
