前言

刚从天勤转过来的同事，几乎都会在策略里写一行 time.sleep(60)，理由是「每分钟检查一次风控」。结果那分钟里行情不推进、撤单不回、止损逻辑卡住，盘中一次闪崩就扛满整分钟。还有更诡异的：有人在 wait_update 里 sleep，有人在外层 sleep，夜盘和白盘表现还不一样，排查时大家对着日志干瞪眼。

我早期也写过「14:55 平仓」，第一版用 sleep 卡到 14:56 才平，滑点多出一截。后来改成跟 quote 的交易所时间走，或者在 TqScheduler 里注册回调，但回调里只设标志位，真正下单仍放回主循环。天勤的单线程事件模型，定时任务必须服从「行情帧」，不能跟行情抢线程。下面分几种写法说清适用场景。

一、为什么不用 sleep

单线程下，sleep 期间 wait_update 不执行，所有订阅对象的更新都停住。你以为只是「歇一分钟」，对策略来说可能是「一分钟失明 + 聋」。撤单、紧急平仓、风控检查若依赖行情推进，都会被拖住。

所以定时需求应挂在：同一 Api 的调度机制，或用行情时间字段判断。别在循环里用 sleep 冒充定时器。

二、用行情时间做「伪定时」（我最常用）

日内「收盘前平仓」「夜盘结束前减仓」，多数时候跟交易所时钟就够了，不必引入复杂调度库。

from datetime import time

while True:
    api.wait_update()
    if not api.is_changing(quote):
        continue
    dt = quote.datetime  # 格式以字段为准，需解析为交易时区
    # 解析后若 >= 14:55 且尚未平仓，则 set_target_volume(0)

精度取决于 quote 更新频率；活跃品种通常够用。非交易时段字段不动，别误触发。解析 datetime 时建议统一用团队约定的时区工具函数，别每个策略各写一版字符串截取。

三、TqScheduler 思路

固定日历时刻、或与行情帧弱相关的任务，可看 advanced/scheduler.rst。典型模式是创建 TqApi 时注册回调，到点触发；回调里务必短小：

• 不 sleep、不做同步 HTTP、不拉大数据
• 不直接狂发单，只设 need_flat = True 之类标志
• 主循环下一帧看到标志，再调 TargetPosTask 或 insert_order

这样调度器和交易逻辑仍共用一条 wait_update 管道，不会两条线互相踩。

四、与 K 线收盘定时对比

方式	触发依据	适用
K 线 datetime 变化	新 bar	按周期调参、换月检查、均线信号
quote 时钟字段	交易所时间	日内时点平仓、午休禁止开仓
TqScheduler	日历/时刻	固定时刻任务、日终报表触发

我若策略本身是 K 线驱动，就优先 K 线帧；若是 tick 级风控叠加日终平仓，就 quote 时间 + 标志位。Scheduler 留给「和 K 线周期对不齐」的时刻。

五、调试建议

• 模拟盘把触发时刻改到「接下来两分钟」，盯着日志看是否只触发一次
• 每次触发打印：原因、解析后的时间、当前持仓
• 节假日、无夜盘日用交易日历过滤，避免春节还在喊平仓

回测里时间加速，判断条件要用回测时钟字段，别用本机 datetime.now()，否则回测和实盘两套时间，结论对不上。

总结

天勤的定时，本质是「在事件驱动里插一脚」，而不是另起一个阻塞线程。我现在的默认顺序是：能跟行情时间走就跟行情走；需要对齐 wall clock 再用 TqScheduler；无论如何不在回调里重仓下单。你把「到点平仓」拆成「到点 → 设标志 → 主循环平仓」，夜盘和白盘行为会稳定很多，同事也不会再偷偷写 sleep。若你手里还有带 sleep 的老策略，建议先在一个模拟日上专门测「闪断 30 秒」时会不会错过撤单，测完一般就有动力改了。

FAQ

1）每秒级任务怎么办？

不适合塞在期货主循环。高频监控用独立进程或外部服务，别拖行情泵。

2）Scheduler 能跨夜盘吗？

注意交易日划分，用交易日历区分「今天」是哪一个 trading day。

3）回测里定时有效吗？

有效，但要用回测时间轴，不能用本机时钟。

4）多策略共用一个 Scheduler？

同一 Api 上统一注册，避免重复注册同一时刻两次触发。

风险提示

本文用于期货量化技术实践讨论，不构成投资建议。