实时行情API选型：从延迟到数据质量，量化实盘避坑指南

搞量化的人，几乎都会走到选行情API这一步。尤其当你准备把手里的策略从回测挪到实盘，一定会到处搜“实时行情API”，然后发现市面上的选择多到眼花：免费的、收费的、国内源、海外源，有的号称毫秒级推送，有的用websocket给你推tick。但我要先把话说在前面：有实时数据，和你的量化实盘真正能用，中间隔着的距离，比很多新手想的要大得多。这篇文章就用我自己的选型经历，把这里面的门道掰开揉碎讲一遍，希望你能少走点弯路。

1. 先把需求说清楚：你是“行情围观者”还是“实盘交易者”

1.1 同样是“实时行情”，背后是完全不同的链路

很多人一搜实时行情API，默认就是找一个能把行情推给我的接口，接到程序里就能用。这个想法本身没错，但它忽略了一个关键问题：行情从交易所到你的策略进程，中间要过很多道手。交易所撮合引擎产生行情后，先到行情网关或数据商机房，数据商做清洗、组装、广播，再通过公网或专线推到你的服务器，你的程序还要解码、缓存、对齐。这个链条上每一环都在消耗时间，每一环都有可能丢数据。

我之前帮朋友看一个所谓的“毫秒级实时行情API”，他拿来做开盘前几分钟的盯盘工具，没什么问题。但同一个API接到实盘策略里，盘中瞬间出现的价格跳变，策略下单时用的已经是几十毫秒之前的价格快照，对某些高频套利策略来说，这几十毫秒就是亏损的全部来源。所以第一步不是选API，而是先承认一个事实：你看盘的实时，和策略需要的实时，不是同一个东西。

1.2 自用研究、策略回测、实盘自动下单，需求根本不是一回事

同样是接入行情，用途不一样，对API的要求能差出好几个数量级。只做盘后研究，比如每天收盘后分析一下当天分钟线，那你只需要一个稳定的历史数据接口就行，实时推送反而没那么关键。如果做策略回测，你需要的是连续、完整、经过复权处理的历史序列，还得能按时间点切分，方便你把策略放在不同市场状态下跑。可一旦到实盘自动下单，数据源就成了交易系统的一部分，它必须和你的风控、下单、持仓模块协同工作。

我用过不少行情源，最大的感受是：研究阶段容忍度很高，缺几根K线、偶尔断流，重新拉一下就行；实盘阶段完全不是这个逻辑，断流一分钟，你可能错过一波行情，或者更糟，触发风控把仓位砍掉。所以后面我会反复强调一件事：选行情API，先给它的使用场景定性，再谈其他指标。否则你很可能买了一个便宜的“实时数据”，却付了比它贵得多的隐性成本。

2. 实时行情API选型时容易被忽略的硬指标

2.1 延迟、快照、增量：三个词背后的真实差距

行情API最常见的一组分流是“快照”和“增量”。快照是某一时刻的全量市场状态，比如当前所有档位的买卖盘口；增量是这之后发生的变化，比如某价位新增了一笔委托。好一点的API会设计成“快照+增量流”配合：启动时先拿快照，之后靠增量流同步。但实现得不好的API，会在两者衔接处留下空档，要么重复推送，要么中间少一段，你的程序如果按增量累加盘口，很快就会和真实盘面越差越远。

延迟也要拆开看。API文档里写的“延迟低于XX毫秒”，通常指的是从它们机房到你服务器的时间，不包含数据来源、解码、网络抖动。我实测过一个宣称低延迟的行情服务，峰值时实际延迟比均值多了3到5倍，而且这个抖动完全不可预测。如果你的策略对延迟敏感，别只看平均延迟，要看95分位、99分位的延迟分布，最好直接在你的目标机房里做压测。

2.2 数据质量比“实时”两个字值钱得多

我会收到一些用户反馈，说API推送很及时，但盘中总出现一些诡异的价格：瞬间打到涨停又立刻拉回来，或者买卖盘口的量明显不连续。查下来大多是数据源在清洗环节出了问题。正规数据商一般会做基本的过滤和校验，比如剔除明显错误价格、标记异常状态、补齐交易时段标记。而一些免费或低价的API，只是把上游数据原样转发，甚至经过多层转发后，连原始价格的先后顺序都乱了。

