QMT策略回测有结果，只能说明代码在历史数据和回测撮合规则下完成了运行，距离实盘可用还有一段路。最常见的误区，是看到收益曲线不错，就直接把回测代码放进模型交易。真正切换前，应检查数据、时间、账户、订单和异常处理，而不是只看回测结果。

第一项是数据完整性。确认回测使用的历史行情没有缺口，周期、复权方式和标的代码一致。指标需要预热时，下载起点应早于回测起点。若回测大量跳过数据不足的标的，结果可能只来自少数样本，不能直接代表策略整体。

第二项是未来数据。回测代码是否使用了当时尚未完成的K线，是否在盘中引用了当天完整收盘价，是否把后续财务信息提前带入，这些都会让历史结果失真。实盘只能使用当前已经获得的数据，回测也应遵守同样时间边界。

第三项是运行机制。QMT中的handlebar、行情订阅和定时任务触发方式不同。回测按K线推进，盘中则可能每个行情快照都触发。代码如果没有使用is_last_bar过滤历史K线，或没有防止同一信号重复执行，实盘可能在短时间内多次报单。

第四项是交易模式。默认逐K线生效与立即下单的行为不同。选择立即下单时，订单状态应保存在普通全局对象中，而不是可能回滚的ContextInfo属性。切换模式前要理解信号在什么时候真正发送，不能仅凭回测中出现交易记录判断。

第五项是账户绑定。模型交易中要选择正确资金账号和账号类型，确认能够查询可用资金、持仓和当日委托。测试账号、模拟账号和真实账号必须明确标识。能进入QMT客户端，不代表交易账户已经加载。

第六项是资金和数量。回测初始资金可能与真实账户差异很大。实盘应根据真实可用资金计算数量，并满足交易单位、价格精度和可卖数量要求。回测中的全仓下单写法，不能不加限制地直接使用。

第七项是订单闭环。下单函数返回订单编号，不代表成交。策略要查询订单状态或接收回报，识别已报、部分成交、已成、已撤和废单。存在未完成订单时，应暂停重复报单。卖出逻辑还要使用真实可用数量，而不是回测持仓变量。

第八项是异常处理。行情为空、账户未登录、网络断开、订单查询失败时，程序应该停止新委托并记录日志。不能为了让策略“不断运行”而把所有异常都忽略。自动交易最重要的能力之一，是在不确定时不行动。

第九项是重启恢复。程序重启后，内存变量可能丢失，QMT部分上下文变量还存在回滚机制。策略应重新查询真实账户，并对订单和持仓做对账。必要的状态可以持久化，但柜台数据始终应当作为最终依据。

第十项是模拟验证。先在模拟信号中观察触发，再用模拟柜台测试订单和撤单。模拟不能保证实盘结果，却能发现重复下单、账号错误和状态不同步。建议至少经历多个交易日，而不是只测试一次。

正式实盘初期还应控制规模和复杂度。可以只运行少量标的、低频逻辑，并保留人工监控。每个订单都能从信号、委托到成交完整解释，再逐步扩展。自动化不是一次开关，而是逐层验证的过程。

还应检查策略是否存在“回测专用写法”。例如回测中直接使用context.portfolio中的虚拟现金，实盘却没有重新查询账户；回测默认一次调用一次交易，实盘中同一函数却可能多次触发；回测订单立即按照撮合规则处理，实盘订单则长时间处于已报。把这些差异逐项列出来，才能知道哪些代码需要重构。

实盘前最好做一次故障演练：主动关闭网络、重启客户端或让数据返回空值，观察程序是否安全停止。只有正常情况能运行，还不算真正准备好。

回测有结果只是说明历史流程跑通，实盘还要面对真实账户、订单和异常。主页会继续更新从回测到模拟、再到实盘的验收清单，便于逐项检查。本文仅作量化学习参考。