股票行情API中停牌股票持续推送完整解决方案与最佳实践
问题：我通过 WebSocket 订阅实时行情数据时，发现部分停牌股票仍在持续推送信息，价格凝固、成交量为零。如何才能用更健壮的代码识别并过滤掉这些无效标的？不同行情接口的表现不一致，又该怎么统一处理？
最佳回答
这个问题在实时数据流处理中很典型。我们从实际需求、痛点分析、数据验证到最终落地方案，一步步拆解会比较清楚。
需求与痛点
核心诉求很直接：区分可交易活跃股和暂停交易标的。过滤逻辑不到位，指标计算会被污染，前端展示也会误判。早期很多做法仅靠价格变动来识别，但部分低流动性股票价格长时间不动，容易误杀。更棘手的是，接口持续推送无用数据，白白占用连接带宽和计算资源。
数据支撑：停牌行为的几种常见模式
结合主流行情接口的实际表现，停牌股票的推送行为大致可以分为以下几种：
| 模式 | 详细描述 | 判定难度 |
|---|---|---|
| 价格冻结 | 最新成交价不再更新 | 低（但不能单独作为依据） |
| 成交量归零 | 累计成交量不再增加 | 中 |
| 状态字段 | 直接提供 suspend 等标志位 | 低，最可靠 |
| 时间戳更新 | 推送时间继续，但无实际成交 | 无参考意义 |
因此，优先检查状态字段是最稳妥的方案；如果接口未提供该字段，则结合成交量和价格静默时长联合判断。
实战方案：分层处理与代码实现
建议将过滤逻辑拆分为三层：数据接收层直接过滤、业务计算层剔除、连接管理层取消订阅。
如果你的接口携带 suspend 字段（例如 AllTick），实现如下：
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()随后在计算模块中直接跳过停牌标的，同时检测到停牌时从订阅列表移除，降低整体负载。
不同接口的差异与应对
不同行情接口的行为差异悬殊：有的停牌后直接停止推送；有的通过状态码变化通知；还有的仅停止盘口更新但价格照常推送。通用的应对策略是：上线前先全量记录一段时间的数据，根据实际表现将股票分为三类：活跃股票、停牌股票、新上市/退市股票。然后针对每一类编写独立的处理逻辑。停牌过滤本质上属于数据清洗和状态同步的范畴，只要统一了分类标准和过滤规则，系统的稳定性就会显著提升。