日志是写给三个月后的自己的

凌晨排查线上问题，翻了两千行日志，没有一行告诉我"这笔订单为什么失败"。有感而发，给团队定了三条日志纪律。

第一条：每条日志都要带上下文。"处理失败"这种日志等于没写。至少带上：谁（用户/订单标识）、在哪（模块/方法）、为什么（错误码或异常摘要）。理想状态下，光看这一行日志就能还原现场，不需要再翻别的。

{"ts":"2026-08-15T14:03:21+08:00","level":"ERROR",
 "svc":"order","trace":"a1b2c3","order":"SO-20260815-0042",
 "msg":"payment callback rejected","reason":"dup_txid"}

第二条：分清日志的受众。INFO 是给"了解系统在干嘛"的人（关键节点、状态变化）；WARN 是给"关注异常趋势"的人（重试、降级、接近阈值）；ERROR 是给"要动手修"的人（必须处理）。分级错位的典型症状：ERROR 满天飞导致真错误被淹没。我的标准：ERROR 出现必须触发人工动作，否则降级成 WARN。

第三条：结构化，别拼字符串。JSON 格式的日志才能被采集系统按字段检索——"过去一小时某订单的所有 ERROR"这种查询，拼字符串的日志永远做不到。

附赠一条反模式清单：循环里打 DEBUG（量爆炸）、把敏感字段打进日志（合规事故）、catch 了只打日志不再抛出（异常被吞）。这三样在 code review 里见到一次拦一次。

日志不是越多越好，是越能回答问题越好。写之前想一下：三个月后排查问题的自己，看到这行能省几分钟？