一、量化策略开发的基础逻辑

在 QMT 中，策略通常遵循“初始化 → 信号生成 → 下单执行 → 状态反馈”的闭环流程，主要由两个核心函数串联：

1）init(context)：策略初始化

• 策略启动时只执行一次
• 常用于：设置参数、订阅标的、加载历史数据、初始化变量/账户状态等

2）handlebar(context)：主逻辑循环（K 线 / Tick 驱动）

• 每根 K 线（或每个 Tick）触发一次
• 常用于：计算指标与交易信号、判断买卖条件、调用下单接口完成执行

注意：QMT 属于事件驱动架构，不支持在策略里写“死循环/等待式”的运行逻辑。

二、开发过程中的关键注意事项

1）下单接口是异步的

• 调用 passorder 等下单函数后会立即返回，不会等待柜台确认
• 委托与成交状态需要通过回调（如 on_stock_order、on_stock_trade）来更新
• 因此应提前设计：委托 ID 跟踪、撤单/重下、重复下单防护等状态管理机制

2）账户与持仓信息可能存在延迟

• get_trade_detail_data 等接口读取的是本地缓存，并非柜台实时回传
• 不建议用“下单后立刻查询持仓/资金变化”来驱动下一步决策，容易出现逻辑误判

3）禁止阻塞主线程

• 多策略通常运行在同一主线程/主事件循环内
• 禁止使用 time.sleep()、死循环、长时间加锁等阻塞操作，否则可能导致策略整体卡死
• 如需“定时任务”，建议借助 handlebar 的自然触发，并结合时间条件判断实现

4）回测复权方式要选对

• 一般建议使用等比前复权进行回测
• 可减少配股、增发等公司行为造成的价格跳空，使回测曲线更连贯、更贴近实盘体验

5）策略模式（大 QMT / MiniQMT）需提前选型

• 大 QMT：更适合回测与复杂策略开发，可直接使用客户端侧数据能力
• MiniQMT：更偏实盘部署，往往需要策略主动拉取/维护数据，策略结构也不同
• 两者在实践中通常代码不兼容，不要指望直接互相迁移

6）信用交易要做专项适配

• 需要将账户类型指定为 "CREDIT"
• 融资买入/融券卖出涉及不同委托类型、标的范围、维持担保比例等约束，需按券商接口与规则细化处理

三、开发建议（更稳更省坑）

• 实盘前先在仿真环境充分验证策略逻辑与异常分支
• 用全局字典/状态对象统一管理关键变量（如委托 ID、订单状态、持仓状态）
• 避免高频、重复拉取数据接口，防止性能瓶颈
• 日志用于定位问题即可，避免过度打印影响运行效率

注：实际 order_type、下单参数与回调字段等细节，应以具体券商的 QMT 接口定义为准，并结合交易方向（普通/融资/融券）确认。

QMT和ptrade低佣金开户，政策好、操作快，欢迎联系我，微信或电话沟通，轻松开户。