订阅行情时遇见“卡住”的股票？从现象到处理，一节课讲透

做行情开发的同学大概都踩过这个坑：某只股票明明停牌了，可你的行情接口还在持续给你推数据。这时候推的是什么？又该怎么优雅地处理？这节课我就用第一人称复盘自己的项目经历，从客户需求、投顾痛点，一路到数据支撑和服务升级，帮你把停牌股票处理的门道彻底理清。

需求背景：行情系统必须识别“不可交易”

不管是给自有策略喂数据，还是做投顾类工具，下游用户都依赖行情系统分辨一只股票到底能不能交易。如果系统不做区分，策略模块可能会把停牌股的价格继续纳入均线、涨幅等计算，导致信号失真。用户界面也会出现明明不能买卖的标的还在闪烁最新价，非常容易引起误操作。所以，我们的核心需求其实就是一个字——准。

痛点分析：那些让你怀疑数据的“假更新”

我曾接手过一个旧系统，它只用价格变化来判断活跃度。结果有几只停牌股停牌前拉了一波，停牌后价格停留在高点，且推送未断，时间戳还一秒不差地更新。系统误以为它们依然活跃，导致当天的龙头股统计里闯进了几个“躺平”的家伙。复盘时才发现，不仅统计异常，订阅流量也被这些无效推送抬高了近15%。这是缺少明确状态标志带来的典型问题。

数据表现：停牌股票在接口里的四种情况

为了一次性解决问题，我把多个数据源的停牌行为列了个表，基本涵盖所有遇到的形态：

光靠价格和成交量来判断很危险。一旦有状态字段，果断用它。

服务升级：我的三层处理策略

找到问题的本质后，我重新设计了处理流程，分为显示、计算和订阅管理三个层面。

显示升级：所有停牌股票在列表和详情页都强制呈现为“停牌”状态，底色变灰，交易按钮隐藏。这样即使用户看到最新价，也不会误解。

计算升级：在策略运算的入口处设置过滤器，条件为 is_suspend == True 或成交量连续N秒为零。过滤之后再计算板块涨跌、组合收益，数据质量马上提高。

订阅优化：长连接场景下，一旦识别出停牌状态，我会立即取消对该股票的订阅，释放连接和计算资源。市场上部分实时行情 API（比如 ALLTICK API ）的结构里就带有 suspend 字段，配合 WebSocket 使用，能很方便地实现这一层优化。

import websocket
import json

def on_message(ws, message):
    data = json.loads(message)
    for tick in data.get("ticks", []):
        if tick.get("suspend"):  # 判断是否停牌
            print(f"{tick['symbol']} 停牌中")
        else:
            print(f"{tick['symbol']} 最新价: {tick['last_price']}")

ws = websocket.WebSocketApp("wss://api.alltick.co/stock", on_message=on_message)
ws.run_forever()

补充细节：不同接口要分类对待

不是每个接口都有状态字段。有些直接停推，有些用特殊的状态码，还有些完全靠量和价。实战中我的做法是先用记录跑一天，把标的分成活跃、停牌、新上市/退市三类，分别管理订阅和历史数据。停牌处理本质是数据清洗和状态管理，清晰的分层逻辑能让系统稳定性提升一个档次。