日志里该写什么：能定位问题，也守住隐私

日志的价值在于帮助回答发生了什么，而不是尽可能复制每个请求。未经选择的请求体、请求头和异常对象，可能把密码、令牌或个人信息带进另一个更难管理的数据集合。

本篇目标： 为一个通用读取接口设计最小可用日志，并检查它是否会泄露无关内容。

从需要回答的问题出发

定位一次失败，通常需要知道事件类型、关联标识、开始时间、耗时、结果和经过控制的错误类别。关联标识用来串起同一操作的多个阶段，不应该直接使用用户的凭据或敏感标识。

{
  "event": "catalog.read.finished",
  "requestId": "demo-request",
  "durationMs": 184,
  "outcome": "timeout",
  "attempt": 2
}

这是独立构造的示意记录。它已经能说明一次读取在哪类问题上结束，无需保存完整请求头和业务内容。

在日志入口显式挑选字段，比把整个对象输出后再用正则替换更可靠。对象层级会变化，字段别名也会变化，事后遮盖很难保证覆盖所有路径。

错误对象也需要处理：对用户返回稳定错误码与可理解说明；对运维保留必要堆栈，但审查 URL、查询参数和第三方响应是否包含敏感值。无法保证安全的原文，应放在受控的专门流程里，而不是默认进入普通日志。

同一种事件尽量使用相同字段名、单位和结果枚举。耗时统一为毫秒，时间统一为明确时区，避免同一个字段有时是数字、有时是带单位文本。

记录开始与结束时，明确哪些请求可能只有开始记录。进程异常退出、取消或采样，都可能造成不完整配对，不能把缺少结束日志直接理解为仍在运行。

使用含有虚构口令、邮箱和长文本的测试输入，走过成功、校验失败、超时和异常分支，然后搜索日志确认这些原始值没有出现。再确认保留下来的事件仍足以追踪问题。

最后明确谁能读取日志、保留多久、如何清理以及备份是否遵守同样边界。能够被找到的线索才有价值，不该留下的内容则应从记录入口就被挡住。