假设用户说“导出失败了”，你在后台却只能找到一个 error。为了下次好排查，直接把整个请求、响应和用户输入写进日志，确实容易开始，但以后回答“哪些地方保存了客户数据”就会变难。
OWASP 的日志建议强调事件发生的时间、位置、主体与行为，同时列出不宜直接记录的密码、访问令牌和会话标识等内容。它也要求考虑日志注入、访问控制以及日志失败的情形。这里能推导出的一个产品设计方向，是先定义排障需要回答的问题，再决定字段。
以文件导出为假设案例，我希望知道：失败在哪个阶段，哪个版本发生，是否有相同模式，能否定位服务端的那次处理。一个候选诊断包可以是：event=export_failed、request_id=随机关联标识、stage=render、error_code=unsupported_format、app_version=版本号、duration_bucket=耗时区间、record_count_bucket=数量区间。例子中的所有字段和值都是设计示意，没有来自真实用户日志。
这些字段也不是默认无敏感性。关联标识可能帮助串联用户行为，数量区间也可能暴露业务规模。因此应按排障目的决定是否需要，规定访问角色与保留期限。若确实需要原文件，另走用户明确授权的支持流程，不能因为“方便排错”就自动收集。
实现上我更倾向于字段白名单：只有列入定义的键才能进入诊断事件。单纯删除名字叫 password 的字段，容易漏掉嵌套结构、请求头和换了名字的密钥。白名单仍需检查允许字段中的值，例如异常消息可能夹带原始输入，URL 也可能带查询参数。
验收可以使用假令牌和假邮箱，分别放在嵌套对象、错误消息与 URL 中，检查最终写出的事件；再加入换行、超长字符串、日志目标不可用的场景。结构化输出有助于保持字段边界，但不等于自动完成脱敏，也不能代替容量限制。
这类改动的成果应是“支持人员能凭诊断包定位失败阶段”，而不是“日志越多越安心”。先拿三个假故障走通排查过程，再增加字段，能让收集范围和排障价值一起接受检验。
资料：OWASP Logging Cheat Sheet；持续维护页面，未取得页面更新时间。查阅日期：2026-11-05（Asia/Shanghai）。
来源：https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
