交易接口的完整生命周期：从提交到终态要经过哪些状态

一笔交易从提交到落定，并不是一个动作，而是一条状态链。理解这条链上的每个环节，比记住任何一次返回结果都更重要——因为返回结果只是某个瞬间的快照，状态链才是全貌。

状态链的完整样貌

把常见过程展开，一条交易通常会经过下面几个状态：

状态链是单向的：已提交不会退回草稿，处理中不会回到已提交。这个约束看起来是限制，实际上是保障——正因为状态只进不退，重复处理与状态回滚才有了明确的判据。如果系统里存在「状态回退」的可能，每一次重试都要重新判断历史是否可信，复杂度会成倍上升。

已成功、已失败、已关闭属于终态，它们的共同特征是：不再变化，可以作为对账与结算的依据。处理中、待确认属于中间态，它们只说明「还没到下结论的时候」。把中间态当终态使用，是状态处理里最常见的错误来源。

受理环节回答的是「这次请求是否合规」，交易环节回答的是「这笔资金是否完成流转」。两个环节可能相隔数秒到数分钟，在中间态里的任何判断，都应该以主动查询得到的最新状态为准。

把这条链画在纸上只需要十分钟，但它会在后续的每一次讨论里节省大量沟通成本——因为所有参与方开始用同一套词汇谈论同一件事。

状态回答「现在在哪一步」，时间戳回答「什么时候到这一步的」。只记状态不记时间，事后就无法还原过程：一笔交易在处理中停留了三秒还是三小时，对应的处理思路完全不同。

状态机不是文档里的示意图，而是系统里可执行的一组规则。画在纸上的状态链只能帮助理解，写进代码的状态链才能真正约束行为。

真实系统里，状态并不总是沿着主链走完。下面三类异常分支需要提前想清楚处理方式，否则一旦出现就只能靠人工兜底。

这三类分支的共同点是：它们都不适合用「再等等看」来解决。把每一种异常对应到一个明确动作，状态机才算真正闭合。