最常见的错误是什么都打成 ERROR。如果所有东西都是错误，错误信号就没有意义了。

• INFO ：有意义的业务事件或状态变更。用户下单、服务启动、定时任务执行完成。
• WARN ：非预期但已被妥善处理的情况，可能需要关注。第三方接口超时后重试成功、配置项使用了默认值。
• ERROR ：确实需要人工调查的故障。数据库连不上、数据损坏、未捕获的异常。
• DEBUG ：详细的排障信息，线上环境默认关闭。

关键原则：预期会发生的事件不应该打 ERROR。用户输错验证码、下游返回业务校验失败、第三方拒绝请求（因为参数不对），这些都是正常业务逻辑的一部分，记录日志可以，但不该打 ERROR。把预期内的业务失败也打 ERROR，告警系统就会失效，值班工程师也逐渐不再信任告警。

一条日志有没有用，取决于它能不能回答这几个问题：发生了什么、在哪发生的、是预期还是异常、有多严重、工程师接下来该查什么。

好的日志上下文包括：

• 请求 ID 或 trace ID
• 操作名称（如"支付授权"）
• 服务名称和环境
• 涉及的外部依赖
• 失败原因或错误码
• 关键业务标识（订单号、用户 ID）

看两个例子对比：

• 差： Error occurred
• 好： Payment authorization failed for orderId=84219, provider=stripe, reason=card_declined, retryable=false

后者有价值，是因为它把事情说清楚了：哪笔订单哪个环节出了什么问题，工程师看到这条日志可以直接判断怎么处理。

上下文有用，但不是什么东西都能往日志里写。以下内容不应该出现在日志中：

• 密码和 token
• 完整的信用卡号
• 个人身份信息（身份证号、手机号、地址）
• 敏感的业务 payload

记了不该记的东西，轻则违反合规要求，重则数据泄露。判断标准：这条日志如果被第三方看到了，你会不会紧张？

这是区分日志级别的核心。很多告警系统在这件事上跑偏了。

业务失败（预期内的） ：信用卡被拒、密码输错、404（资源不存在）。这些是产品流程中的正常分支，用 INFO 或 WARN 记录，配业务元数据用于分析即可。不需要告警。

系统故障（非预期） ：超时、未捕获异常、依赖服务中断、数据损坏。这些需要打 ERROR 并触发告警。

两者的本质区别：前者是你的业务逻辑主动返回的"不行"，后者是你的系统"本不该这样"。监控应该把工程注意力引向真正出了问题的地方，而不是业务上不顺的地方。

过度记录是日志系统退化的最快路径。每个函数调用都记、每个循环迭代都记、每个状态变更都记。那真正有用的信息就会被淹没。搜索变慢、仪表盘变乱、存储成本上升。

加日志之前问自己：

• 排障时我会搜这条日志吗？
• 它记录的是有意义的状态变更或决策点吗？
• 这条日志帮回答"发生了什么"吗？

如果答案都是否，就不该记。

最后几条实操建议：

• 统一格式 ：所有日志用相同格式输出，方便解析和查询
• 结构化日志 ：用 JSON 等结构化格式替代纯文本，比用 grep 搜字符串可靠得多
• 人类可读的 message ：结构化的字段留给机器处理，日志正文还是要让人一眼看懂
• 关联 trace ID ：跨服务的调用链靠 trace ID 串联，没有这个标识分布式排障基本靠猜
• 定期清理噪声 ：像重构代码一样定期审查日志，删掉那些已经没用的、过于聒噪的

好的日志只记录重要的事情，而且要说清楚。用正确的级别、带上足够的上下文、区分预期失败和真故障。日志是系统和运维人员沟通的渠道，它不是代码的附属品。

这篇文章列的都是基础原则，不算新鲜。但偶尔翻出来对照一下清单，看看有没有跑偏的地方也不错。