一、系统对象 ContextInfo 逐 k 线保存的机制

机制说明

ContextInfo是由底层维护并传递给init、handlebar等系统函数的参数，同一个 bar（不是 bar 里面的 tick，下同）内ContextInfo本质上是同一个变量且对其进行的修改只会对本次handlebar调用的下文所起作用。handlebar里对ContextInfo做的修改在该 bar 结束后才会进行保存，也就是说，对ContextInfo做的修改会在下一个 bar 体现出来。

具体来说，ContextInfo不同于一般 python 对象，做了逐 k 线更新设计，盘中主图品种每个 Level 1 分笔到达会触发handlebar函数调用，但只有 k 线结束时最后一个分笔触发的handlebar调用，对ContextInfo的修改才有效。

每次handlebar函数调用前会对ContextInfo对象进行深拷贝, 下一次分笔行情到来时，如果新的分笔不是新 k 线 bar 第一个分笔，则判断上一个分笔不是k线最后分笔，ContextInfo对象被回退为之前深拷贝的那个。

ContextInfo对象逐k线更新机制设计的目的，是为了在盘中时模拟k线的效果，只在k线结束的分笔触发的handlebar函数运行时生效一次，丢弃所有其他分笔的修改。

影响

该机制有两个影响，一是在ContextInfo对象中存数据每次分笔到达时会被深拷贝，拖慢策略运行；二是ContextInfo适用于记录逐k线生效的交易信号（quickTrade参数传0），不适宜立刻下单的情况。

如不需要模拟k线效果，希望调用交易函数后立刻下单，quickTrade参数可以传2， 下单记录可以用普通的全局变量保存, 不能存在ContextInfo对象的属性里(实现可以参考实盘示例7-调整至目标持仓Demo)。

二、快速交易参数 quickTrade

下单函数passorder有可选参数快速交易quickTrade， 默认为0。

• 传0，只在k线结束分笔时调用passorder产生有效信号，其他情况调用不产生信号。
• 传1，在当前k线为最新k线时调用passorder函数产生有效信号, 历史k线调用不产生信号。
• 传2，任何情况下调用passorder都产生有效信号，不会丢弃任何一次调用的信号。
• 如果在定时器注册的回调函数，行情回调函数, after_init函数中调用下单函数，需要传2，确保不会漏单。
• passorder以外的下单函数不能指定快速交易参数，效果与传0的passorder一致。

三、下单与回报相关

1. 为保证以尽快的速度执行交易信号, qmt 客户端提供的交易接口是异步的, 以快速交易参数填2的passorder函数为例，调用后会立刻发出委托, 然后返回。不会等待委托回报, 也不会阻塞python线程的运行。
2. 委托/成交/持仓/账号信息的更新, 是在客户端后台进行的, python策略中无法手动控制。python提供的取账号信息接口 get_trade_detail_data， 与四种交易回调函数, 都是从客户端本地缓存中读取数据 / 触发调用，不是调用时查询柜台再返回。客户端本地缓存状态定期接收柜台推送刷新，有交易主推的柜台50ms一次，没有交易主推的柜台1-6秒一次。 不能认为get_trade_detail_data查到的状态是与柜台完全一致的, 比如卖出委托后立刻查询, 不会查到对应委托, 可用资金也不会变多。
3. 实盘策略需要设计盘中保存/更新委托状态的机制。常见的做法是用全局变量字典保存委托状态, 给每一笔委托独立的投资备注作为字典的key，委托状态作为字典的value, 下单后默认设置为待报, 之后查到委托后更新状态。如果某品种股票存在待报状态委托, 暂停该品种后续报单, 防止发生超单的情况。(实现可以参考实盘示例7-调整至目标持仓Demo)
4. QMT 所有策略是在同一个线程中被调用的，任意一个策略阻塞线程(死循环 sleep 加锁等操作)会导致所有策略的执行被阻塞，所以不能在策略里写等待操作。如需要多线程 / 多进程的用法，可以使用极简模式配合 xtquant 库使用