日志经常被当成附属品：代码写完了，随手打几行。等线上出问题时，大家才发现日志要么太少，要么太吵，要么只有一句“failed”，没有任何能帮助定位的信息。

我更愿意把日志看成写给开发者和运维人员的产品功能。它的用户不是终端用户，而是未来那个在凌晨排查问题的人。既然是产品功能，就应该考虑使用场景：谁会看它？在什么情况下看？需要用它回答什么问题？

一条好日志通常包含三个部分：发生了什么、相关上下文是什么、系统接下来怎么处理。比如只写“支付失败”价值有限；如果能带上订单号、支付渠道、错误码、重试状态，就能明显减少排查成本。

日志也不是越多越好。噪音太大的日志会掩盖真正重要的信号。普通流程可以用 debug 或 info，异常路径要有清晰的 warn 或 error。真正需要报警的错误，更应该和监控指标配合，而不是指望人一直盯日志。

还有一个容易忽视的点：不要在日志里泄露敏感信息。密码、token、完整身份证号、银行卡号都不应该直接出现。日志一旦进入集中系统，传播范围通常比业务数据库更难控制。

好的日志能让系统在出问题时保持可解释。它不能替代测试和监控，但它能显著缩短从“知道坏了”到“知道为什么坏了”的距离。