QMT 的 Python 执行引擎本质上是一个 C++ 内核外面包了一层 Python 的“单线程回调机器”。它的瓶颈几乎都源于“单线程”这三个字——不能并行，一个地方慢了，所有策略一起排队等。

QMT 的 Python 执行引擎到底是个啥？

你可以把 QMT 理解成一个本地运行的量化软件，它自带了一个 Python 环境。但 QMT 没有用标准的 Python 主程序来跑你的策略，而是用底层的 C++ 内核“指挥” Python 干活。

具体流程是这样的：

QMT 的 C++ 内核负责接收行情、解析数据、管理账户。 当它发现有新数据来了（比如新的一根 K 线完成了，或者新的一笔 Tick 到了），它就会去调用你写在 Python 策略里的 handlebar 函数。你的 Python 代码只是在 C++ 说“轮到你了”的时候跑一下，算完指标、发出信号，控制权又交回给 C++。

这跟你在 PyCharm 里写个脚本自己从头跑到尾完全不一样。你的代码是被“打断式”执行的，主动权在 QMT 手里。

QMT 主要提供三种触发方式：

• handlebar（逐 K 线）：每根 K 线走完（或盘中 Tick 变动）触发一次，最常用。
• subscribe（事件驱动）：订阅某只股票的 Tick，来了就推给你。
• run_time（定时器）：按固定秒数/分钟数隔一会儿执行一次。

单线程策略的瓶颈一般卡在哪里？

QMT 最大的一个“硬限制”是：所有 Python 策略、所有指标计算，都在同一个线程里跑。没有多线程，没有并行。这意味着任何一段慢代码，都会拖死整个 QMT 里所有正在跑的策略。

瓶颈通常出现在这几个地方：

① 在 handlebar 里反复取历史数据

这是最常见的坑。很多人习惯在每根 K 线里调 get_market_data_ex 或者 history_bars 去捞数据。问题是，每根 K 线都去取一遍，相当于把同一段历史数据翻来覆去读了几百遍。数据量小的时候感觉不到，股票一多、K 线一长，光读数据就能把线程堵住。

正确做法是在 init 里一次性把需要的历史数据读到内存里，后面在 handlebar 里只做索引和计算。

② 在 handlebar 里写循环算指标

如果你在 handlebar 里写 for 循环遍历几十只股票算均线、算 RSI，那就是在单线程里硬扛。Python 原生循环本来就慢，QMT 这个单线程更扛不住。

能用 pandas/numpy 的向量化运算就用向量化，能预计算的就在 init 里预计算好。

③ 高频 Tick 订阅 + 全量计算

有人为了“实时”，给几十只股票订阅 Tick，然后每一笔 Tick 来了都重新计算全套指标。Tick 一秒可能来好几笔，你的策略一秒钟要算几十遍同样的东西，线程直接跑满。

合理的做法是加计数器，比如每 10 个 Tick 算一次，或者只在关键价格位置才算。

④ 任何形式的阻塞代码

这是最致命的。如果你在策略里写了 time.sleep()、死循环、或者用了 threading 去锁东西，不只是你的策略会卡住，整个 QMT 里所有策略全部一起卡死。

QMT 的设计里就没有“让出 CPU 等一会儿”这种概念。你的代码只要没跑完，C++ 内核就等在那里，别人的 handlebar 也进不来。

所以总结一下：QMT 的引擎是一个 C++ 内核驱动的单线程回调系统。瓶颈的核心永远是“单线程”三个字——你写的每一段慢代码，代价都是整个平台上所有策略一起替你买单。 避免瓶颈的方法就一句话：能在 init 里做的别放到 handlebar 里，能用向量化的别写循环，永远不要写阻塞代码。