信号发到 QMT 之后：延迟出在哪一段、怎么保证不重复下单

很多人把策略跑通之后，会遇到两个新问题：信号慢几秒到十几秒，以及偶尔重复下单。这两个都不是玄学，拆开看都是确定性的工程问题。

一、延迟到底出在哪一段

整条链路只有四个地方会吃时间，按实际发生概率排：

1. 策略侧的调度精度（最容易被忽略）

run_daily 注册的时间点不是精确到毫秒的，本身就有抖动。如果你用的是延时行情源，信号还会跟着一起晚。这一段不在你的控制范围内，但必须先从总耗时里扣掉，否则会一直怀疑是自己的中转慢。

2. 信号推送

策略侧 requests.post 推出去，通常几百毫秒。但如果你是把信号先写进文件、再由执行端轮询读取，就要再加一个完整的轮询周期 —— 5 秒轮询就是平均多 2.5 秒，这是白送的延迟。

3. 中转服务

一般可以忽略。真正会拖慢它的是同步阻塞的写法，比如在收信号的接口里直接调了下单。

4. 执行端取实时行情（第二大坑）

如果下单用的是「按目标市值/数量」这类接口，它得先拉一次实时行情算出价格和股数。行情源没有提前订阅、临时拉取的时候，这一步吃掉十几秒很常见。

解决办法两条：

• 提前订阅你要交易的标的，别等下单那一刻才拉；
• 或者在信号里就把价格算好带过去，执行端不再自己算。

怎么定位

在执行端打两个时间戳 —— 「收到信号时刻」和「实际报单时刻」，再和策略里打印的策略时间一比，四段耗时立刻分开。

固定十几秒这种量级，几乎一定是某个同步阻塞调用，不是网络抖动。网络抖动是波动的，不会每次都卡在同一个数字上。

二、比延迟更危险的：重复下单

延迟最多让你成交价差一点。重复下单会让你的仓位直接翻倍，而且往往在收盘后才发现。

三个必须做的设计：

1. 发目标持仓，不要发动作指令

「买入 100 股」这种动作消息一旦重试，就是重复下单。「目标持仓 = 1200 股」这种状态消息重复收到也没关系，执行端自己算差额就行。

这是整条链路里最重要的一条设计，建议一开始就这么定，后面改起来很痛。

2. 用 signal_id 做幂等

断线重连、任务重启、轮询重叠，都会重放同一条信号。执行端拿 signal_id 建唯一索引，重复的直接丢。

没有这一条，你迟早会在某个下午发现账户里多了两倍的仓位。

3. 带 expire_at，过期直接丢

9:29 生成的信号，10:30 才被拉起来执行，价格早就变了。

丢单第二天会自己修正，补单是主动做错一笔。 所以宁可丢，不要补。

三、每日对账

两端各存一份日志，每天收盘比一次「目标持仓 vs 实际持仓」。

出问题时你才能判断到底是哪一种：没发出 / 没收到 / 被拒单 / 未成交 —— 这四个的处理方式完全不同。

四、完整步骤与工具

这套流程从注册到跑通的分步说明： https://www.kimiquant.cn/notes/jq-signal-qmt

不想自己搭中转服务的话，我们做了个现成的： https://www.kimiquant.cn/tools/signal （免费档：5 秒轮询、每天 20 条、1 个策略；付费档：0 延迟、约 5000 条、5 个策略。先免费用，够用就不用花钱。）

顺带分享一个写这类脚本挺省事的 AI 工具： https://workbuddy.ai/invite?code=66L9RNCT