前言
策略凌晨还好好的，早上开盘发现quote.datetime不动、日志也不刷新了——这种“假死”在长跑程序里很常见。原因可能是网络、主循环阻塞、API 未继续wait_update，也可能是进程还在但数据截面没更新。要先区分进程活着但没数据和进程已经挂掉。
天勤程序以wait_update为心跳，官方还提供超时返回、断线后的数据恢复等机制（团队里常与TqNotify、持仓核对专题一起用）。下面按概率从高到低列原因和对应处理。
一、主循环阻塞（最常见）
现象：进程 CPU 高或卡在某一函数，wait_update很久才调用一次。
典型诱因：
time.sleep等待下一根 K 线- 同步 HTTP、写库、大段 pandas 计算
- 死循环里
continue前未调用wait_update
处理：用is_changing(kl.iloc[-1], "datetime")代替 sleep；重活放队列或收盘后批处理。在循环里打耗时，超过 200ms 就要优化。
二、网络与连接
现象：进程在跑，wait_update仍调用，但quote.datetime长期不前进。
可能原因：
- 宽带/VPN 抖动、机房到行情网关中断
- 笔记本休眠唤醒后 TCP 半开
处理：
- 用
wait_update(deadline=time.time()+N)做周期心跳，超时返回 False 时打告警并尝试api.close()后重启进程（重启策略要配合状态持久化专题） - 外层用进程管理器（systemd、nssm）保证崩溃自动拉起
具体断线重连行为以当前 TqSdk 版本为准，恢复后应用get_position与策略记忆对账。
三、订阅与合约问题
现象：只有某一个 symbol 没行情，其他正常。
检查：
- 合约代码是否写错（交易所前缀、大小写）
- 是否用了已退市月份
- 夜盘合约白盘未订阅
用get_quote后至少一次wait_update，文档提示刚订阅时datetime可能为空，需区分“从未收到”和“中途停收”。
四、协程里误用 wait_update
若在 asyncio 协程里调用wait_update，API 会抛不能在协程中调用 wait_update。有的同事把异常吞掉，表现为策略静默。
协程环境应使用register_update_notify，与同步策略写法分开，不要混在同一个文件两种模型。
五、TargetPosTask 与主循环抢时间
TargetPosTask在每次wait_update时可能撤单重报。若合约波动剧烈，task 频繁改价，主循环若还在同一帧做重计算，会拉长两次wait_update间隔，间接表现为行情处理变慢。
处理：字段级is_changing缩小计算面；task 参数price="PASSIVE"撤单更多，慎用。
六、资源泄漏与未 close
反复启动脚本而不api.close()，长时间可能耗尽连接或文件句柄。规范：进程退出路径（正常/异常）都close()。
七、恢复后的核对步骤
- 重启进程，确认订阅列表与配置
wait_update后打印各quote.datetimeget_position与策略持久化状态对比- 有在途单则
get_order看清是否需人工撤单
八、运维层建议
| 手段 | 作用 |
|---|---|
| 进程外心跳 | 脚本 5 分钟无日志则告警 |
| TqNotify / 钉钉 | 柜台断线、成交类事件集中转发 |
| 结构化日志 | 每帧记录quote.datetime便于画图定位断点 |
总结
长时间不收行情，先查主循环是否阻塞wait_update，再查网络与合约订阅，然后查协程误用、task 频繁撤单、未 close 泄漏。恢复后按 position、order 与持久化状态对账。
预防靠字段级过滤、避免 sleep、deadline 心跳、进程守护与日志时间戳监控。天勤模型下没有独立“行情线程”，主循环健康度几乎等于行情健康度。
FAQ
1）wait_update 一直阻塞算卡住吗？
无 deadline 时可能长时间阻塞等待数据，属正常；若交易所休市，datetime 不变也正常，要配合交易日判断。
2）TqTimeoutError 是什么？
部分等待操作超时会抛此异常，与wait_update(deadline=...)返回 False 不同，查阅版本文档分级处理。
3）多合约只有一个不动？
优先查该 symbol 代码与是否仍在交易。
4）回测会“卡住”吗？
回测数据播完会BacktestFinished，属于结束而非断线。
风险提示
本文用于运维与开发排查，不构成投资建议。
