状态码的三种语言：成功、失败与中间态

状态码看起来只是几个词，但它背后是三种完全不同的语言：一种说结论，一种说拒绝，一种说还没完。混着读，系统动作就会错位。

三类的划分与对应动作

中间态最危险的地方在于它看起来像失败。把处理中当成失败，就会触发本不该有的重试或补偿；把中间态当成成功，则会让业务提前推进。唯一正确的动作是：按约定间隔查询，直到状态进入终态。

把所有失败塞进同一个处理分支，要么淹没在无效重试里，要么错过需要人工介入的信号。

状态码描述的是「这次调用的处理结果」，业务结论还需要补充三个信息：这笔钱到了哪个账户、凭证编号是什么、后续可能发生哪些变化（退款、分账）。状态码是入口，不是终点。

在系统里为每一类状态码写清楚默认动作，并让所有模块共用这一份映射。分散在各处的 if 判断，迟早会因为口径不一致而互相矛盾。

把「没收到成功」等同于「已经失败」，是状态码处理里最危险的一次跳跃。

返回状态码是最容易被完整保留下来的信息，也是事后复盘的抓手。记录时建议连同下面几项一起留存：

状态码面向系统，不面向人。直接把内部码展示出来，既无法帮助用户理解发生了什么，也可能暴露不必要的实现细节。正确的做法是把码映射成人能读懂的描述，并给出下一步可以做什么。

并不是所有失败都值得重试，重试的前提是判断这次失败有没有可能自己变好。

不加区分地统一重试，是把一次失败放大成一批失败的最快方式。

状态码的处理水平，往往能反映一个系统对异常的关注程度。把三类语义分清、把中间态单独对待、把结论写进记录，这三件事做到，就足以躲开大多数由误判引发的问题。