在实盘场景里，这种脏数据比你收不到数据更危险。收不到行情，你至少知道系统有问题，可以暂停交易；收到一个虚假的瞬间价格，策略可能直接判定为极端行情，触发止损，把你的仓位打掉。这也是我为什么一直强调：数据质量校验必须由你这边再做一层，包括但不限于价格合理性检查、涨跌停状态识别、时间戳单调性检查。不要因为API标注了“实时”，就默认它里面的数字可信。

2.3 历史数据能力是实盘的隐藏门槛

实盘策略上线前，几乎都要做一轮全市场、长周期的回测和参数稳定性检验。这时候你会发现，很多实时行情API的历史数据能力非常弱：要么只给你最近几天，要么只有日线或分钟线，拿不到更细的tick级历史数据；要么复权因子处理得不清不楚，送你的价格序列里有大量因为除权除息造成的跳变。

我自己的做法是：在选行情API的阶段，就把历史数据需求一起列出来。回测需要什么样的频率？是否需要复权？要不要支持按日期批量导出？这些在采购前就要确认清楚。否则策略跑起来之后才发现历史数据不够，再换数据源，所有回测结果都得推倒重来，那个成本比行情API订阅费高多了。

3. 为什么“有实时数据”不等于量化实盘就够用了

3.1 实盘的第一杀手是“数据缺口”，而不是信号算错

很多人以为量化实盘最难的是策略逻辑，真跑起来才发现，系统崩溃、数据断流、下单失败才是最折磨人的事情。其中行情数据缺口几乎是所有实盘事故里最常见的。所谓缺口，不只是网络断线那种明显的中断，更多是这种：开盘瞬间流量大，上游行情网关过载，某个合约的数据丢了200毫秒；或者API服务端滚动重启，你的websocket连接被静默断开，重连之后增量流从中间开始，盘口就永远对不齐了。

我踩过一次印象很深的坑：用某个免费行情源做期权策略实盘，盘中某个合约的实时行情突然停止更新，但连接还活着，心跳也正常。策略端没发现异常，继续按最后一份快照计算，等到我发现时，已经用陈旧价格成交了几笔。后来我在所有行情模块里都加了“数据新鲜度”监控：如果超过一定时间没有新行情进来，立即告警并暂停相关品种的自动交易。这个机制比任何策略优化都值钱。

3.2 盘口深度、逐笔成交、涨跌停状态：实时之外的另一层

“实时数据”通常指的是行情更新频率，但实盘策略对行情“内容”的要求同样苛刻。普通行情API一般只给五档盘口和最近一笔成交，做简单的趋势策略够用。可如果你的策略要看十档盘口、委托队列、逐笔成交甚至撤单明细，就需要更高级别的数据产品。这个差距不是“实时”两个字能覆盖的。

另外还有交易状态的问题。每个交易时段都有开盘集合竞价、连续交易、收盘集合竞价、午间休市等状态。行情API如果在这些状态切换时不给你明确的标记，你的策略就容易在错误的时间做错误的事。比如把集合竞价的虚拟成交价当成连续交易价，触发一个本不该触发的信号。这些看起来都是细节，但在实盘里都是真金白银的教训。

3.3 交易执行链路：行情只是半边天，报单、撤单、成交回执都是数据

我最初也犯过这个错误：花了很多精力在行情API上，等实盘才发现，交易执行同样需要一整套数据接口。报单请求有没有到达交易所？有没有被拒单？撤单是不是成功？成交回报回来没有？这些信息如果不能及时、可靠地同步到你的系统里，策略就不知道它的订单到底是什么状态。

尤其是做日内或高频策略的人，下单和撤单频率很高，订单状态任何一个环节延迟或丢失，都可能导致重复下单或漏撤单。我见过一次事故：成交回报因为网络抖动晚了半秒，策略以为没成交，又下了一单，结果把本来一个小仓位打成了双倍。所以选实时行情API的同时，一定要把交易API的状态回报质量放在同等位置去评估。行情数据管的是“市场长什么样”，交易回报管的是“你自己干了什么”，两者缺一不可。

4. 量化实盘场景下的API选型实操清单

4.1 选型前先做一张需求表

我建议所有准备做实盘的朋友，在搜任何行情API之前，先花半小时填一张需求表，至少包括这几项：交易品种（股票、期货、期权、加密资产等）、策略交易频率（日频、分钟级、tick级）、对延迟的容忍度、是否需要盘口深度和逐笔数据、历史数据跨度要求、预算范围、部署环境（本机还是云服务器）、是否需要和现有交易系统直接对接。

