前言
策略丢在云主机上跑，人不在机房，心里总有点虚。我习惯开一个轻量 Web 页面盯仓位和曲线，手机通过内网 VPN 刷一眼，确认进程还活着、持仓没跑偏。天勤这边和 Web 相关的说明在 usage/web_gui.rst，实现上常和 TqWebHelper 一类能力一起用。好用的时候很省心，难用的时候也就两类毛病：图不动，或者端口被占用启动失败。
印象最深的一次，同事远程喊「页面死了」，SSH 上去发现策略其实在跑、也在下单，是主循环里夹了同步请求拉外部数据，把 wait_update 堵住了，Web 自然不刷新。另一次是一台机起三个策略，三个都默认 8888，后起的两个静默失败，大家以为「Web 坏了」，其实是端口打架。下面写集成习惯和排查顺序。
一、适用边界
先说清楚能干什么、不能干什么，免得期望错位。
- 适合本机或内网辅助看盘，不是给互联网公众访问的产品
- 不能替代期货公司官方终端，更不能替代风控审批流程
- 和主策略同一进程、同一
TqApi时，关系最清晰；拆进程就要接受延迟和同步成本
生产环境我会把 Web 当「安慰剂 + 粗监控」，真告警仍走文件日志和分级推送，不靠页面刷新判断生死。
二、最小集成思路
类名、构造参数以 usage/web_gui.rst 为准，别凭记忆硬写。
python
from tqsdk import TqApi, TqAuth, TqSim
# 具体 Web 类名、构造参数以 usage/web_gui.rst 为准
api = TqApi(TqSim(), auth=TqAuth("账户", "密码"))
# web = TqWebHelper(api, ...) # 按文档启用
while True:
api.wait_update()浏览器打开文档给的地址后，策略逻辑仍只在 wait_update 循环里推进。Web 是展示层，别在渲染回调里写下单逻辑，否则刷新一次页面触发一次报单这种惨剧，理论上可能发生。
三、图表不刷新
图 frozen 时，我按这张表从上到下查。
| 可能原因 | 处理 |
|---|---|
| 主循环阻塞 | 去掉 sleep、同步 HTTP、大文件 IO |
| 循环已退出但进程还在 | 看是否异常未捕获、是否误 break |
| 浏览器缓存 | 强刷、换浏览器、无痕窗口试一次 |
| 非交易时段无成交 | 行情字段不变，页面不动属正常 |
| 订阅合约错误 | 核对 instrument_id 是否有推送 |
在循环里临时加一行：仅当 is_changing(quote) 时 print 时间戳。若终端在刷、页面不动，问题在 Web 层；若终端也不刷，先救主循环。
四、端口冲突
多策略同机时，端口必须写进启动脚本，写进运维表。
- 构造参数或配置文件里改端口（以文档为准）
- Windows / Linux 用系统命令查占用，杀掉僵尸策略进程
- 每台机维护「进程名 --- 端口 --- 策略版本」小表，新人部署不会撞车
我见过最折腾的是：旧策略没 kill 干净，新策略用了新端口，同事仍 bookmark 旧端口，以为「今天行情特别平」------其实是在看昨天的僵尸页面缓存。
五、安全注意
内网监控也会出事：误暴露公网、页面里带完整账号、截图外传泄露 webhook。
- 不对公网暴露无认证端口
- 防火墙只放行办公室 / VPN 网段
- 页面和日志里账号打码，密码永不出现
六、与钉钉告警分工
| 渠道 | 用途 |
|---|---|
| Web | 人在时扫一眼、盘中直觉判断 |
| 钉钉/邮件 | 人不在时、必须叫醒你的事件 |
Web 不适合替代断线短信。图不动不等于策略停，策略停也不等于图会马上变灰------两条线要分开想。
总结
TqWebHelper 这类能力，适合「人在附近」的盯盘，不适合当唯一运维手段。天勤主循环一旦为图表或外部请求让路，行情就会慢半拍，下单也会慢半拍。我现在的习惯是：先保证 wait_update 干净，再开 Web；端口写死、写进表；图不刷先查循环活不活，再查浏览器。你若也在远程跑策略，不妨下周挑一个非交易时段，故意开一个阻塞调用，看 Web 和日志谁先「死」------试一次，以后就不容易在实盘高峰踩坑。
FAQ
1）远程服务器怎么看？
SSH 隧道或 VPN 进内网访问，不要裸奔公网。
2）能否只开 Web 不下单？
可以，只订行情做监控，但仍需合法 auth。
3）和 Jupyter 区别？
Jupyter 偏研究交互；Web 偏轻量、长期挂着看。
4）多账户 Web？
以文档为准，先单账户调通再扩展。
5）生产能依赖 Web 吗？
不建议。生产靠日志 + 分级告警 + 期货公司终端复核。
风险提示
本文用于期货量化技术实践讨论，不构成投资建议。