单子一直显示处理中：交易所订单状态字典、终态判定与卡单归因

下单之后的那几秒钟，是普通用户和交易所系统之间信息最不对称的时刻：你的请求已经离开手机，但你既不知道它进了撮合引擎没有，也不知道它成交了没有，页面上只有一个转动的圈，或者一个灰色的处理中。多数错误操作——重复提交、反复撤单再重下、在四个入口各下一遍——都发生在这几秒。这篇文章把交易所订单状态的基本结构和卡住时的正确动作讲清楚。撰写于 2026 年 9 月，本文为通用机制说明，各平台的具体状态名称与字段以官方接口文档和帮助中心为准，不构成投资建议。

先建立一个概念：一笔订单在系统里是一台状态机。它会从若干起点（新建、已受理）经过中间态（处理中、部分成交、等待风控）走向终态。终态的意思是这个状态不会再自己变了：完全成交、已撤销、已拒绝都属于终态；而处理中、已提交这类状态的定义恰恰是还没走完流程。区分这两类状态之所以重要，是因为所有安全的自动化逻辑——包括你手动操作时的判断——都建立在同一个问题上：现在这个状态是不是终态。是，才有下一步动作；不是，等待和查询就是唯一正确的动作。

处理中卡在界面上不动，通常对应三种位置完全不同的情况。第一种是请求根本没到达撮合系统：网络断在用户侧、网关拒绝了请求，这笔单在交易所的记录里不存在，等于没下过。第二种是请求进了系统但停在撮合之前的排队或风控环节，它在交易所的记录里真实存在，只是还没获得成交回报。第三种是订单其实已经处理完毕，但回报没有送达你的设备——成交了，只是你的界面没收到通知。三种情况的处置方式完全相反，所以不能靠猜。

区分三者的工具不是那个页面，而是三个彼此独立的事实源：当前挂单列表、历史委托和成交记录，以及资金余额变动。刷新这三个列表（网页端重新加载、App 下拉刷新，程序用户直接查订单查询接口）之后：挂单列表里没有、成交记录里有、余额变了，说明其实是第三种情况，单已处理完，什么也不用做；挂单列表里有它，说明单活着，处于正常挂单等待，处理中的只是界面状态标签；三处都没有但余额少了，这是最需要认真对待的一种，立即联系工单并明确说明余额与订单不一致，附时间戳和金额。

这里必须讲幂等。交易所的下单接口普遍支持一个客户自定义标识字段：同一标识的重复请求，系统只受理第一次，后面的重复会被直接拒掉。这是设计出来专门对付网络重试的——你的程序断线重发十次，引擎里只有一笔单。手动操作没有这个保护，所以人在卡单时反复点提交，就是把十次请求当成十个独立订单提交了。普通用户在 Web 端遇到卡单，可以用挂单与成交列表确认之后，只补一次操作；确认之前，任何补点都在制造真实的重复订单。

部分成交的状态最容易读错。一笔五手限价单成交了两手，状态是部分成交，这是中间态：剩下的三手还在队列里，会继续成交。很多人看到状态在变，以为单子出了问题，于是撤单重下——撤单会带走还没成交的三手并且排到队列末尾，损失的是排队位置。正确的读法是：部分成交期间，你的选择只有等待和撤销两个，没有第三种改进选项。想改价格，动作的名称是撤单再重下，代价就是排队位置清零。

对使用接口的读者，还有两个补充事实。其一，状态回报通道不止请求响应一种：多数平台的成交推送走独立的数据通道，主请求超时但推送正常时，推送里带回来的才是权威状态；写程序时应以订单查询接口的返回为准，而不是以任何一次推送或回调为准。其二，交易所对异常事件（宕机、撮合延迟）事后的事故报告里通常会写明受影响的时间窗和处理的订单范围，事后对账时值得拿来和自己的记录做交叉，凡是落在时间窗内的订单，状态都可能有平台侧的补救动作。

归因顺序值得单独背一遍：先看余额，再看历史委托，再看成交记录；三个事实源交叉之前不重试、不撤单重下、不去第二个入口补单。给工单的材料按固定结构写：下单时间（带时区）、交易对、下单金额与价格、订单页截图、余额变动截图。按这个顺序和结构处理，处理中四个字就不再是焦虑来源，只是状态机里一个正常的中间态。

风险提示：交易系统在极端行情下可能出现延迟、超时或状态不一致，任何重试与补单操作都可能造成非预期的重复成交或额外费用。本文仅介绍通用的订单状态机制与排查方法，不构成投资建议，也不针对任何特定平台的实现。接口字段与状态名称请以各平台官方文档为准。