TqSdk 回测由订阅的数据事件推动不是每次wait_update固定前进一根 K 线。程序订阅了 Quote、不同周期 K 线或其他数据后回测会推进到下一个相关事件更新内存对象再让策略判断变化。因此同样一次循环可能对应当前 K 线内部变化也可能形成新 K 线必须用is_changing判断真正发生了什么。先用明确时间区间创建回测回测通过TqBacktest指定开始和结束日期或时间并使用本地模拟账户。下面只演示结构和新 K 线触发不构成完整策略。import os from datetime import date from tqsdk import TqApi, TqAuth, TqBacktest, TqSim from tqsdk.exceptions import BacktestFinished sim TqSim(init_balance100000) api TqApi( sim, backtestTqBacktest( start_dtdate(2025, 1, 2), end_dtdate(2025, 3, 31), ), authTqAuth(os.environ[TQ_USER], os.environ[TQ_PASSWORD]), ) klines api.get_kline_serial(KQ.mSHFE.rb, 60, data_length50) try: while True: api.wait_update() if api.is_changing(klines.iloc[-1], datetime): closed klines.iloc[-2] print(closed.datetime, closed.close) except BacktestFinished: print(sim.tqsdk_stat) finally: api.close()日期和时间按北京时间理解。区间应记录在结果中避免只保存收益率却不知道使用了哪段行情。示例使用主连做连续研究涉及交易时还要处理具体合约映射和换月不能把主连直接当成交标的。wait_update 推进的是下一个数据事件如果只订阅一分钟 K 线也可能在这一分钟内部收到末行字段变化。若订阅 Tick事件会更密集若同时订阅多个合约和周期各自的数据事件都会影响循环推进。于是“循环次数”不能直接解释为“K 线根数”。策略希望每根完成 K 线只决策一次就监听末行datetime变化并使用倒数第二行。策略希望观察当前线内部变化则监听收盘价或其他字段。触发条件必须和实时版本一致否则回测中的计算频率与实盘不同。事件驱动还有一个重要好处同一份策略结构可以在实时和回测中使用相似的更新逻辑。但这不代表两者成交结果相同行情数据和撮合环境仍有差异。回测中下单仍是一个状态过程使用insert_order或 TargetPosTask 时请求仍要经过后续wait_update执行委托、成交、持仓和资金对象也会逐步更新。不要在创建订单的同一行后立刻读取最终持仓并作结论。回测使用 TqSim 模拟交易撮合遵循其模拟规则。可用数据中出现某个价格不等于真实交易时自己的订单一定能成交。结果应被理解为在给定数据和撮合假设下的测试而不是未来成交证明。若策略依赖盘口排队、部分成交或交易所微观撮合普通回测可能无法完整复刻。应把这些差异写进结论并在实时模拟和小规模实盘中继续验证。先验证信号与流程再看收益率第一轮回测最重要的是检查信号是否在预定条件出现。可以抽取若干时间点保存输入 K 线、指标值、信号和目标仓位手工核对公式。信号定义错误时收益率无论好坏都没有解释价值。第二轮检查订单和持仓。每个信号是否只产生一次业务动作方向与开平是否正确订单结束后仓位是否符合目标退出时是否还有未决委托。能跑完并不等于状态闭环。第三轮再看资金统计、回撤、交易次数和成本敏感性。若修改参数后只挑最好区间容易把策略适配到历史。应保留多个区间与未参与调参的样本观察结果是否稳定。回测速度很快反而容易让人忽略检查。一次跑几秒就得到结果不代表其中数千次事件都正确。先建立少量可回放样本再扩大区间能显著降低错误公式被漂亮曲线掩盖的风险。一次参数调整应留下变更记录改了哪个条件、为什么改、在哪些区间验证。若每次看完结果就同时修改多个参数最后即使收益改善也无法知道真正起作用的是哪一项。保留固定基准运行才能区分规则改进与偶然区间差异。失败结果同样有价值。没有成交可能意味着条件过严也可能是事件没有触发、合约代码不对或订单无法成交。先按数据、信号、委托、成交顺序定位不能只降低阈值让曲线出现交易。数据粒度决定能回答什么使用一分钟 K 线时只知道每分钟开高低收等汇总信息无法还原分钟内全部路径。最高价与最低价的先后、订单排队和每笔成交顺序可能未知。依赖这些细节的策略需要更合适数据或者接受结果范围而非精确点值。主连序列解决连续研究问题却引入合约切换。实际持仓不能在换月点自动无成本迁移若策略跨月运行需要显式选择实际合约并把换月交易、价差和费用纳入测试。历史数据本身也不能消除未来数据泄漏。指标不得使用当时尚未形成的末行最终值也不要通过反向填充、居中窗口或全样本标准化间接看到未来。时间区间还应覆盖策略声称处理的场景。趋势、震荡、活跃与低流动性阶段可能表现不同。只选一段最适合策略的历史不能说明稳定性但把所有历史混成一个数字也会掩盖阶段差异。分段报告并保留统一规则更有解释力。交易成本和成交假设应做敏感性检查。参数轻微变化就让结果从盈利变成大幅亏损说明结论对假设非常敏感。此时优先收紧适用边界而不是把最乐观的一次结果当作预期。如何让回测与实时结构一致把行情推进、信号计算、目标生成、订单管理和日志分开。回测与实时共用纯计算函数各自只负责提供当时可用的数据快照。这样差异主要集中在数据源和账户环境而不是维护两套完全不同的策略。时间判断尽量使用行情时间不依赖程序实际运行速度。实时一分钟与回测一分钟在墙钟耗时上完全不同但行情时间规则应一致。退出也应有统一路径。回测结束捕获BacktestFinished输出统计并关闭 API实时退出则处理信号停止、活动委托和账户状态。两者都不要靠强制终止进程代替收尾。回测验收清单记录固定时间区间、合约、周期、初始资金和关键参数。用is_changing定义事件不把一次循环等同于一根 K 线。先抽查输入、指标、信号、订单和持仓再解释收益统计。数据粒度、模拟撮合、主连换月与未来数据边界写入结论。回测与实时共享计算逻辑分别验证执行环境结束时安全关闭 API。回测真正回答的是“这套明确规则在这些数据和假设下如何运行”。只要不把循环次数、模拟成交和历史收益扩大成它们没有证明的事情回测就能成为发现错误、比较规则和准备下一阶段验证的高效工具。