A股实时行情接口怎么选？从免费开源到生产级API——mootdx、Tushare、TickDB、Wind 6家数据源底层对比与验证指南

摘要：面对mootdx、akshare、TickDB、Tushare Pro、同花顺热点和Wind这6家A股实时行情数据源，选型的真正难题不是“谁最好”，而是“哪个在我的场景里最扛得住”。本文把6个方案从协议层、返回形式、字段校准、异常容错到隐性成本拆解到底层，给出一份你能立刻复现的5步验证清单。

选数据源这件事，有一种“推荐文陷阱”：每篇都把各家优点列一遍，看完觉得收获满满，合上文章却仍然不知道自己的脚本明天会不会在开盘时崩掉。

因为你读到的那些维度——全面、稳定、低延迟——都不是你能验证的。你不能验证的结论，就是别人的结论。

所以本文换一种做法：把6家主流方案按5个能直接操作的底层维度拆开，每拆一层都附带一个你能跑的测试。等你用自己的股票代码跑完，你自己的系统会告诉你该选谁。

6家方案速览

维度1：协议层——数据怎么到你手上

是什么

协议层指的是数据从服务端传递到你代码里的通信方式。主流行情数据协议有三种：HTTP请求-响应（你主动去拉）、TCP长连接（建立连接后持续传输）、WebSocket推送（服务端主动推给你）。

为什么它决定了稳定性的天花板

三种协议的核心差异是“拉”和“推”。HTTP轮询的延迟由轮询间隔决定，且每次请求都要完整走一遍网络握手，高频调用容易触发反爬。TCP长连接绕过了应用层反爬，但协议一旦被服务端变更，客户端就必须跟着改。WebSocket推送从物理上消除了轮询开销，数据到达最快，但客户端需要自己处理断线重连和心跳。

怎么判断

看文档里“获取实时行情”的方式：需要反复调用同一个函数，底层是HTTP轮询；需要先建立连接再持续读取，底层是TCP或WebSocket。如果文档没写清楚接入方式，这本身就是一个信号。

你能立刻做的测试：不写代码。打开候选方案的文档，找到“获取实时行情”的说明。如果它让你调一个封装好的函数，网络层已被处理好。如果它让你自己构造HTTP请求，你还要写重试、超时、断连恢复——这些与业务无关，却是生产系统里最容易出问题的地方。

维度2：返回形式——数据到你手上时长什么样

是什么

返回形式指的是你的代码调用接口后拿到的原始数据形态。常见的三种：结构化数据（JSON/DataFrame）、半结构化文本（用分隔符连接的字符串）、非结构化内容（HTML/混杂文本）。

为什么它决定了代码复杂度

解析代码是技术债的高发区。一段处理分隔符文本的解析逻辑，在标准情况下工作正常，但遇到某只股票停牌、字段为空或上游网站加了新字段时，就可能因为索引偏移而拿到错误数据。

更深远的影响是AI兼容性。如果你的系统未来要接入AI Agent，接口返回的数据必须能被Agent的函数调用机制直接消费——也就是纯净的JSON。如果返回的是分隔符文本，Agent需要额外的解析步骤，每次额外调用都增加延迟和失败概率。

!image.png

怎么判断

把原始返回直接print出来，看它能不能被一行代码消费。能直接json.loads()的是满分；需要用split()按分隔符拆开再按索引取值的，每多一个步骤就多一层出错可能。

一个社区已经验证的公开案例：腾讯财经的行情接口，字段索引43被国内大量教程标为“PB（市净率）”，社区实测发现真正的PB在索引46，索引43是振幅。这就是“按索引取分隔符文本”这种返回形式的固有风险——字段位置一变，你的代码悄无声息地拿到错误数据。

你能立刻做的测试：调一次接口，把返回结果直接print出来。如果是{"symbol":"600519.SH","last_price":1850.00}，你的Agent就能直接消费。如果是var hq_str_sh600519="开头的一长串，你需要写一个解析模块。

!image.png

