绝大多数情况下catch块必须记录日志，但仅限真正处理并终结异常传播路径时；业务异常用warn，系统异常用error并保留完整堆栈；避免重复记录、截断堆栈及异步场景日志丢失。
异常捕获时要不要记录日志
绝大多数情况下，catch 块里必须记录日志，但不是所有 catch 都该记——关键看是否“真正处理”了异常。
常见错误是：捕获后只调用 e.printStackTrace()，或什么也不做（空 catch），这会让问题彻底丢失；更隐蔽的问题是，在多个层级重复记录同一异常，导致日志爆炸且难以定位根因。
- 只在你**明确要处理并终结该异常传播路径**的位置记录日志（例如兜底返回默认值、触发重试、降级逻辑）
- 如果只是做简单包装再抛出（如
throw new ServiceException("下单失败", e)），通常不应在此处记日志，留给上层统一处理 - 使用 SLF4J 时，优先用
logger.error("下单失败", e)而非logger.error("下单失败: " + e.getMessage())—— 后者丢弃了堆栈，且可能触发空指针
哪些异常类型值得单独记录
不是所有异常都值得同等对待。区分「业务异常」和「系统异常」是日志策略的核心。
IllegalArgumentException、BusinessException（自定义）这类通常代表输入校验失败或业务规则拒绝，属于预期内异常，一般用 logger.warn() 级别即可；而 NullPointerException、SQLException、TimeoutException 往往反映代码缺陷或外部依赖故障，必须用 error 级别，并确保堆栈完整。
立即学习“Java免费学习笔记（深入）”；
- 对
RuntimeException及其子类保持警惕：除非明确是业务语义（如InsufficientBalanceException），否则默认按系统异常处理 - 避免把
IOException这类检查异常无差别降级为 warn——它出现在网络/磁盘操作中，大概率意味着真实故障 - 若用 Spring，注意
@ExceptionHandler中的日志位置：全局异常处理器是集中记录的合理位置，但需判断是否已由下层记录过
logback 或 log4j2 中如何避免异常日志被截断
默认配置下，大堆栈（尤其是嵌套多层的 Cause）可能被日志框架截断，导致看不到根本原因。
以 Logback 为例，%ex 或 %xEx 转换符控制异常输出深度：%xEx{full} 强制展开全部嵌套，%xEx{5} 限制最多 5 层。Log4j2 对应的是 %throwable{full}。
- 开发/测试环境建议用
%xEx{full}，确保问题可追溯 - 生产环境若担心日志体积，可用
%xEx{10}，但不要低于 5 —— 多数 RPC 框架（如 Dubbo、Feign）会封装 3~4 层 - 禁用
%ex（不带参数）：它默认只打印最外层异常，极易掩盖真实源头
异步线程和 CompletableFuture 中的日志陷阱
在 CompletableFuture.runAsync() 或自定义线程池中抛出未捕获异常，不会打印到主线程日志，甚至可能静默消失。
根本原因是：这些场景下异常发生在新线程，而默认 UncaughtExceptionHandler 通常只输出到 System.err，不受 SLF4J 控制。
- 为线程池显式设置
ThreadFactory，并在其中为每个线程绑定UncaughtExceptionHandler，用logger.error("async task failed", e)记录 - 对
CompletableFuture，优先用handle()或exceptionally()显式处理异常，而不是依赖whenComplete()（它不区分正常/异常完成） - Spring 的
@Async方法若抛异常，且未配置AsyncUncaughtExceptionHandler，异常将被吞掉——务必重写该 Bean 并接入日志
异常与日志配合最难的不是语法，而是判断“谁该记、在哪记、记多少”。同一个异常在网关层记一次 error，在 service 层又记一次 warn，再在 DAO 层打个 debug，这种叠加不仅浪费 I/O，还会让告警失真。留心调用链路中的日志责任边界，比选对日志框架更重要。
