QMT量化交易中同步下单与异步下单的区别是什么？

在量化交易中，理解同步下单与异步下单的机制对于编写高效、稳定的策略至关重要。需要首先说明的是，order_stock 和 order_stock_async 通常是 Ptrade 平台或某些特定封装库的 API 命名。在 QMT 原生 Python API 中，核心的下单函数是 passorder、order_lots 等。不过，同步与异步下单的底层逻辑是相通的，下面为您详细解答这两种模式的区别、适用场景以及回调问题。

一、 同步下单与异步下单的区别

1. 同步下单 (类似 order_stock)

• 执行机制：阻塞式（Blocking）。当策略代码执行到下单函数时，程序会暂停往下执行，向交易柜台发送委托指令，并等待柜台返回委托确认结果（如委托编号、成功或失败状态）。拿到结果后，代码才会继续执行下一行。
• 优点：逻辑清晰，所见即所得。你可以立即根据下单的返回值决定下一步操作。
• 缺点：网络延迟或柜台处理延迟会导致策略线程阻塞，如果在同一根 K 线上需要处理大量计算或多只股票的下单，可能会导致严重的延迟甚至错过行情。

2. 异步下单 (类似 order_stock_async)

• 执行机制：非阻塞式（Non-blocking）。策略代码执行到下单函数时，仅将下单指令推送到本地发送队列或直接发给网关，不等待柜台返回结果，程序瞬间继续执行下一行代码。
• 优点：执行速度极快，不会因为网络 I/O 阻塞策略的主逻辑计算，非常适合并发处理。
• 缺点：无法立即获取委托结果，必须依赖事件驱动（回调函数）来异步处理订单状态和成交结果，增加了代码逻辑的复杂性。

二、 分别适用于什么样的场景？

• 同步下单适用场景：

  • 低频交易：如日线级别的调仓，对毫秒级延迟不敏感。
  • 强逻辑依赖：下一步操作必须依赖上一步的成交结果。例如：必须确认卖出某只股票释放了资金后，才能执行买入另一只股票的操作。
  • 简单策略：新手入门或逻辑简单的策略，使用同步下单更容易调试和维护。

• 异步下单适用场景：

  • 高频/Tick级交易：对延迟要求极高，不能容忍任何网络等待。
  • 批量并发下单：例如一篮子股票（几十上百只）同时调仓，如果用同步下单，串行等待会导致最后几只股票的下单时间严重滞后；异步下单可以瞬间将所有指令发出。
  • 复杂的事件驱动策略：策略本身就是基于状态机编写的，能够很好地处理异步回调。

三、 为什么异步下单不能回调成交主推？

如果您在使用某种异步下单接口时发现无法触发成交主推回调（如 on_stock_trade 或 QMT 中的 deal_callback），通常是由以下几个原因造成的：

1. 未正确绑定资金账号
   在 QMT 中，接收交易主推的前提是在 init 函数中显式绑定了资金账号。如果没有绑定，底层网关不知道该把哪个账号的推送发给当前策略。

   def init(ContextInfo):
       # 必须绑定账号才能接收 order_callback 和 deal_callback
       ContextInfo.set_account('您的资金账号')
   

2. 异步线程上下文丢失
   异步下单通常由后台独立线程处理。如果封装的异步接口在发送订单时，没有正确携带当前策略的上下文标识（如 strategyName），当柜台返回成交信息时，平台无法将该成交信息路由回您当前的策略实例中，从而导致回调函数不触发。

3. API 接口本身的限制或 Bug
   某些平台在早期设计异步接口时，可能仅将其作为一种“只发不收”的快捷通道（Fire-and-Forget），底层并未将异步生成的订单 ID 与主推事件队列进行关联。如果是这种情况，建议查阅对应平台的最新文档或联系技术支持。

4. 回调函数命名或参数错误
   在 QMT 平台中，标准的成交主推回调函数是 deal_callback，委托主推是 order_callback。请确保函数签名完全正确：

   def deal_callback(ContextInfo, dealInfo):
       print("收到成交主推:", dealInfo.m_strInstrumentID, dealInfo.m_nVolume)
   

总结建议

在 QMT 平台中，推荐使用原生的 passorder 函数。配合 quickTrade 参数（设为 1 或 2）以及 deal_callback，可以实现非常高效的准异步交易体验，同时完美支持成交和委托的状态主推。