不同日志级别异常记录规范：<code>e</code>与<code>e.getMessage()</code>如何选型

各日志级别对应的推荐方案 #

• log.error()：必须传入完整异常对象e
  error级别用于记录影响业务正常运行、需要人工介入排查的错误，仅靠e.getMessage()完全无法支撑根因定位：比如空指针异常的getMessage()返回值为null，数组越界、类加载异常的报错信息也通常没有上下文链路信息，只有完整的异常堆栈才能明确报错的代码位置、调用链路，快速定位问题。
  正确写法示例：log.error("用户{}支付回调处理失败", userId, e);，SLF4J等主流日志框架会自动识别最后一个异常参数，打印完整堆栈，不需要额外为异常预留占位符。
• log.debug()：优先传入完整异常对象e
  debug级别用于开发调试、测试环境问题排查，本身定位就是输出详细的运行信息，且生产环境默认不会开启debug级别的日志，不用担心堆栈打印带来的日志量膨胀问题，完整堆栈可以大幅提升调试效率。如果是非常明确无需堆栈的简单场景，也可以仅传e.getMessage()。
• log.info()：仅传入e.getMessage()，且不建议用info级别记录异常
  info级别通常用于记录业务关键节点、核心运行指标，生产环境默认开启，随意打印堆栈会导致日志量暴增，占用大量存储资源甚至引发磁盘告警。如果是参数校验不通过、非核心流程的预期内异常确实需要记录，仅传e.getMessage()说明异常原因即可，完全不需要打印堆栈。

异常日志通用规范与经验法则 #

• 所有需要根因排查的错误场景，优先传完整异常对象，不要手动拼接异常信息：手动拼接不仅容易遗漏关键信息，还会产生不必要的字符串拼接开销，也无法输出完整调用链路。
• 生产环境常开的日志级别（info及以上），除error级别外不要打印异常堆栈，避免日志冗余引发性能、存储问题。
• 不要重复打印异常：如果下层逻辑已经打印过异常堆栈，上层捕获后仅需传递业务上下文信息即可，不要重复打印相同堆栈。
• 不要吞异常：捕获异常后完全不记录任何异常信息，等于将问题隐藏，后续出现故障完全无法追溯。
• 打印异常时必须关联业务上下文：打印堆栈的同时要带上用户ID、订单号、请求ID等业务标识，避免出现堆栈却不知道对应哪个业务请求的问题。

内容的提问来源于stack exchange，提问作者Aditya