实测：通过 tickdb.get_ticker 工具直接调用 600519.SH、000001.SZ、300750.SZ 的 A 股实时行情，返回结构化 JSON，可直接用于程序化处理。

维度3：字段校准——同一只股票跑出来的数据对得上吗

是什么

字段校准指的是用同一个股票代码、在同一个时刻，向不同数据源发起查询，然后逐字段比对返回结果。这不是比“谁快谁慢”，而是检查更基本的问题：不同源给出的last_price是同一个价格吗？volume用的是同一个单位吗？

为什么字段校准是选型的必做项

不同数据源对同一个字段的口径、单位、时间基准可能完全不同。这不是bug，而是每个源有自己的数据处理管线。如果你只接一个源，永远不会发现这种差异——等回测中发现异常时，已经跑了两个月的数据。

字段差异有三个来源：时间基准不同（交易所时间 vs 服务器时间）、单位不一致（股 vs 手，差100倍）、复权处理管线不同（原始价格 vs 前复权 vs 后复权）。

怎么拆解

选一只你熟悉的股票（600519.SH），对候选源做6个校准点的核对：

你能立刻做的测试：选两个候选源，用同一只股票（600519.SH）各调一次，对比last_price和volume。如果对不上，至少一个源需要校准——这个发现，在你用它跑回测之前解决，成本为零。

维度4：异常容错——不该出错的时候它怎么表现

是什么

异常容错指的是数据源在非标准情况下返回什么：交易时段外、调用频率超限、标的停牌、网络闪断。所有方案的文档都会写“高可用”，但在这些边界场景下真正返回什么，只有跑过才知道。

为什么这个维度容易被忽略

因为测试通常在交易时段进行。你第一次调接口是在某个工作日的上午10点，一切正常。上线后第一个周末，监控脚本凌晨报警——数据源在非交易时段返回了HTTP 500。这种问题在测试阶段遇不到，但一上线就变成每周两天的噪音。

异常容错能力取决于两个因素：一是服务端对“无数据”的定义方式（干净的做法是返回200+空data，粗糙的做法是返回500或超时）；二是限流机制的透明度（是否通过429状态码和Retry-After头告诉你要等多久）。

你能立刻做的测试：收盘后（15:30之后）调一次接口。如果返回报错或HTML乱码，你的系统就需要加一个“非交易时段判断”逻辑。如果返回200加空data，这一步就可以省略。

维度5：隐性成本——免费背后的真实账单

是什么

隐性成本指的是选型时没有写在预算表里、但未来一定会付出的代价。它不一定是货币，更多是时间、精力和系统在关键时刻挂掉带来的机会成本。

为什么只看显性价格会做出错误决策

免费源的逻辑是：你不用付钱，但要自己承担维护成本。上游网站改版、反爬升级、接口失效时，修复的责任在你。付费源的逻辑是：你付的钱买的是“确定性”——知道这个接口明天还能用，出问题有人负责，返回格式不会悄无声息地变。

把时间换算成成本。如果每小时时间值200元，每个月花2小时修数据源，一年就是4800元隐性成本，可能已超过一个付费方案的年费。你自己的场景决定了这个时间成本是多少。

关于免费和付费的选择逻辑：免费源的隐形成本是你未来要付的时间，而且这个时间是随机的，最可能在你最需要它的时候发生。如果你只是学习验证，这个成本可以接受。如果你要跑生产、接系统，你要的是确定性。用体验期，就是为了在决定之前用自己的symbol跑完验证，确认这个确定性是否存在。

你的场景该重点看哪几个维度

一张你就能跑起来的验证清单

选一个你正在评估的方案，按顺序跑这5步：

跑完怎么办：5项全部“过”的方案，可以在你的场景里进入下一轮评估。有“没过”的，不是方案不行，是它和你的需求不匹配。

!image.png

选型这件事，最值的30分钟，不是你读推荐文的那30分钟，而是你用自己的数据跑验证的那30分钟。

通过 TickDB API 获取实时行情数据

一个 API 接入外汇、加密货币、美股、港股、A股、贵金属和全球指数的实时行情。支持 WebSocket 低延迟推送，免费开始使用。