A股投资者必备：三大数据源对比，哪种最适合实时行情与回测？
TickDB Research ·
A股投资者必备：三大数据源对比，哪种最适合实时行情与回测？
做一个自选股看板，和回测一套跨越数年的策略，看起来都需要“股票数据”，真正需要解决的问题却差得很远。
看板关心最新价格什么时候到、断线后能不能恢复；回测关心历史数据是否完整、复权口径是否一致，以及当时究竟能知道哪些信息。如果只比较“有没有实时行情”“能不能下载 K 线”，很容易选到能跑示例、却不适合自己任务的接口。
本文选择 AKShare、Tushare Pro、TickDB 三种接入方案，比较范围限定为 A 股行情与价格策略回测。它们并非同一种产品形态：AKShare 是数据接口工具库，Tushare Pro 和 TickDB 提供数据服务。这里的“三大”仅指本次选取的三个对象，不代表市场份额或行业排名。
先给出选择方向：学习采集、验证小规模原型，可以从 AKShare 开始；以历史数据批量入库和回测为主，优先考察 Tushare Pro；明确需要 WebSocket 持续行情推送，可以重点验证 TickDB。这些是按接口形态作出的试接建议，最终选择还要通过数据覆盖与运行测试。
一、把“实时”拆开，才能比较得公平
“现在能查到一个价格”与“持续接收价格变化”，对应不同的数据消费方式。
快照查询是客户端发起请求，服务端返回当前状态。需要定时刷新时，由程序安排下一次请求。持续推送是在建立连接并订阅后，由服务端陆续发送消息，客户端负责处理消息、监测连接和恢复订阅。
还有第三种容易混淆的数据：正在形成的 K 线。上午查询到的当日最高价和成交量，只描述查询时刻之前的状态，不是当天的最终结果。
因此，实时选型要问的是“更新如何抵达应用”，回测选型要问的是“这一条记录在策略决策时是否已经确定”。REST 或 WebSocket 只描述接入方式，不能直接证明行情延迟、完整性或成交可执行性。
图 1：实时观察与历史回测需要不同的数据处理路径。此图为建议设计示意，不是任一供应商的系统架构。
二、三种方案，各自适合从哪里开始
AKShare：适合先把采集和分析流程搭起来
以东财接口为例，stock_zh_a_spot_em 获取沪深京 A 股行情快照，stock_zh_a_hist 提供日频历史行情及复权选项。需要分钟数据时，要单独核对接口范围：stock_zh_a_hist_min_em 的 1 分钟数据仅覆盖近 5 个交易日，且不复权。这是该接口的限制，不能外推成整个 AKShare 的统一历史深度。AKShare 股票接口文档
对入门项目，我更建议先用少量股票完成“读取、保存、画图、重跑”的闭环。真正值得验证的是：程序隔天还能否重跑、接口变化后能否定位问题、已经保存的数据能否继续使用。
把工具库作为数据入口时，也要保留具体上游和接口名称。两个都通过同一工具库返回的 DataFrame，不一定具有相同的单位、时间含义或更新节奏。
Tushare Pro：适合围绕明确的数据接口建立研究库
Tushare 的 daily 提供未复权日线；官方说明其在交易日收盘后入库，停牌期间不提供记录。adj_factor 则提供复权因子，两者可以分别保存，便于研究中核对复权过程。日线文档、复权因子文档
如果任务是多年分钟回测，stk_mins 值得优先验证：文档列出 1、5、15、30、60 分钟周期，注明可提供超过 10 年的历史分钟数据，但需要单独开权限。这个描述不等于每只股票都有完整十年记录；上市时间、目标时间段和实际返回覆盖仍要逐项检查。历史分钟文档
同时，不应把 Tushare 简化为“只有盘后数据”。rt_k 已提供实时日线，包含当日最新状态，也需要单独申请相应权限。它适不适合你的盘中看板，要按该接口的实际更新与调用条件判断。实时日线文档
这种入口适合把研究需求拆成明确的数据表，再安排增量更新。选择前先列出必需接口及权限，避免拿到日线后，才发现分钟或其他配套数据需要另外开通。
TickDB：需要持续推送时，重点验证订阅与恢复
TickDB 的 A 股全量行情文档明确提供 WebSocket 订阅：先分批发送快照，再推送发生变化的行情。该能力要求 A 股全量或企业版权限，并需要在握手时成功协商 permessage-deflate 压缩，不能从“能连接 WebSocket”直接推断“能订阅全市场”。A 股全量行情文档
历史侧，K 线查询支持 A 股及不复权、前复权、后复权。但文档同时提醒：最后一根可能仍在形成；免费版不能指定起止时间查询。因此，能返回最近一段 K 线，并不等于已经满足按指定区间回测的要求。K 线查询文档
对于实时应用，推送入口的价值在于可以按消息驱动更新。工程代价也很具体：重连后要重新订阅，恢复快照要正确覆盖本地状态，恢复期间要让应用知道数据尚未追平。官方最佳实践同样要求重连后恢复订阅。WebSocket 连接管理
三、把选型结果写成“条件”，而不是总分榜
| 你的主要任务 | 建议先验证的方案 | 决定能否采用的条件 |
|---|---|---|
| 学习采集、少量股票原型 | AKShare | 所选接口覆盖目标区间，重跑与异常处理可接受 |
| 历史日线研究、多年分钟回测 | Tushare Pro | 已具备对应权限，历史覆盖、单位和复权口径验收通过 |
| 持续行情看板、消息驱动告警 | TickDB | 订阅权限匹配规模，更新时效和断线恢复达到要求 |
这张表给的是试接起点。它不表示 AKShare 不能做回测、Tushare 不能做实时，或 TickDB 在历史数据方面天然更好。本次没有进行三家同条件延迟测试，也没有足够证据给出“最快”“最稳”或“最低成本”的排名。
成本也要按完成任务的总投入计算：所需接口权限、调用与订阅容量、首次历史回补、日常维护，都会影响最终选择。只比较一个套餐数字，容易漏掉最费时间的部分。
四、回测前，先拦住三个常见的数据错误
1. 同名字段不代表同一单位
一个很实际的例子是 Tushare 自身的接口差异：daily 的成交量单位为手、成交额为千元；rt_k 与 stk_mins 的对应单位则为股、元。适配规则必须绑定到具体接口，而不能只写一个“Tushare 转换函数”。日线字段、实时日线字段、分钟字段
下面用模拟数字演示成交额归一化，不调用任何线上服务：
from decimal import Decimal
def amount_yuan(value, unit):
scales = {"元": Decimal("1"), "千元": Decimal("1000")}
if unit not in scales:
raise ValueError("成交额单位未确认")
amount = Decimal(str(value))
if not amount.is_finite() or amount < 0:
raise ValueError("成交额必须是有限非负数")
return amount * scales[unit]
# 两条模拟记录描述相同成交额，不是供应商实测结果。
assert amount_yuan("1234.5", "千元") == amount_yuan("1234500", "元")
如果直接把两个原始 amount 字段拼起来，同一笔规模会相差 1000 倍。策略中的成交额筛选、流动性门槛就会被单位错误改变。价格精度、成交量和时区，也应在入库前采用同样的显式规则。
2. 图上的复权价格，不应直接当作成交价格
复权序列有助于处理公司行动带来的价格不连续，但必须保存采用的口径、计算依据和获取时间。TickDB 文档明确提醒复权历史可能随公司行动或数据更新而调整，并提供单独的复权因子接口。K 线说明、复权因子说明
一个更便于复现的组织方式是：保存原始价格，保留因子版本，再生成研究所需的复权序列。用于指标计算的价格，与用于模拟下单成交、处理现金分红和持仓变化的价格及事件，要分清职责。
是否存在未来信息，也需要检查策略如何使用这些数据，不能仅凭“用了前复权”四个字作判断。尤其是绝对价格阈值、历史财务筛选和指数成分筛选，应确认所用信息在当时是否已经可得。
3. “有一根 K 线”不等于“这根 K 线可以用了”
以 10:03 查询一根 10:00—10:05 的 K 线为例，它还会继续变化。若把之后才确定的最高价或收盘价拿去决定 10:03 的交易，回测就提前看到了未来。
处理时不要简单地“每次删掉最后一行”。休市后查询时，最后一行可能已经完整。应依据市场交易时段、时间戳对应的是周期起点还是终点、数据源更新状态，确认记录是否已经可用于当前决策。
建议给入库记录保留数据来源、原始代码、市场时间、接收时间、周期、单位和复权口径。缺失值与确认的零值分开保存；缺了一天时，先区分休市、停牌、尚未上市和采集失败，再决定是否补数。
图 2：先统一口径并保存版本，再进入策略回放。此图为数据准备方法示意，不代表回测收益或供应商质量结论。
五、用一个小样本，把“适合”变成可验证的结论
正式接入前，可以给三个候选方案使用同一份验收任务：挑选一只交易活跃股票、一只包含停牌区间的股票，以及一只覆盖除权除息事件的股票。行情类项目增加盘中连续观察；回测类项目覆盖普通交易日与事件前后区间。
验收不只看“请求成功”，还要留下可以复查的记录：
- 历史覆盖：列出预期交易日期与实际日期的差集，并解释缺口；不能用两份数据行数相同来代替日期核对。
- 字段一致性：先统一单位、复权和时段范围，再比较价格与量额差异；不同口径的差异不能直接判为数据错误。
- 实时状态：同时记录源时间与本地接收时间。只有源时间语义相同、机器时钟同步时，二者之差才有比较意义；否则只能报告本地观察到的更新间隔。
- 恢复能力：主动断开连接或暂停采集，观察恢复后能否补齐应用需要的状态；只恢复最新快照，不代表已经找回丢失的逐笔事件。
- 可重复性：用保存的原始数据、转换规则和版本信息再跑一次，确认差异能够定位到输入或处理步骤。
如果目前只想把一个研究想法跑起来，先选容易接入且范围满足要求的入口；如果要做长期回测，把历史覆盖与可复现性放在前面；如果要做持续运行的盘中系统，把更新语义与故障恢复放在前面。
实时行情解决“现在发生了什么”，回测数据还要回答“当时能知道什么”。 三种方案都应该围绕这两个问题验收。先确定任务，再核对具体接口，通常比先找一个“全能数据源”更容易做出可靠选择。
官方资料参考
文中涉及的接口功能、数据单位、历史范围与权限条件，参考以下公开官方文档；各项说明对应的资料如下。
- AKShare 股票数据文档：实时与历史行情接口。对应东财行情快照、历史日线及 1 分钟数据的查询范围与复权限制。
- Tushare Pro 日线与复权文档：A 股日线行情、复权因子。对应日线入库、停牌记录、成交量与成交额单位，以及复权因子的获取方式。
- Tushare Pro 分钟与实时文档：股票历史分钟行情、A 股实时日线。对应分钟周期、历史覆盖说明、单独权限及实时字段单位。
- TickDB 行情订阅文档：A 股全量行情、WebSocket 连接管理。对应快照与增量推送、全量权限、压缩协商和重连订阅。
- TickDB K 线与复权文档：K 线查询、复权因子。对应查询条件、复权方式、末根 K 线状态及复权因子的计算说明。