搞量化的人几乎都会走到选行情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返回的状态码然后看数据流是否有心跳、是否有新数据推进最后对比一个独立行情源确认是不是上游问题。为了方便复盘我把常见问题整理了个表供大家参考现象可能原因排查思路连接正常但行情很久不更新服务端静默断开 / 订阅失败检查心跳、重新订阅、查看服务端日志行情数据乱序多通道推送未做排序在客户端按时间戳排序丢弃过期数据价格瞬间跳动后又回落上游脏数据未清洗增加价格跳变过滤、涨跌停状态检查重连后盘口数量和真实盘面对不上增量流从中间开始重连后强制拉一次全量快照再续增量API返回400/401/429/503参数错误 / 鉴权失败 / 限流 / 过载检查鉴权信息、请求频率做退避重试收盘后合约代码找不到合约切换或退市定期同步合约列表做好映射5.3 独家避坑技巧最后分享一个我自己一直在用的技巧无论用哪个行情源都在本地单独保存一份原始行情归档。不要只保存加工后的K线或信号原始的逐笔、快照、消息时间戳全都留底。这样一旦盘中出了什么诡异问题你可以事后用归档数据完整回放定位问题到底出在数据源、网络还是策略逻辑。这个习惯帮我省了无数次“背锅式排查”。另外一个技巧是尽量让行情模块和策略模块解耦。行情API挂了交易程序不应该立刻崩溃而是进入降级模式暂停相关品种开仓保留撤单能力。这个设计一开始就要做进去临时补的话很容易留下漏网之鱼。我在实际项目里见过太多人盯着“实时”两个字把行情API选成了整个系统的瓶颈其实行情数据的实时推送只是第一步它后面连着数据质量、历史回放、状态管理、交易回报一整套链路任何一个环节不给力实盘都会出问题。所以我评估行情服务商时第一件事不是问“你们是不是实时”而是问“断线之后你们怎么处理数据有没有保障能不能让我完整复盘”。把这些问题都问清楚你的量化实盘才算是真正踩到了地上。