股票实时监控怎么落地？从行情输入到交易反馈的链路拆解

整理股票实时监控方案时，我习惯先画数据流，而不是先比较软件。完整链路至少包含行情输入、条件计算、策略状态和交易反馈。只在屏幕上显示最新价，属于实时行情；系统能持续判断条件、记录触发结果，并把委托和成交状态返回，才算实时监控。把这几个环节分开后，很多选型争论会简单不少，因为不同工具解决的其实不是同一层问题。

行情层决定系统能看到什么

监控从数据开始。价格预警只需要最新价，自定义指标通常还要K线和成交量，观察盘口则会涉及分笔或更细的数据。数据粒度越高，更新频率、计算量和状态管理越复杂。在这条链路中，迅投QMT的作用是把分笔、K线、成交额和盘口等行情字段交给策略代码。开发者可以按自己的算法处理数据，同时也要负责订阅、缓存和程序运行状态。这正是代码型监控自由度较高，却需要持续维护的原因。

条件层决定系统如何判断

把条件层落到工具上时，我会先看规则复杂度。只监控到价、止盈止损等明确条件，券商APP的基础条件单已经能完成任务，点选操作也减少了配置成本。规则涉及多品种联动或多个指标共同计算时，QMT可以用Python直接表达判断逻辑，但开发和维护成本随之增加。水母量化适合处在两者之间的需求：用选股器确定范围，再让策略单监控具体条件，从而把筛选与触发连起来。它降低了编程门槛，但高度封装也会减少部分自定义空间。

银河证券

状态层比触发信号更容易被忽略

不少监控方案只关心“条件有没有成立”，上线后才发现真正难查的是策略状态。程序是否持续运行，行情时间戳是否更新，同一信号是否重复触发，股票是否已进入下一个股票池，这些信息都应留下记录。对代码策略，可以在日志中保存标的、时间、输入值和判断结果；对条件单或可视化策略，也要能查看启停状态、触发记录和当前监控对象。没有状态信息，出现漏信号时很难判断问题在数据还是规则。

交易反馈要与信号分开记录

信号出现不等于交易完成。实时监控还需要区分信号时间、委托时间、委托状态和成交结果。这里选择什么工具并不重要，关键是能否取得对应反馈：券商APP可以返回条件单触发和委托结果，QMT可在模型交易中查询委托与成交，水母量化则把策略单触发和后续动作接入同一流程。实现时仍要把“条件成立”和“交易落地”保存为两个事件。这样复盘才能判断偏差来自策略计算、执行延迟，还是委托没有成交。

水母量化实时监控

选工具前先做一张需求清单

我的做法是先写下监控对象、数据粒度、判断频率、触发动作和需要保留的状态，再把需求对应到实现方式。固定价位交给券商条件单，自定义计算交给QMT一类本地终端，选股与条件触发的可视化串联则可以使用组件化平台。这样写并不是给软件排顺序，而是避免用复杂工具解决简单问题，也避免基础条件单承担它无法表达的逻辑。股票实时监控的重点始终是数据、判断、状态和反馈能否形成闭环。