日志脱敏到满屏星号后，怎样还保留排错线索？

可以把原则定成：只保留回答当前问题必需的结构，而不是尽量保留原日志。通常值得保留的是事件先后、相对时间、错误码、组件名、调用阶段，以及同一对象在本帖内是否重复出现；绝对时间可以整体平移。凭据、会话信息、请求正文、完整查询参数和无关环境变量应直接删除，不要只做格式替换。高风险字段连长度区间也不建议留，因为长度和前后缀本身可能缩小猜测范围。

稳定占位符最好由一次性的随机映射生成，发布后销毁映射，不要直接对原值做无盐哈希，低熵账号或主机名很容易被枚举。发布前可以做两道检查：先用规则扫描常见敏感字段和异常长字符串，再让一个不了解原值的人只看脱敏稿，尝试推断身份、地址和凭据；同时给排错者一个明确问题，看他能否仅凭这份日志判断失败阶段。前者仍能反推就继续删，后者无法判断就只补与该问题直接相关的结构。

我觉得可以把脱敏分成“诊断目标”和“泄露风险”两步，而不是先规定哪些字段一律保留。发布前先写一个可验证的问题，例如“能否判断失败发生在哪个边界、同一请求是否经过重试”；只为回答它生成最小日志切片。请求和响应正文、凭据、完整参数、租户或业务标识默认删除；需要关联时只生成本帖一次性的事件编号，按调用链保留父子关系，时间改成相对值通常就够了。

检查最好做盲测：让不了解原文的人只看脱敏稿回答预设的排错问题，同时列出他能推断出的身份、网络拓扑或业务行为。前者答不出，说明结构删过头；后者能推断出不该公开的信息，说明还要继续删。规则扫描可以兜底，但不应当单独作为通过依据；遇到无法识别的字段或解析异常时，发布流程应默认拦截。

还有一个容易漏掉的点：稳定占位符虽然隐藏了原值，却会保留频率和共现关系。样本很小时，某个只出现一次的用户占位符加上一条少见错误码，仍可能被熟悉系统的人认出来。发布前可以专门找低频组合，必要时把它们合并成更粗的角色，或删掉与当前排错问题无关的事件。

关联关系也不必全留。如果只需判断同一请求是否跨组件重试，就保留一次性的请求编号即可，不必同时保留用户、主机和路径之间的对应。一个简单门槛是：每条保留下来的关联都要能说明它具体回答哪个诊断问题；说不出来就删。

比起在原始文本上不断做替换，我更倾向于先把日志解析成结构化事件，再按允许字段重新生成一份公开稿。这样新出现的字段、解析失败的行和自由文本都默认不输出，不容易因为规则没跟上就漏过去。堆栈也要单独处理：保留异常类型和调用层级，源码绝对路径、函数参数、动态查询内容、构建目录直接删；行号只有能对应公开版本时才值得留。

发布前还可以做一次差分检查：公开稿里只允许出现预先定义的字段和占位符，任何无法归类的片段都让流程失败。再用相同错误路径生成一份合成日志，如果合成样本已经足够定位问题，就没必要公开真实业务样本。

相对时间也不一定安全。若外部同时能看到状态页或告警截图，一串精确到毫秒的间隔加上少见错误码，可能把脱敏稿重新对应到某次事件。只需要看先后顺序时，时间可以直接改成阶段编号；需要分析超时时，再按足够粗的区间分桶，比如 小于 100ms、100ms 到 1s、大于 1s，不必保留原始间隔。

发布前还可以把脱敏稿和已经公开的状态信息对照一次，看看能否仅凭时间模式、版本号或错误组合锁定具体事件。能锁定的话，即使单个字段都通过了扫描，整体仍然需要继续降精度。

补一个版内建议：公开稿先写清只要回答的一个诊断问题；如果合成日志或阶段编号已经够用，就不要公开真实样本。必须用真实日志时，按字段白名单重建，默认删掉自由文本、凭据、会话和业务标识、精确时间，以及能和外部公开信息对上的版本与错误组合；解析失败或无法归类的内容直接不发布。发布前做两次反向检查：不了解原值的人能否回答诊断问题，能否仅凭公开状态或告警资料锁定具体事件。任一项过不了，就继续降低精度。这样比逐字段替换更容易复核，也能明确这份日志的适用边界。