H3.02.4error codes as secondary identifiers设计研究
错误码只作为辅助标识
别名: 错误码 · reference id · 诊断编号
概念解释
错误码是给日志、客服和版本追踪对齐同一次事件的标识，不是写给正在恢复任务的人看的主信息。界面先用任务语言说结果、原因和出口，码放在可复制的次要位置。把码当成唯一说明，等于把诊断工作转包给用户。这条不讨论三要素里的前三句怎么写，只讨论码在恢复流程里的地位。
机制
绝大多数人没有码表，也无法从哈希里读出「卡被拒」还是「库存没了」。码出现在主位置时，人会停下来试图解码，恢复被推迟；解码失败就放弃或把码拍给客服，而客服真正需要的是能检索的关联键，不是用户的猜测。码的价值是精确：同一内部原因、同一请求、同一时间切片。它必须稳定、可复制、不携带可被枚举的账户或资源含义。主信息与码分层，才能让不会查表的人走下去，同时让会查表的人一次对上日志。
怎么研究
同一失败下比较：只显示码、只显示任务语言、任务语言加可复制编号。
自变量：码是否占据主文案、是否提供一键复制、客服能否仅凭编号定位事件。 因变量：用户能否不查码完成恢复、把码读成原因的比例、求助时编号被正确带上的比例、支持定位时长。
不要招募内部开发者当「普通用户」去读码，那会把辅助标识测成主信息。开发者工具可以另开一层，但要与主流程分开测。
边界
面向运维的控制台可以把码放得更前，前提是受众有码表且会话已鉴权。安全接口的码不能编码「用户是否存在」或剩余尝试次数。编号若可被遍历拿去查别人的故障，就成了访问凭证，必须无业务语义并限速查询。本地化之后码可以保留英文或数字，但不得成为用户唯一能看到的字符串。
怎么落地
- 主表面只放任务语言和动作；码、请求编号放在「详情」或脚注，提供一键复制。
- 内部原因码映射到公开文案，原始异常只进受控日志；未知码走审核过的兜底句，并告警。
- 求助表单自动附上脱敏后的编号，避免让人手工抄写。
- 验证：普通用户不看码能否走完恢复；支持人员只拿编号能否在授权范围内找到同一事件。两头有一头做不到，码就还在抢主信息的位置，或还不能当标识用。