企业官网建设流程全解析

前言

国内期货很多品种有夜盘和日盘，中间有休市、小节休息、集合竞价等时段。程序化策略若只写“有价格就交易”，容易在：夜盘结束到日盘开盘之间的几分钟、午休、或节假日仍用旧信号报单，表现为拒单、废单，或更糟——在流动性极差时成交在离谱价格。

K 线datetime能判断新 bar，但休市时 datetime 不推进，不能单靠 datetime 判断“允许交易”。夜盘结束到日盘开盘、小节休息前后的几分钟，还要结合合约 quote 上的交易时间信息与团队规则。下面用天勤 TqSdk 说明这类场景常见误下单原因，以及发单前过滤应怎么写；各品种具体开收时间以交易所当日公告为准。

一、场景：衔接几分钟为何危险

举例（品种各异，以交易所公告为准）：夜盘 23:00 结束，日盘 9:00 开盘，中间行情服务可能仍推送个别字段或显示昨收；若策略在 8:59 用夜盘最后一根 K 线的信号、又对日盘第一秒盲目下单，可能用到过期方向或非连续成交价格。

又如 10:15–10:30 小节休息：K 线 datetime 可能暂停，quote 的last_price偶发跳动，若 tick 策略无时段过滤会误触发。

二、天勤里可用的信息从哪来

quote = api.get_quote(symbol)在wait_update后更新，常见相关字段包括（以你安装版本文档为准）：

• trading_time：与该合约相关的交易时间段结构；
• datetime：行情快照时间；
• 涨跌停upper_limit/lower_limit等。

策略应区分两层：

1. 交易所可交易窗口（尽量从 quote / SDK 能力读取，少手写全国统一钟点）；
2. 本策略允许交易窗口（如开盘后 5 分钟不出信号），可窄于交易所。

三、发单前过滤骨架

q=api.get_quote(symbol)defstrategy_allow_trade(quote):# 请按 TqSdk 文档实现：当前是否处于该合约可交易时段# 不同版本可能有辅助判断，勿虚构字段名returnTrue# 上线前必须替换为真实逻辑whileTrue:api.wait_update()ifnotstrategy_allow_trade(q):continueifnotapi.is_changing(kl.iloc[-1],"datetime"):continue# 信号与 set_target_volume

上线前在模拟盘录一段日志：夜盘结束、日盘开盘前后strategy_allow_trade的 True/False 是否符合预期。开盘集合竞价是否允许入场，应由团队书面规则决定。

四、与 K 线 datetime 的配合

• 休市：K 线datetime不推进 → 不会误触发“新 bar 信号”，这是好事。
• 仍可能问题：休市前最后一根 bar 的信号缓存到日盘，若不在日盘开盘重新评估，会“带着昨夜方向”开仓。可在日盘首根datetime变时强制刷新 bias，或开盘 N 分钟内禁止开仓。

五、TargetPosTask 与非交易时段

模拟逻辑里，非交易时段挂单可能被置为完成或无法成交（见模拟交易源码对_is_in_trading_time的处理）。实盘更应以不发单为主，而不是依赖柜台拒单。

总结

夜盘到白盘的衔接时段，看上去只有几分钟，但恰恰是最容易让策略“拿错时间、拿错业务语义”的窗口。正确做法不是只盯 K 线 datetime，而是把“可交易窗口”和“策略允许交易窗口”分层：用 quote / SDK 能提供的交易时段信息做硬过滤，用开盘规则刷新策略缓存，避免把夜盘最后的方向直接带到日盘第一笔。再加上日志留痕，你在复盘时就能把拒单与异常成交归因到明确的时段决策，而不是纠结于‘那几分钟到底触发了什么’。

FAQ

1）能否用交易日历 API？

若有，可与 quote 组合；以文档为准。

2）夜盘品种订日盘合约？

订可交易的那档合约，时段跟品种走。

3）Scheduler 收盘清仓？

可与时段过滤分层，见 Scheduler 专题。

4）回测夜盘衔接？

回测时间轴按历史规则，仍建议加同样过滤代码。

风险提示

本文讨论交易时段技术，不构成投资建议。