错误处理排障的证据留存

错误处理排障的证据留存

排障最怕两种日志：一种只写“处理失败”，看不出失败发生在哪；另一种把请求、响应和环境全部打印出来，虽然信息很多，却夹带用户内容和凭证。可用的证据需要在两者之间取一个清楚的边界：足以还原处理阶段，但不收集与定位无关的数据。

我会先给错误定义稳定类别，而不是把底层报错字符串直接当接口。解析配置失败，可以指出字段和阶段；不需要把整份配置写进日志。

return Err(AppError::Parse { field: "config" });

错误类型由代码表达后，上层可以决定怎样显示、是否重试和记录什么。底层错误仍可作为 source 保留给受控环境中的调试，但对外响应只使用稳定的错误码和简短说明。这样既保留上下文，也不会让库升级后的字符串变化破坏调用方判断。

一条证据链应该包含什么

一次操作分配随机请求标识，入口日志记录版本和开始阶段，后续解析、外部调用和结果交付沿用同一标识。每个阶段只记录状态、耗时和已审核的错误类别。若任务跨进程，关联标识随协议传递；如果经过不可信边界，则重新校验格式，避免用户自行构造的值污染日志查询。

时间线比孤立堆栈更重要。出现错误时，要知道之前经过了哪些阶段、是否重试、用户是否取消、依赖返回了什么类别。堆栈适合定位代码位置，却无法单独说明输入条件和外部状态。二者关联起来，才有机会复现。

最小复现要脱离真实用户数据

排查确认某类输入会触发问题后，我会把它缩成不含业务内容的最小样例。敏感字段用具有相同格式的占位符替换，同时保留编码、长度类别或缺失状态等与错误有关的条件。替换后必须再次触发问题，否则这份样例只是看起来相似，并不能作为复现证据。

原始响应、堆转储和完整追踪可能含有正文或令牌，只在权限受控的位置查看，并按既定期限清理。向协作群或问题单分享时，优先贴脱敏摘要、错误类别和复现步骤，不直接上传整个归档。需要别人访问原始材料时，单独授权并记录用途。

验证修复时保留同一条件

修复后先运行最小复现，确认错误不再出现，再跑相邻的正常和边界用例，防止只是把输入拒绝得更早。若问题涉及异步时序，还要固定可控的延迟或事件顺序，避免一次没有复现就宣布完成。版本、配置和测试输入与修复前保持一致，之后再单独验证新环境。

日志数量增加不等于证据更完整。高频重复错误可以聚合计数，保留少量带上下文的样本；无法驱动处理的字段则删掉。每次复盘最后应能回答：错误在哪个阶段发生，依据是什么，怎样稳定复现，修复后用什么测试防止回来。回答不了的部分就明确标成未知，等新的证据出现后再继续判断，不用猜测补齐。