Node.js 小服务日志，先写到控制台也要有格式

2013 年刚开始用 Node.js 写小服务时，很多项目规模不大，大家对日志的预期也很简单：出问题时能在控制台看到几行输出就行。可我后来越写越觉得，哪怕暂时还没有完整日志系统，只是写到控制台，日志也应该先有最基本的格式感。

因为一旦请求多起来、异步回调多起来，没有结构的输出会比没有日志更让人烦。

为什么控制台日志也需要被设计

Node.js 服务最容易遇到的情况是，多条请求交错执行。
如果日志只是一行行随手 console.log，很快你就分不清：

• 哪一行属于哪次请求
• 这条输出是正常流程还是报错补充
• 前后两条日志有没有关系

日志本来是帮你收敛问题的，没有格式时它反而会制造更多猜测。

我后来最低限度会保留哪些信息

哪怕项目很小，我也尽量让一条日志至少带上：

• 时间
• 事件类型
• 关键对象或请求标识

这样做不复杂，但能立刻把日志从“聊天记录”变成“可追踪事件流”。

为什么早期更该养成这个习惯

因为小项目最容易觉得这些事情以后再说。
可真正麻烦的不是以后接日志系统难，而是你已经先养成了什么都随手打一行的习惯。等服务开始稳定运行，历史代码里到处都是不同风格的输出，再统一成本就高了。

我更在意的是一致，不是华丽

日志格式不需要特别复杂，也不一定非要 JSON。
早期阶段最重要的是：

• 同类事件用同一套表达方式
• 错误日志和普通流程日志能看出区别
• 关键信息不要埋在长句子里

只要做到这几条，控制台日志也能很有用。

小结

Node.js 小服务日志，先写到控制台没问题，问题在于不能把“先写控制台”理解成“可以不讲结构”。
日志越早有格式，后面排查问题越不费劲。对异步场景尤其如此，这点节制非常值得。