"查不到日志"是排障中最令人沮丧的一句话。多数情况下不是没打日志，而是打了但没用：信息不全、级别混乱、关键路径没打、或者被海量无用日志淹没。
一、格式统一：一行一条，结构化
日志应便于机器解析：时间、级别、模块、请求标识、用户标识、消息、必要上下文。使用结构化格式或固定分隔符，避免随意拼接的字符串。
- 时间使用统一格式与时区
- 关键字段固定位置，便于检索
- 请求标识贯穿一次请求的所有日志
二、级别要用对
| 级别 | 使用场景 | 生产环境 |
|---|---|---|
| DEBUG | 调试细节 | 默认关闭，排障时临时开启 |
| INFO | 关键业务节点 | 保留 |
| WARN | 可恢复的异常 | 保留并关注趋势 |
| ERROR | 影响功能的错误 | 保留并告警 |
最常见的错误是把异常都打成 ERROR，导致真正的错误被淹没。错误级别失去区分度，告警就等于噪音。
三、关键节点必须打日志
- 请求入口与出口：参数摘要、耗时、结果状态
- 外部调用：目标、耗时、返回状态
- 数据变更：谁改了什么（关键业务表）
- 异常：上下文信息与堆栈
打日志也要有边界
循环里逐条打印、把整个对象序列化、记录超长响应体——这类日志会快速耗尽磁盘并拖慢系统。日志里只放排障需要的最小信息。
四、绝不能进日志的内容
- 密码、密钥、令牌
- 完整身份证号、银行卡号、手机号
- 完整的请求体中的敏感字段
需要定位问题时，对敏感字段做掩码处理（保留首尾、中间打星）。
五、让日志真正被用起来
规范落地需要三件事：把它写进编码规范、在代码评审中检查、上线后真的用它排过障。一次成功的"靠日志定位问题"的经历，比十页规范更能让团队重视日志。
#日志规范#排障效率#链路追踪#软件事业部
