股票 WebSocket 行情实战：解决停牌复牌 K 线断层，完整快照修复方案

前言

最近在做量化行情终端开发时踩了一个典型业务坑：个股停牌后复牌，K线出现明显时间空白断层，量化回测指标全部失真。
最开始我的实现逻辑很粗暴：只要长时间没有Tick推送，就判定接口断连，频繁重连WebSocket、批量拉取历史K线补数据。上线后不仅请求量暴涨、带宽浪费，还出现大量重复快照记录，数据校验报错频发。

经过多轮调试，我找到一套标准化解决方案：基于WebSocket订阅指令，解析报文自带的交易状态字段，单连接动态管理订阅，无需重建连接、不虚构停牌成交数据，自动修复停牌到复牌的完整时序快照。下文完整分享落地思路、踩坑点、可直接运行的Python代码。

一、核心概念说明

停牌复牌快照恢复定义

个股复牌第一条Tick到达后，读取本地持久化的停牌状态缓存，校验停牌区间历史快照完整性，仅补充交易状态标记，串联停牌前静态价格快照与复牌实时数据流。
和两种低效方案做区分：

1. 不销毁重建WebSocket连接，避免重连风暴；
2. 不依赖定时REST轮询拉取全量历史K线。

二、业务场景与参数复核对照表

三、开发高频踩坑总结（4类线上典型问题）

1. 停牌无Tick直接判定数据丢失，循环调用历史接口

现象：个股停牌期间无成交报文，程序无限循环拉取批量K线接口，消耗接口额度。
检测方式：解析每条Tick内置status字段，区分「交易暂停」和「链路异常断开」两种空白区间。
解决方案：仅status为正常交易且长期无数据时，才执行重连；停牌状态下停止历史数据补拉逻辑。

2. 复牌Tick入库未关联停牌记录，时序链条断裂

现象：数据库仅存在停牌前快照、复牌首条Tick，中间时间段无状态记录，图表出现缺口。
检测方式：查询标的完整时间轴，对比复牌时间与停牌结束时间是否连续。
解决方案：独立存储表记录每只个股停牌起止时间、停牌前收盘价；复牌数据入库时关联该表写入时序标记。

3. 多标的同步复牌，并行修复引发数据库写入竞态

现象：多只股票同日复牌，多线程并行执行修复逻辑，同一标的生成多条重复停牌记录。
检测方式：统计同一code+同一停牌周期下的数据条数，出现多条重复条目。
解决方案：单标的快照修复逻辑串行执行，数据库设置code+停牌起始时间联合唯一索引。

4. 品类地址混用，停牌状态字段无法解析

现象：股票标的使用加密货币WSS地址订阅，报文无status字段，无法识别停牌/复牌。
检测方式：核对接入域名，股票必须使用独立专用WebSocket地址。
解决方案：代码层做品类路由隔离，股票请求强制路由至股票专用WSS地址，拦截跨品类错误请求。

四、方案边界说明

本方案基于标准订阅指令cmd_id=22004实现，支持单条活跃WebSocket连接内动态增删标的、修复停牌时序；存在两处限制：

1. 无法跨多条WebSocket连接同步个股停牌状态；
2. 不会自动生成停牌期间模拟成交Tick，仅补充交易状态标记字段，不支持虚构行情数据。

五、完整可运行Python代码

importwebsocketsimportasyncioimportjsonfromdatetimeimportdatetime# 股票行情专用WSS地址，参考官方接口文档WSS_STOCK_URL="wss://quote.alltick.co/quote-stock-b-ws-api?token=YOUR_TOKEN"classStockQuoteClient:def__init__(self):self.ws=Noneself.subscriptions=set()# 本地缓存：key=股票code，存储停牌时间、停牌前价格、交易状态self.stock_status_cache={}asyncdefsend_subscribe(self,action:str,code_list:list):ifnotcode_list:returnpayload={"cmd_id":22004,"action":action,"code":code_list}awaitself.ws.send(json.dumps(payload))ifaction=="subscribe":[self.subscriptions.add(c)forcincode_list]elifaction=="unsubscribe":[self.subscriptions.discard(c)forcincode_list]defcheck_resume_repair(self,code:str,curr_status:str,trade_time:str):"""检测个股复牌，触发快照时序修复核心逻辑"""cache_info=self.stock_status_cache.get(code)ifnotcache_info:returnold_status=cache_info["status"]# 状态从停牌切换为正常交易，判定为复牌ifold_status=="suspend"andcurr_status=="normal":print(f"标的{code}复牌，启动历史快照时序校验")self.repair_snapshot_timeline(code,cache_info["suspend_start"],trade_time)self.stock_status_cache[code]["status"]="normal"defrepair_snapshot_timeline(self,code,suspend_start,resume_time):"""模拟时序修复，持久化停牌区间状态记录"""repair_record={"code":code,"suspend_start":suspend_start,"resume_time":resume_time,"pre_suspend_price":self.stock_status_cache[code]["last_price"],"status":"suspend_repaired"}# save_market_snapshot(repair_record) 此处替换为自己的持久化逻辑print("已写入停牌区间时序修复记录",repair_record)asyncdefon_open(self):# 初始化订阅标的init_codes=["NASDAQ:AAPL","HKEX:00700"]awaitself.send_subscribe("subscribe",init_codes)print("股票WebSocket连接建立，完成初始标的订阅")asyncdefon_message(self,raw_msg):ifnotraw_msg:returntry:data=json.loads(raw_msg)tick_data=data.get("data",{})code=tick_data.get("code")price=tick_data.get("price")trade_time=tick_data.get("time")status=tick_data.get("status","normal")# 空值守卫，过滤无效行情报文ifnotcodeorpricein(None,0)ornottrade_time:return# 更新本地标的状态缓存ifcodenotinself.stock_status_cache:self.stock_status_cache[code]={}self.stock_status_cache[code]["last_price"]=price self.stock_status_cache[code]["status"]=statusifstatus=="suspend"and"suspend_start"notinself.stock_status_cache[code]:self.stock_status_cache[code]["suspend_start"]=trade_time# 校验是否触发复牌修复逻辑self.check_resume_repair(code,status,trade_time)print(f"行情更新 |{code}价格:{price}交易状态:{status}")exceptExceptionase:print("行情报文解析异常",str(e))asyncdefon_error(self,err):print("WebSocket连接异常：",err)asyncdefon_close(self):print("股票WebSocket连接关闭")asyncdefconnect(self):try:asyncwithwebsockets.connect(WSS_STOCK_URL,ping_interval=10)asws:self.ws=wsawaitself.on_open()whileTrue:msg=awaitws.recv()awaitself.on_message(msg)exceptExceptionase:awaitself.on_error(e)awaitself.on_close()asyncdefrun_demo():client=StockQuoteClient()task=asyncio.create_task(client.connect())awaittaskif__name__=="__main__":asyncio.run(run_demo())

总结

对于量化回测、金融终端这类对数据连续性要求严苛的业务，停牌复牌的数据衔接是极易被忽略但影响极大的细节。完整解决方案需要三层逻辑配合：实时数据流状态监听、本地标的状态缓存、历史快照时序校验，才能彻底规避K线断层、指标计算失真等线上问题。
如果需要快速搭建覆盖股票、外汇、贵金属、加密货币全品类的标准化行情服务，AllTick API 统一规范的WebSocket订阅报文、完善的多语言示例代码，能够大幅降低特殊交易场景的适配与调试成本。