2. 盘口数据基础与多股票同步采集
做多股票盘口联动对照，第一步不是画图，而是把“同一时刻”这件事在数据层面定义清楚。不同股票、不同行情源、不同推送通道，数据到达本机的时间天然存在差异；如果直接按接收顺序拼接，看到的“联动”很可能只是网络抖动造成的假象。本节围绕盘口字段、时间戳对齐和多股票同步采集三件事展开，目标是让读者能独立搭起一条可复现的采集链路。
一、Level-1 与 Level-2 盘口字段的差异
Level-1 是最基础的行情快照，通常包含最新价、昨收价、开盘价、最高价、最低价、成交量、成交额，以及买一卖一的价格与挂单量。它每 3 秒左右推送一次快照，字段少、带宽低，适合做粗粒度的联动观察，但看不到盘口内部的挂单结构。
Level-2 在 Level-1 基础上扩展了逐笔成交和十档（或更多档）委托队列，典型字段包括：买一至买十、卖一至卖十的价格与数量，逐笔成交的成交价、成交量、成交方向（主动买/主动卖），以及委托明细中的委托价格、委托数量和买卖方向。Level-2 的更新频率可达毫秒级，数据量大，是观察盘口联动的核心数据源。实际接入时要注意，不同数据商对“十档”的档位数量、逐笔成交是否合并、委托队列是否含撤单等细节定义并不一致，字段映射必须逐项核对，不能想当然地按同名对齐。
二、时间戳对齐：三种时间基准要分清
盘口数据至少涉及三种时间：交易所撮合时间（交易所时间戳）、行情商服务器打标时间、本机接收时间。三者含义不同，混用会直接破坏对齐结果。交易所时间戳最接近“事件真实发生时刻”，但经过行情商转发后可能被截断精度或重新打标；本机接收时间受网络延迟和本地时钟偏差影响，只能作为兜底参考。
对齐的实用做法是：优先使用行情源提供的交易所时间戳作为主键，统一转换为同一时区、同一精度（例如毫秒），再按股票代码分组排序。对于只有本机接收时间的源，需要先做时钟同步（如 NTP 校时），并记录每次采集的接收延迟分布，作为后续判断数据质量的依据。跨股票对照时，建议以“时间窗口”而非“单点时刻”做匹配：例如把每只股票在 [t, t+200ms] 内的快照归入同一窗口，再在窗口内取最近一条，避免因推送节奏不同导致某只股票在某一时刻“缺数据”。
三、多股票同步采集的工程方法
多股票采集的核心矛盾是“并发”与“有序”。推荐采用“单连接多订阅 + 本地统一事件队列”的结构：行情客户端与数据源建立一条（或少量）长连接，一次性订阅目标股票列表，所有推送进入同一个本地队列，由消费线程按时间戳归并后落盘。这样既减少了连接数，又保证了不同股票的数据在同一队列中按统一规则排序，便于后续对齐。
落盘格式建议采用“一行一条快照”的宽表或长表：宽表以时间为行、股票为列，适合直接做对照；长表以（时间、代码、字段）为行，适合灵活筛选。无论哪种，都必须保留原始时间戳、接收时间戳和数据源代码三个字段，便于回溯。采集过程中要记录订阅确认、心跳、断线重连等事件日志，否则出现数据缺口时无法判断是源端没推还是本地丢了。
# 采集配置示例（参数为教学假设值）
stocks: ["600000", "600036", "601318", "000001"]
source: level2_feed
fields: [last, bid1_px, bid1_vol, ask1_px, ask1_vol,
bid2_px, bid2_vol, ask2_px, ask2_vol]
time_key: exchange_ts_ms # 主时间戳，毫秒
fallback_key: recv_ts_ms # 兜底时间戳
window_ms: 200 # 对齐窗口
flush_interval_s: 5 # 落盘间隔
reconnect_backoff_s: [1, 2, 5, 10]四、常见数据源接入与校验
常见接入方式有三类：券商或行情商提供的 API/SDK、交易所授权的行情网关、以及公开的行情文件或网页接口。前两类稳定性和字段完整性较好，适合正式采集；第三类延迟和字段定义不稳定，只适合做辅助验证。接入时先做小样本校验：订阅 3～5 只股票，采集 10 分钟，检查每只股票的推送频率是否与源端声明一致、时间戳是否单调、买卖档位是否连续、有无重复或跳变。校验通过后再扩大股票池。
下面这张图把“多源接入—统一时间基准—窗口对齐—联动对照”的链路画在一起，重点看时间戳在哪个环节被统一，以及窗口对齐发生在落盘之前还是之后。
五、采集质量的判断依据
采集完成后，不要急着做联动分析，先看三个指标：一是每只股票的推送间隔分布，若某只股票间隔明显偏大，说明订阅或源端有问题；二是时间戳单调性，出现回退说明存在乱序或时钟问题；三是窗口内缺数据的比例，比例过高时联动对照的结论不可靠。把这三项做成每日采集报告，比事后排查省力得多。只有数据在时间上可信，多股票盘口联动对照才有意义。