miniQMT下单接口返回订单编号，不代表委托一定已经被交易柜台接受，更不代表订单已经成交。订单编号更像一张“查询凭证”，说明程序已经生成了可跟踪的请求，后续还要通过委托回报、错误回调或主动查询确认真实状态。

这是自动交易里最重要的基本概念之一。信号只是策略决定做什么，订单编号说明系统已经受理了一个下单请求，委托状态说明订单目前处于哪个阶段，成交回报才代表账户持仓真正发生变化。把这几层混在一起，是重复下单和持仓错乱的常见原因。

同步下单时，如果接口直接返回负数，通常说明请求在较早阶段就失败了，可能是连接、参数、账号或客户端状态异常。返回非负订单编号，说明请求进入了后续流程，但仍可能因为价格、数量、权限、交易时间或柜台规则变成废单。

异步下单则会先返回请求序号，随后通过异步回调得到对应订单信息。请求序号与订单编号也不是同一个概念。程序需要把两者关联起来，避免收到回调后不知道它属于哪次下单。

拿到订单编号后，至少要做三件事。第一，监听on_stock_order，观察订单状态变化；第二，监听on_order_error，获取失败原因；第三，在必要时使用订单编号主动查询。回调提供及时信息，主动查询用于重启和异常后的兜底。

委托状态可能经历未报、待报、已报、部分成交、已成、已撤或废单。只有已成和部分成交会改变持仓数量。已报只是订单进入市场等待，可能长时间没有成交；废单则表示本次订单无效，不能继续按原计划更新持仓。

例如，策略计划买入一千股，下单后立刻把本地持仓变量加一千。如果订单最终废单，本地记录就与真实账户不一致；如果只成交三百股，本地仍会高估持仓。正确做法是根据成交回报更新数量，或重新查询账户持仓。

订单编号还应写入日志，并保存策略名称、股票代码、方向、数量、价格和备注。出现问题时，才能从订单编号追溯到具体信号。多策略运行时，更不能只保存一个“最后订单”，否则不同策略会相互覆盖。

若拿到订单编号却在委托列表中暂时查不到，可以稍等片刻，结合回调判断。主动查询和主推消息在时间上可能有短暂先后差异。此时不要盲目重试，更不能因为列表为空就再次发送同样订单。

程序重启后，本地订单对象可能丢失，但柜台订单仍然存在。应根据当天委托和成交恢复状态，而不是只依赖上次保存的编号。订单编号是重要线索，却不是账户状态的唯一来源。

实盘程序可以把订单状态分为“处理中”和“终态”。待报、已报、部分成交属于仍需跟踪；已成、已撤、废单属于阶段结束。只要订单尚未进入终态，就应谨慎发送同方向新订单。

策略可以为每笔订单建立状态机：创建请求后标记为等待回报，收到订单编号后标记为已受理，委托已报后进入市场等待，收到成交后更新数量，进入终态后才允许同方向新订单。这样比只用一个布尔变量“是否下单”更可靠。

如果订单编号长期没有对应状态，应触发人工检查，而不是一直占用等待列表。任何自动恢复都要基于真实查询，不能简单把本地状态清空后重新下单。

若采用异步下单，程序还应保存请求序号。异步回调返回时，通过序号找到原始信号，再记录真正的订单编号。这样即使短时间内发送多笔订单，也不会把回报对应错。没有映射关系的异步下单，数量一多就很难排查。

订单编号的意义是方便追踪，而不是替代成交确认。准备编写自动交易逻辑时，应先把回调、查询和状态机设计好。主页会继续分享基础订单管理方法，本文仅作技术说明。