3个Git痛点场景，lazygit如何让版本控制变得像呼吸一样自然
2026/6/9 23:32:06
前言
国内期货量化，指的是用 Python 等语言写程序，根据行情自动决定买卖多少手、何时调仓，而不是人工盯盘点鼠标。一套程序往往同时关注多个品种：螺纹钢、铁矿石、豆粕各订一份行情，有的还订 1 分钟、5 分钟两套 K 线。天勤量化（TqSdk）是常用的 Python 框架：你创建TqApi，用get_quote订 tick 级行情，用get_kline_serial订 K 线，然后在while True里反复wait_update()收数据、算指标、决定是否set_target_volume调仓。
问题出在：订得太多、算得太勤，服务器 CPU 会在交易时段飙高，风扇响，wait_update变慢，行情反而处理滞后——看起来像「天勤慢」，往往是订阅范围和触发条件写得太宽。回测里历史数据推送节奏和实盘不同，同样代码回测可能很轻快，一上实盘就暴露。下面先说明天勤数据怎样更新，再讲如何用is_changing做字段级过滤、如何精简订阅。
一、先弄清几个名词
| 名称 | 是什么 | 和 CPU 问题的关系 |
|---|---|---|
| 订阅 | 调用get_quote/get_kline_serial向服务器声明要哪些合约数据 | 订得越多，每次wait_update可能处理的更新越多 |
wait_update() | 阻塞等待一批业务包，刷新内存里的行情、委托、持仓 | 主循环核心；两次调用之间若做大计算会拖慢收包 |
| tick | 每笔成交或盘口跳动，quote.last_price等字段会变 | 每个 tick 都算均线，CPU 会爆 |
| K 线 bar | 按固定周期合成的开高低收，表里有datetime | 5 分钟策略应在新 bar 时算一次，不是每个 tick |
is_changing(对象, "字段") | 判断本帧该字段是否刚更新 | 只在该变时进逻辑，避免空转 |
iloc[-1]/iloc[-2] | K 线表最后一行 / 倒数第二行 | 新 bar 看 [-1] 的 datetime 变，信号常在 [-2] 算 |
set_target_volume | 设目标净仓，task 在 wait_update 里发单 | 每个 tick 都 set 会频繁撤单，加重负担 |
| trade 列表 | 允许真实下单的 symbol | 与只观察不交易的 watch 列表应分开 |
二、天勤程序为何会因「订太多、算太勤」变卡
典型错误写法：
- 对 15 个合约各订 quote + 3 套 K 线，共 60 个序列；
- 主循环里
if api.is_changing(quote):不指定字段，盘口任意字段变都进逻辑； - 每个 tick 对全部合约重算 60 周期均线；
- 方向一变就
set_target_volume，夜盘产生大量撤单。
正确节奏（以 5 分钟 K 线趋势策略为例）：只有is_changing(kl.iloc[-1], "datetime")为真时，才在iloc[-2]上算均线、出信号；tick 级入场另说，也要字段级is_changing(quote, "last_price")，且避免重复 set 相同目标。
三、推荐主循环结构
# 启动时订好，勿在循环里反复 get_kline_serialklines={s:api.get_kline_serial(s,300,data_length=200)forsintrade_symbols}whileTrue:api.wait_update()forsintrade_symbols:kl=klines[s]ifnotapi.is_changing(kl.iloc[-1],"datetime"):continue# 仅在已收盘 bar（[-2]）上算信号process_signal(s,kl)process_signal内再决定是否tasks[s].set_target_volume(target)；若 target 与上次相同，不要重复 set。
四、订阅精简原则
| 列表 | 放什么 | 怎么用 |
|---|---|---|
| trade_symbols | 真要下单的品种 + 算信号必需的 K 线 | 主循环重点处理 |
| watch_symbols | 只看基差、不写单 | 仅在 K 线 datetime 变时读一次，或另进程 |
主连算信号、具体月执行时：执行层只订underlying_symbol对应的具体合约，不必订所有月份。data_length在启动时按最长指标周期估好，循环内不要新建订阅。
五、如何确认是 CPU 问题
在交易时段打日志：每圈wait_update耗时、每秒循环次数。若每秒上百次且每次都做 pandas 大计算，优先改触发条件。若在 Jupyter 里反复运行策略单元格而不api.close()，会叠多个TqApi，内存和 CPU 也会异常——这与订阅无关，但是常见坑。
生产环境若开了天勤 web 绘图（TqWebHelper），也会额外占资源，服务器上常关闭。
总结
订阅太多合约本身就会增加每次 wait_update 的工作量；若再用无字段过滤的 is_changing、在每个 tick 重算指标，CPU 飙高几乎必然。天勤提供字段级 is_changing 和 K 线 datetime 触发，就是让期货量化程序只在「该算的时候」才算一遍。把允许交易的 symbol 和只观察的 symbol 分开、启动时订齐 K 线、热路径上避免重复 set_target_volume，多品种组合也能在普通服务器上长期跑，而不是一味加 CPU 硬扛。
FAQ
1）天勤有订阅数量上限吗？
文档无固定上限，以你的机器和逻辑实测为准。
2）data_length 很大会更卡吗？
主要增加指标计算量和内存，见最长均线周期合理估算即可。
3）多品种能否多进程？
每进程独立TqApi可以，但同一期货公司资金账户不要两个进程同时自动交易。
4）最少要订几个合约？
一个 trade symbol + 一套信号 K 线 +wait_update循环，先跑通再扩展。
风险提示
以上内容用于性能优化参考，不构成投资建议。