不使用错误码作为唯一信息
别名: 错误码 · 诊断信息 · 技术详情 · 请求 ID
概念解释
错误码（error code）适合日志、支持工单和版本追踪，但不能替代用户可读说明。界面应先说明发生了什么和能做什么，再把代码、请求 ID、时间戳和技术详情放在可展开或可复制区域。这一条和组内前三条不冲突：前三条要求内容、位置、方案三者齐全，这一条补的是"齐全之后，代码该放在哪里"——答案是放在旁边而不是放在正中间。
机制
大多数用户没有错误码对照表，也没有能力从一串哈希式 ID 反推出这次失败到底属于权限、网络还是输入问题——错误码对用户而言是不透明的符号，只有对照内部文档或工单系统才有意义。只显示一个代码，等价于把诊断这件事的成本，从本该承担它的系统和支持团队，转移给了完全没有工具去做这件事的用户。即使是内部人员，跨系统版本升级和本地化翻译也会让同一个代码在不同时期、不同团队里代表不同的含义，这种"漂移"使得代码本身也不是长期稳定的凭证，唯一真正稳定的是与之绑定的请求日志。错误码真正的价值发生在诊断链条的另一端：它是精确检索日志、串联多个系统间调用、把同一次故障在不同团队之间对齐的钥匙，但这把钥匙用户自己打不开锁，用户层需要的是任务事实和下一步动作，代码只是附带的、供别人使用的证据。
边界
技术详情不是任何时候都能公开：堆栈信息可能包含内部路径、主机名或未脱敏的个人数据，直接展示给终端用户是一种信息泄露而非帮助，安全系统应有专门的脱敏策略再决定哪部分可以出现在界面上。面向开发者的高级视图（比如管理后台或调试模式）可以展示更完整的堆栈和原始响应，因为这批用户具备解读能力，此时把代码藏起来反而是过度保护、拖慢了他们的排查速度——这条原则的适用对象是普通任务界面，不是开发者工具。错误码的命名和含义也需要跟着版本走：如果同一个码在两次发版之间悄悄改变了含义而没有同步更新文档，支持团队按旧文档处理新问题会得出错误结论，这个风险比用户看不懂代码更隐蔽也更危险。
怎么落地
- 建立一张错误码到用户文案、恢复动作和支持路径的映射表，作为发布检查项的一部分，随每次版本更新回归测试，防止代码含义漂移而文案没跟上。
- 主信息区只写任务语言；错误码、请求 ID 和时间戳放进可展开的"详情"区域，并提供一键复制。
- 支持表单应能自动附带脱敏后的诊断信息，不要求用户手工抄写代码和时间戳，抄写本身就是一次容易出错的环节。
- 验证办法：用真实的历史错误做回放测试，分别让普通用户、内部管理员和一线支持人员在同一个报错界面上作答，检查三类角色是不是都能从各自需要的层级里拿到答案——普通用户看懂任务后果，支持人员能定位到日志。