这张表做完，很多问题会自己浮出来。比如你做的是日频选股，那就完全没必要为一个毫秒级tick推送的API付高溢价；如果你做的是期货日内高频，那免费API基本可以直接排除，因为它的延迟稳定性和数据完整性大概率撑不住。需求表不是流程上的形式主义，它是帮你把“实时行情”这个大词拆成具体可比较的指标，不然你只能在各种营销话术里打转。

4.2 免费源、付费源、券商柜台源的取舍

行情源大致可以分三类，各有各的坑和优势，我列个表方便对比：

我的看法是，不要一上来就追求最好最贵的，但也不要抱着免费源直接上实盘。一个比较稳妥的路径是：先用免费源把策略逻辑跑通，再用付费源或券商源做一轮模拟盘验证，重点观察数据是否连续、盘口是否一致、延迟是否满足要求。毕竟换行情API的成本不低，但更贵的是你在实盘阶段才发现数据源不行的代价。

4.3 灰度验证：用模拟盘和本地录制校验数据源

选定候选API后，不要急着接实盘。我一般会先做一轮灰度验证，大概三到五步：第一步，接入模拟盘或paper trading环境，跑至少一周；第二步，在本地录制原始行情流，包括消息到达时间、内容、顺序；第三步，每天收盘后把录制的数据和另一个独立数据源做对账，看有没有缺漏、重复、乱序；第四步，检查策略在模拟盘里的信号触发次数和预期是否一致；第五步，手动模拟断网、重连、服务重启，看数据模块能不能自动恢复且不丢数据。

这一步做下来，能过滤掉绝大多数“看起来实时、实际要命”的坑。我见过有人省掉灰度验证，直接用一个只经过简单demo测试的行情API上实盘，结果前两周就遇到多次数据断流和乱序，被迫临时切换数据源，整个交易系统跟着重写了一遍。行情数据这种基础设施，宁可多花一周验证，也不要赌它上线后不会出问题。

5. 常见问题与排查技巧实录

5.1 我踩过的实时行情坑

第一个坑是websocket连接被服务端静默断开。很多行情API用websocket推送数据，但服务端为了节省资源，会在空闲或滚动发布时断开连接，客户端如果不做心跳探测和自动重连，就发现不了断线。对策是客户端必须自己维护心跳，定时发ping，并且重连成功后要做一次数据对齐或重新订阅。

第二个坑是主力和约切换。有些品种到交割日会换合约，主力合约的标识会变。如果API返回的合约标识不稳定，你的策略可能盯着一个已经停止交易的合约计算，盘中没有任何提示。需要定期同步合约列表，并在合约状态变更时及时切换。

第三个坑是时间戳不统一。有的API给的是交易所时间，有的是服务器接收时间，有的带时区不带毫秒。如果你的策略需要把行情和成交回报按时间对齐，时间戳体系不统一会造成大量错位。必须建立统一的时间轴，并在入库前做标准化。

5.2 排查思路速查表

平时遇到行情异常，我按这个顺序排查：先看本地网络和服务端连接状态，再查API返回的状态码，然后看数据流是否有心跳、是否有新数据推进，最后对比一个独立行情源确认是不是上游问题。为了方便复盘，我把常见问题整理了个表，供大家参考：

5.3 独家避坑技巧

最后分享一个我自己一直在用的技巧：无论用哪个行情源，都在本地单独保存一份原始行情归档。不要只保存加工后的K线或信号，原始的逐笔、快照、消息时间戳全都留底。这样一旦盘中出了什么诡异问题，你可以事后用归档数据完整回放，定位问题到底出在数据源、网络还是策略逻辑。这个习惯帮我省了无数次“背锅式排查”。

另外一个技巧是，尽量让行情模块和策略模块解耦。行情API挂了，交易程序不应该立刻崩溃，而是进入降级模式，暂停相关品种开仓，保留撤单能力。这个设计一开始就要做进去，临时补的话很容易留下漏网之鱼。我在实际项目里见过太多人盯着“实时”两个字，把行情API选成了整个系统的瓶颈，其实行情数据的实时推送只是第一步，它后面连着数据质量、历史回放、状态管理、交易回报一整套链路，任何一个环节不给力，实盘都会出问题。所以我评估行情服务商时，第一件事不是问“你们是不是实时”，而是问“断线之后你们怎么处理，数据有没有保障，能不能让我完整复盘”。把这些问题都问清楚，你的量化实盘才算是真正踩到了地上。