get_full_tick()能任意获取股票的tick数据，是不是说明qmt一直在缓存全部股票的tick
如题，想不明白，get_full_tick()能任意获取股票的 tick 数据，是不是说明 qmt 一直在缓存全部股票的 tick？
如果真是这样的话，带宽应该不够也对吧？
问题描述
解决方案
这是一个非常专业且切中量化交易底层机制的好问题。直接回答你的疑问：不是的，QMT 并没有一直在后台缓存全市场所有股票的 tick 数据。
正如你所推测的，如果 QMT 客户端实时接收并缓存 A 股全市场（5000多只股票加上各类指数、基金等）的 tick 数据，普通家用或商用宽带的带宽根本无法承受，同时个人电脑的 CPU 和内存也会因为处理海量的高频数据而崩溃。
那么 get_full_tick() 是如何工作的呢？这涉及到 QMT 的按需订阅（Subscribe）机制和快照请求机制：
1. 按需订阅机制 (Subscribe)
QMT 终端与行情服务器之间采用的是按需订阅模式。只有在以下几种情况下，QMT 才会实时接收并缓存某只股票的 tick 数据：
- 主图/副图展示：你在 QMT 软件界面上打开了某只股票的 K 线图或分时图。
- 策略股票池：你在 Python 策略的
init函数中，通过ContextInfo.set_universe(['股票代码'])将股票加入了基础股票池。 - 显式代码订阅：你在策略中使用了
ContextInfo.subscribe_quote('股票代码')显式订阅了该股票的行情。
对于这些被“激活”的股票，QMT 会在本地内存中维护它们的最新 tick 状态。当你调用 get_full_tick() 时，它是直接从本地内存中极速读取这笔最新数据的。
2. 未订阅股票的临时快照请求
如果你在代码中调用 get_full_tick(['未订阅的股票代码'])，QMT 底层通常会触发一次向服务器的临时快照请求（Snapshot）。它只会拉取该股票当前时刻的最新一笔 tick 数据返回给你，而不会建立持续的实时推送连接。这种单次请求的数据量极小，完全不会造成带宽压力。
(注：在某些严格限制的版本中，如果未提前订阅或加入 universe，直接获取未订阅股票的 tick 可能会返回空值或旧数据，因此规范的做法是先订阅再获取。)
3. 为什么感觉像“任意获取”？
因为 QMT 底层 C++ 框架对网络请求和内存读取做了极好的封装。当你传入任意代码时，底层会自动判断：
- 如果在本地缓存中（已订阅） -> 直接返回内存数据（微秒级）。
- 如果不在本地缓存中（未订阅） -> 发起一次极轻量的网络请求获取最新快照并返回（毫秒级）。
这种无缝切换让你在编写 Python 代码时，感觉像是本地拥有了全市场的数据，实际上是**“本地核心缓存 + 云端按需极速拉取”**结合的结果。
💡 最佳实践建议
为了保证策略运行的效率和数据的绝对实时性，强烈建议：
不要在盘中高频地对未订阅的股票列表调用 get_full_tick()。如果你需要监控某些股票的 tick，请务必在 init 中使用 ContextInfo.set_universe() 将它们加入股票池，或者使用 ContextInfo.subscribe_quote() 进行订阅，让数据通过主推机制更新到本地内存中，这样调用 get_full_tick() 才是最高效、最安全的。