凌晨两点看线上日志时，屏幕前的人和写下那行代码的人，常常已经不是同一个人。

即使是同一个人，也隔着几个月的时间、不同的上下文和明显下降的耐心。从这个角度看，日志不是程序运行时随手留下的痕迹，而是一封写给未来陌生人的信。

request failed 几乎什么也没说。

一封有用的信至少应该回答：

  • 正在做什么；
  • 对哪个对象操作；
  • 走到了哪一步；
  • 为什么失败；
  • 是否会自动恢复；
  • 下一步应该去哪里找。

我以前会担心日志太多，于是把信息写得很短。后来发现，真正昂贵的不是多占几行磁盘，而是人在故障中重新拼接上下文。

当然，详细不等于倾倒。打印整个请求体可能泄露密码，循环里逐条输出会淹没关键信号，把同一个错误在五层调用栈各记一次也只是制造回声。

我现在更喜欢在边界处记录：任务开始、状态变化、外部调用、重试耗尽和最终结果。内部函数负责返回带语义的错误，由最了解业务上下文的那一层决定怎样写日志。

代码主要服务机器，日志主要服务人。两者都值得被认真设计。