日志控制台：等级、requestId 与脱敏
点动作生成一次请求的结构化日志，换等级筛选，再点「记录密码」看一条明文会留下什么后果。每条日志都是只追加的事件记录。
在哪看日志：应用把日志写到 stdout / 日志文件 / 可观测平台——先打开接收端，再用 requestId 检索一次请求。
请求日志（只追加 · 最新在上）当前 requestId：
—还没有日志 — 点「开始一次请求」生成第一条结构化日志。
还没有日志 — 点「开始一次请求」生成第一条结构化日志。
四个要点：等级、结构、关联、脱敏
面板里刚操作过的东西，命名成四条规则。
- 等级要对：DEBUG 开发细节、INFO 正常路径、WARN 可恢复异常、ERROR 需调查或告警。404 是客户端误请求，记 INFO/WARN，不是 ERROR。
- 结构化而非自然语言：字段（requestId、userId、durationMs）让日志可被机器检索和聚合，一整行话只能 grep。
- requestId 串请求：一次请求穿过入口、缓存、数据库和下游服务，用同一个 requestId 把多条日志连成一条可追的链。
- 永不写秘密：密码、令牌、Cookie、完整 PII、卡号不进日志；错误摘要只留可公开的关联 ID。
什么时候用
日志解决的是事后追查，不是实时展示。
排查失败、合规审计、监控告警的根因都靠日志。不适合把日志当业务数据库（用事件表/埋点）， 也不适合在生产里用 print 调试一次性问题（用 console 或断点，验完即删）。 日志不是越多越好，而是每一条都能让人或告警做出判断。
怎么用
从开始到能追查一次失败的最短路径。
- 中间件给每次请求注入 requestId，并透传给下游服务和 traceId。
- 在入口、依赖调用、错误分支、响应四处写结构化日志，字段名稳定。
- 失败时按 requestId 检索整条链路；敏感字段在日志层统一脱敏或不记。
正反例：同一笔登录失败
只改一个关键选择：要不要把密码写进日志。
反例
ERROR login failed · password=Tr0ub4dor把密码写进 ERROR：泄漏敏感明文，又没有 requestId/字段，无法定位是哪次请求、哪个用户。
正例
WARN { "requestId": "req_7f2", "userId": "u_1242", "reason": "bad_credentials", "durationMs": 89 }等级恰当、字段结构化、可按 requestId 串链路，且不含任何敏感明文。
快速自测
某接口被请求了一个不存在的资源、返回 404。这条日志的等级和内容最合适的是？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。