结构化日志Structured Logging

先看见这次登录失败，再让同一 requestId 串起三行

左边是出问题的登录页，右边是这次请求的日志流。重放后三条共用 req-7f2；把密码写成明文时，泄漏标在那一行上。

知识点：固定字段，按一次请求追查

上面的工作台已经演示了核心关系，这里只给可复用的命名。

• ts、level、event、requestId 是筛选键，不是装饰。
• 一次失败要用同一个 requestId 串起开始、校验和响应。
• 密码、token、Cookie 只记字段是否存在；发现明文立刻改写重放。

什么时候用、怎么用

需要在生产里按一次请求追查，或把 Console 里的临时输出变成可筛选证据时用结构化日志。

• 入口：服务端看终端或日志汇聚；浏览器可用 Console 对照同一 requestId。
• 最短路径：触发同一请求 → 按 requestId 筛 → 读 level/event → 确认无明文。
• 不要只打一整句自然语言；字段不稳就无法关联错误追踪和链路追踪。

正反例：同一 422，只改日志能不能串起来

目标都是解释这次空密码登录。差别在于三行能不能被同一个 id 找回，以及有没有泄密。