Java中日志与异常需互补：异常负责结构化错误传播，日志负责记录可追溯的上下文；底层异常不重复打日志，上层捕获后结合业务场景记录WARN/ERROR并带堆栈；日志须含业务动作、关键输入（脱敏）、完整堆栈；按故障严重性分级，杜绝空catch、拼接异常等反模式。
Java中日志与异常的配合，核心在于：异常是“发生了什么”，日志是“什么时候、在哪里、为什么发生”。二者不替代，而要互补——异常负责结构化错误传播和处理，日志负责可追溯、可分析的上下文记录。
异常该抛还是该记？明确分工
不是所有异常都需要记日志，也不是所有日志都要裹异常。关键看责任边界：
- 底层抛出异常时，通常不自行打日志（如JDBC驱动抛SQLException、Jackson解析失败抛JsonProcessingException），避免重复记录；上层捕获后，结合业务上下文决定是否记录
- 主动throw new XxxException()前，若已知是预期外的严重问题（如配置缺失、连接池耗尽），可先打ERROR日志再抛，确保即使异常被静默吞掉，也有迹可循
- catch块里不做任何处理就直接throw e或throw new WrapperException(e)，属于典型日志遗漏——至少应记录WARN或ERROR，并带上原始异常（用log.error("业务操作失败", e)而非log.error("业务操作失败: " + e)）
日志内容必须包含可定位的关键上下文
只记“NullPointerException”毫无价值。一次有效的异常日志应至少包含三要素：业务动作、关键输入、异常堆栈。
- 业务动作：比如“支付回调验签失败”“用户ID=12345查询订单超时”，而不是“服务出错”
- 关键输入：脱敏后的请求参数、订单号、用户ID、接口路径等。避免打印完整request body或password字段
- 异常堆栈：用带Throwable参数的log方法（如log.error(msg, throwable)），让SLF4J/Logback自动输出完整堆栈；切忌e.toString()或e.getMessage()拼接进字符串
按场景选日志级别，避免ERROR泛滥
日志级别混乱会导致告警失真、排查困难。基本原则：
立即学习“Java免费学习笔记（深入）”；
- ERROR：系统级故障、数据不一致、不可恢复的外部依赖失败（如DB连不上、Redis集群全宕）。必须有人跟进
- WARN：异常可恢复但需关注，如第三方接口返回503临时不可用、缓存击穿触发DB加载、金额校验不通过但已拦截
- INFO：正常业务流转的关键节点（如“订单创建成功，orderNo=ORD20240501001”），非异常场景下不用记异常
- DEBUG：仅在开发/排查期启用，用于输出中间状态（如SQL参数、HTTP响应头），上线禁用
避免常见反模式
这些写法看似省事，实则埋下运维雷：
- 空catch + println / log.info(e)：掩盖问题，丢失堆栈，等于没记录
- 在finally里打日志说“执行完成”却不区分成功/失败：无法判断是否真完成了
- 用String.format拼接异常信息再打日志：堆栈丢失，且可能因参数为null导致二次NPE
- 每个service方法开头log.info("enter xxx")，结尾log.info("exit xxx")：噪音大、无业务语义，建议用AOP+注解统一处理
规范不在多，在准——每次打异常日志，问自己一句：运维看到这条日志，能不能在5分钟内定位到代码行、参数值、上下游依赖状态？答案能肯定，才算到位。
