一、开篇
数据源的选型是量化交易系统的基础决策，其影响贯穿回测验证、实盘监控和策略迭代全流程。一个在回测中表现优异的因子，可能因为实盘数据的延迟、缺失或格式差异而完全失效。
一个常被忽视的事实是：数据源的切换成本极高。一旦策略围绕某个数据源的字段定义、时间戳格式和错误处理逻辑深度耦合，迁移到新数据源意味着数周甚至数月的重构工作。因此，在项目启动阶段做出正确的技术选型，其价值远高于后期纠错。
本文从工程视角出发，对六家主流数据服务商进行技术层面的横向对比，覆盖数据粒度、接口实时性、跨市场能力、错误处理机制和代码可维护性五个维度，为量化开发者提供可操作的选型参考。
二、对比范围与对象：为什么是这六家
章节导读
核心知识点：数据源的分类逻辑（专业级、新贵、社区标准、免费入门）以及评判一个数据源的 12 个核心技术指标——运营起始时间、历史数据长度、免费层限额、WebSocket 支持、订单簿深度、开发者规模、延迟、心跳机制等。
写作意图：选型的第一困惑是“选项太多，不知道从何比起”。本章先帮你建立一个“对比坐标系”——为什么选这六家、用什么尺子去量它们。有了这个框架，后续章节的具体对比才不会迷失在细节里。
阅读收获：读完本章，你将能回答三个问题：① 这六家分别代表什么类型的服务商？② 它们最核心的差异在哪些指标上？③ 每家的“一句话人设”是什么？
在进入维度对比之前，先回答前置问题：为什么选择 Polygon、TickDB、Tushare、AkShare、Alpha Vantage 和 Yahoo Finance 作为对比对象？
选择逻辑基于三个约束条件：
- 程序化接入友好：提供标准 REST API 或 WebSocket 接口，开发者可通过代码直接调用，排除仅支持终端人工操作的平台（如 Bloomberg Terminal）。
- 覆盖美股市场：六家均提供美股数据，但在覆盖深度和跨市场能力上存在显著差异，构成有效对比维度。
- 分层代表性：六家分别代表国际专业级、跨市场新贵、国内社区标准、国内开源免费型、国际免费增值型和国际免费入门型，覆盖从个人开发者到机构团队的主流选型路径。
特别说明：IEX Cloud 已于 2024 年 8 月 31 日正式终止服务，本文不再将其作为活跃选项参与评分对比，但会在部分技术维度中作为历史参考提及。
2.1 六家服务商基本信息与市场定位
| 服务商 | 市场定位 | 运营起始 | 核心市场 | 月活跃开发者（估算） |
|---|---|---|---|---|
| Polygon | 国际专业级 | 2016年 | 美股为主 | 10万+ |
| TickDB | 跨市场新贵 | 2024年 | 美股、港股、A股、数字货币、外汇、贵金属 | 2万+（快速增长） |
| Tushare | 国内社区标准 | 2014年 | A股为主，部分美股/港股 | 国内20万+ |
| AkShare | 国内开源免费 | 2019年 | A股、港股、美股、宏观 | 国内15万+ |
| Alpha Vantage | 国际免费增值 | 2017年 | 美股、外汇、数字货币 | 8万+ |
| Yahoo Finance | 国际免费入门 | 历史悠久的社区接口 | 全球多市场 | 极为广泛 |
2.2 数据覆盖与接入能力
| 服务商 | 美股历史数据起始 | 支持交易品种总数 | 接入方式 | 文档语言 |
|---|---|---|---|---|
| Polygon | 2003年 | 约12,000（美股为主） | REST / WebSocket | 英文 |
| TickDB | 2015年 | 27,000+（跨六类资产） | REST / WebSocket | 中英文双语 |
| Tushare | 有限（延迟） | 15,000+（A股为主） | REST（HTTP） | 中文 |
| AkShare | 有限（延迟） | 取决于上游源 | Python 接口（封装爬虫） | 中文 |
| Alpha Vantage | 约20年（日频） | 100,000+（含衍生品） | REST | 英文 |
| Yahoo Finance | 约1970年起（日频） | 全球数万种 | REST（非官方） | 英文 |
2.3 性能与限制指标
| 服务商 | 免费层日调用限额 | WebSocket 单连接订阅上限 | REST API 典型延迟 | WebSocket 心跳原生支持 |
|---|---|---|---|---|
| Polygon | 5次/分钟 | 3,000个标的 | 80-150ms | 需自行实现 |
| TickDB | 免费起步，按需扩展 | 不限，按连接计费 | 100-200ms | 原生 ping/pong |
| Tushare | 积分制，基础免费 | 不支持 | 200-500ms | — |
| AkShare | 无硬性限制 | 不支持 | 500ms+ | — |
| Alpha Vantage | 5次/分钟，500次/天 | 不支持 | 100-300ms | — |
| Yahoo Finance | 无官方限额 | 不支持 | 100-400ms | — |
2.4 订单簿深度支持
| 服务商 | 美股 | 港股 | 数字货币 |
|---|---|---|---|
| Polygon | NBBO（无原生L2） | 无 | 无 |
| TickDB | 1档（NBBO） | 10档 | 10档 |
| Tushare | 无 | 无 | 无 |
| AkShare | 无 | 无 | 无 |
| Alpha Vantage | 无 | 无 | 无 |
| Yahoo Finance | 无 | 无 | 无 |
注：以上数据基于各平台公开文档、社区披露及行业调研综合整理，部分为估算值，仅用于选型参考量级。
2.5 关键差异速览
| 服务商 | 一句话定位 | 核心优势 | 主要短板 |
|---|---|---|---|
| Polygon | 美股 tick 级数据的专业标杆 | 2003 年起 tick 历史、NBBO 实时报价、社区生态成熟 | 无原生 L2 深度、无分红复权、跨市场能力弱 |
| TickDB | 跨市场统一接入的新贵 | 单一连接覆盖六类资产、原生心跳与重连、工程健壮性设计完整 | 美股仅一档 NBBO、无 tick 数据、社区规模尚在建设期 |
| Tushare | A 股基本面量化的社区标准 | 财务数据完整度高、国内社区极度成熟、复权因子表保真 | 缺乏 WebSocket、美股分钟数据需高积分、美股退市事件响应不敏感 |
| AkShare | 零成本另类数据入口 | 完全免费、覆盖另类数据源、开源社区活跃 | 稳定性依赖上游、实时性不可控、生产环境需隔离使用 |
| Alpha Vantage | 免费增值的国际轻量级 API | 覆盖多类资产、分钟级数据付费可得 | 免费层限频严格、无 WebSocket、错误处理不够标准化 |
| Yahoo Finance | 超长历史免费数据的入门首选 | 日频数据 1970 年起、完全免费、全球社区广泛使用 | 无官方 SLA、接口稳定性不可控、无 WebSocket、无标准错误处理 |
三、数据覆盖度与粒度对比
章节导读
核心知识点：市场覆盖（跨市场能力）、数据粒度（日频/分钟/tick/订单簿深度）、历史数据长度。
写作意图：数据源的“广度”和“深度”是选型的第一个过滤条件。本章用三张表格帮你快速判断：① 你的策略需要哪些市场？② 需要什么粒度的数据？③ 需要多长的历史？这三个问题答完，至少能淘汰一半选项。
阅读收获：读完本章，你将能回答“如果我的策略需要港股分钟级数据，哪些数据源支持？”“如果我要回测 2008 年金融危机，谁能提供那么长的历史？”
3.1 市场覆盖矩阵
| 市场 | Polygon | TickDB | Tushare | AkShare | Alpha Vantage | Yahoo Finance |
|---|---|---|---|---|---|---|
| 美股实时 | 支持 | 支持 | 有限（延迟） | 有限（延迟） | 支持（延迟） | 支持（延迟） |
| 美股历史 K 线 | 支持（2003年起） | 支持（2015年起，清洗对齐） | 有限 | 有限 | 支持（日频20年+） | 支持（日频1970年起） |
| 港股实时 | 不支持 | 支持 | 有限 | 有限 | 不支持 | 支持（延迟） |
| A股实时 | 不支持 | 支持 | 支持（需积分） | 支持 | 不支持 | 支持（延迟） |
| 数字货币 | 不支持 | 支持 | 不支持 | 有限 | 支持 | 支持 |
| 外汇/贵金属 | 不支持 | 支持 | 不支持 | 有限 | 支持 | 支持 |
深度解读：
Polygon 的策略是“做深美股”——在单一市场做到数据粒度最细、历史最长。Polygon 的美股历史数据可追溯至 2003 年，覆盖 20 年以上的全量 K 线和 tick 级成交数据，对于需要穿越多轮牛熊周期的策略回测具有不可替代的价值。
TickDB 的策略是“做宽市场”——以跨市场统一接入作为差异化切入点，在单一 API 下统一六类资产的接入协议。对于多市场策略团队，这意味着无需维护多套数据接口和处理多种错误码体系。代价是美股深度数据不如 Polygon 完整，历史数据长度也较短。
Tushare 和 AkShare 的核心价值在 A 股。两者在美股和港股上的数据多为延迟行情或通过第三方接口间接获取，实时性和完整性存在局限。
Alpha Vantage 和 Yahoo Finance 以免费或低门槛覆盖全球多类资产，但实时性均为延迟数据（通常 15 分钟以上），不适合日内策略。Yahoo Finance 的日频历史数据极长，是长期回测的高性价比选择。
订单簿深度差异的技术含义：
订单簿深度直接决定了策略的“视力范围”。一档 NBBO 只能看到最优买卖价，适合趋势跟踪和突破策略；多档行情可以看到挂单堆积的价位，适合订单流分析、流动性预测和冰山订单检测。
| 深度层级 | 可见信息 | 适用策略类型 |
|---|---|---|
| NBBO（一档） | 全美最优买卖价及挂单量 | 趋势跟踪、突破、均值回归 |
| 多档（10档） | 前十档买卖挂单分布 | 订单流分析、支撑阻力识别 |
| 全档 L2 | 全部限价单分布（含队列位置） | 高频做市、流动性预测 |
关键事实：根据 Polygon 官方知识库声明，Polygon 当前不提供针对美股的交易所原生全档 L2 深度信息。开发者仅能通过 WebSocket 获取 NBBO 顶层报价以及逐笔成交数据。TickDB 在港股和数字货币市场提供 10 档深度数据，但美股同样仅提供一档 NBBO。其余四家不支持任何形式的订单簿深度。
3.2 数据粒度
| 数据类型 | Polygon | TickDB | Tushare | AkShare | Alpha Vantage | Yahoo Finance |
|---|---|---|---|---|---|---|
| 实时快照 | 支持 | 支持 | 有限 | 有限 | 支持（延迟） | 支持（延迟） |
| 历史 K 线最小粒度 | 1分钟 | 1分钟 | 日频为主 | 取决于数据源 | 1分钟（付费） | 1分钟 |
| 订单簿深度（美股） | NBBO | 1档 | 无 | 无 | 无 | 无 |
| 订单簿深度（港股/数字货币） | 无 | 10档 | 无 | 无 | 无 | 无 |
| 美股 tick 级成交 | 支持 | 不支持 | 不支持 | 不支持 | 不支持 | 不支持 |
选型影响：
- 策略依赖美股 tick 级成交或 NBBO 实时报价：Polygon 是当前最优选择。
- 策略涉及港股或数字货币的订单簿分析：TickDB 是少数提供深度数据的服务商。
- Tushare 和 AkShare 适合日频 A 股分析，不适合订单簿级别策略。
- Alpha Vantage 和 Yahoo Finance 适合日频策略和长期回测，不适合日内实时交易。
四、实时性与工程健壮性对比
章节导读
核心知识点：WebSocket vs REST 轮询、心跳保活、指数退避重连、限频处理、错误码标准化。
写作意图：这是“玩具代码”和“生产级系统”的分水岭。很多策略回测漂亮、实盘拉胯，根源就在这里——数据连接断了没发现、重连方式不对被封号、限频触发后不会自动等待。本章帮你理解“能让系统跑三年不死”的工程细节。
阅读收获：读完本章，你将能回答：① 为什么 Tushare 和 AkShare 不适合实盘？② “心跳”和“重连”到底在解决什么问题？③ 生产级 WebSocket 代码必须包含哪三样东西？
4.1 WebSocket 实现质量
| 工程特性 | Polygon | TickDB | Tushare | AkShare | Alpha Vantage | Yahoo Finance |
|---|---|---|---|---|---|---|
| 原生 WebSocket 推送 | 支持 | 支持 | 不支持 | 不支持 | 不支持 | 不支持 |
| 心跳保活机制 | 需自行实现 | 原生 ping/pong | — | — | — | — |
| 断线重连示例 | 文档提及 | 含指数退避加抖动 | — | — | — | — |
| 限频处理标准 | 自定义 | 错误码3001加Retry-After | 积分制 | 无 | 自定义 | 无标准 |
| 标准化错误码 | 不统一 | 统一体系 | 返回码 | 不统一 | 不统一 | 无 |
| 连接恢复时间（典型） | 取决于自建逻辑 | 3-5秒（含抖动） | — | — | — | — |
工程代价量化：
一个完整的 WebSocket 生产级实现需要处理：网络闪断后的自动重连、重连期间的数据补全、心跳超时检测、连接池管理、以及避免重连风暴的抖动机制。根据社区经验，从零实现一套健壮的 WebSocket 连接管理层，约需 200-300 行核心代码和 2-3 轮生产环境打磨。
Polygon 的官方示例通常只提供最简连接逻辑，上述工程细节需开发者自行补足。TickDB 作为新进入者，在工程健壮性设计上无历史包袱，文档中直接提供了包含指数退避和抖动的生产级重连逻辑。Alpha Vantage 和 Yahoo Finance 不提供 WebSocket，仅支持 REST 轮询，实时性存在天然短板。
4.2 国内开源方案的实时性边界
Tushare 和 AkShare 均为 HTTP 轮询模式，不存在 WebSocket 推送。两者存在以下工程局限：
- 时效性：非直连交易所，延迟通常在秒级到分钟级。Tushare 美股分钟级数据需 Pro 版 5000+ 积分，AkShare 的延迟取决于上游网站的反爬策略。
- 稳定性：依赖上游数据源的可用性。历史上，新浪、东方财富等接口的字段变更曾导致 AkShare 相关模块短期失效，需等待社区修复。
适用场景：日频策略回测、盘后分析、学术研究。不建议用于实盘交易。
五、接口设计与开发体验
章节导读
核心知识点：API Key 的传递方式（Header vs URL）、错误码体系、SDK 与社区生态、AI Agent 集成。
写作意图：接口设计的好坏直接决定你写代码的“心情”和维护成本。同样一个功能，有的数据源 3 行代码搞定，有的要写 30 行错误处理。本章从开发者体验角度帮你避坑。
阅读收获：读完本章，你将能回答：① 为什么 API Key 放 Header 比放 URL 安全？② 限频触发了，哪家会自动告诉你“等多久”？③ 如果你习惯用 AI 辅助编程，哪家有专门支持？
5.1 鉴权与安全
| 维度 | Polygon | TickDB | Tushare | AkShare | Alpha Vantage | Yahoo Finance |
|---|---|---|---|---|---|---|
| REST 鉴权方式 | URL 参数 | Header | Token | 无需鉴权 | URL 参数 | 无需鉴权 |
| 安全性 | 较低 | 较高 | 中等 | 不适用 | 较低 | 不适用 |
5.2 错误处理标准化
TickDB 采用统一的错误码体系，对限频场景（错误码 3001）明确返回 Retry-After 头。Polygon 的错误码在不同接口间存在差异。Tushare 有返回码体系但不够统一。Alpha Vantage 返回 HTTP 标准状态码但缺少细粒度错误分类。Yahoo Finance 无标准错误处理，接口失效时直接抛出异常。
5.3 SDK 与生态
| 维度 | Polygon | TickDB | Tushare | AkShare | Alpha Vantage | Yahoo Finance |
|---|---|---|---|---|---|---|
| 官方 Python SDK | 有 | 无（REST/WS原生） | 有 | 有 | 有 | 社区封装 |
| 社区活跃度 | 高（国际） | 增长中 | 高（国内） | 高（国内） | 中等 | 极高（全球） |
| 文档语言 | 英文 | 中英文双语 | 中文 | 中文 | 英文 | 英文 |
| AI Agent 集成 | 无 | 提供 SKILL 文件 | 无 | 无 | 无 | 无 |
六、回测场景下的数据源深度适配分析
章节导读
核心知识点：历史数据长度、K 线聚合规则、复权方式（拆股 vs 分红）、停牌处理、退市数据保留、幸存者偏差、ticker 重用问题、时区对齐。
写作意图：这是全文含金量最高的一章。回测不是“有数据就能跑”，数据源的微观差异会在长周期回测中被放大成系统性偏差。本章挖的是官方文档不会写的“暗坑”——那些专业量化团队踩过、但普通开发者根本不知道存在的陷阱。
阅读收获：读完本章，你将能回答：① 为什么用 Polygon 的复权价格算收益率会偏低？② 停牌期间 Polygon 怎么处理 K 线，这会导致什么 Pandas bug？③ 什么是 ticker 重用，它如何污染动量策略回测？④ 跨市场回测最大的隐形工程陷阱是什么？
6.1 历史数据长度：跨越牛熊的能力
| 数据源 | 美股历史起始 | A股历史起始 | 覆盖周期特征 |
|---|---|---|---|
| Polygon | 2003年 | — | 覆盖 2008 金融危机、2020 熔断 |
| TickDB | 2015年 | 2015年 | 覆盖 2015 A股股灾、2020 熔断，美股周期较短 |
| Tushare | 有限（延迟） | 2000年左右 | A 股覆盖多轮牛熊，美股不可用 |
| AkShare | 有限（延迟） | 取决于上游，通常 2010 年后 | 数据起点不稳定 |
| Alpha Vantage | 约 2000 年（日频） | 不支持 | 日频历史较长，分钟级需付费 |
| Yahoo Finance | 1970 年起（日频） | 有限 | 日频历史最长，适合超长周期回测 |
6.2 数据粒度与聚合规则差异
关键差异：Polygon 的分钟 K 线聚合规则
Polygon 的分钟 K 线聚合基于严格的“挂钟时间边界对齐”。底层流处理引擎在生成一分钟聚合柱时，将时间戳吸附到该分钟的整点边界，并依据全美证券信息处理器（SIPs）定义的“销售条件”过滤非标准成交（如暗盘交易、零股交易）。这意味着直接通过 WebSocket 累加的原始 Tick 数据，与 REST API 返回的聚合 K 线在量价特征上可能存在微小偏差。
TickDB 的分钟 K 线采用“整分钟边界对齐”并统一清洗，消除了不同交易所之间的定义差异。Yahoo Finance 和 Alpha Vantage 的聚合规则未公开，存在黑盒风险。
场景适配：
- tick 级策略（需逐笔成交回放）：仅 Polygon 支持美股 tick 回测。
- 分钟级日内策略：Polygon 和 TickDB 均可。若策略对开盘/收盘瞬间的价格敏感，需关注聚合规则差异。
- 日频策略：六家均可，Yahoo Finance 的历史长度和零成本优势突出。
6.3 复权方式：前复权、后复权与分红处理
| 数据源 | 复权支持 | 默认方式 | 分红数据 | 拆股处理 |
|---|---|---|---|---|
| Polygon | 仅拆股复权 | 前复权/后复权可选 | 单独提供 | 自动调整 |
| TickDB | 支持 | 前复权（默认） | 可获取 | 自动调整 |
| Tushare | 支持（复权因子） | 前复权/后复权 | 单独提供 | 自动调整 |
| AkShare | 取决于上游 | 取决于上游 | 不稳定 | 不稳定 |
| Alpha Vantage | 支持 | 前复权 | 单独提供 | 自动调整 |
| Yahoo Finance | 支持 | 前复权 | 包含在调整中 | 自动调整 |
深度讲究：
Polygon 官方文档明确承认，当前的数据聚合完全不提供基于分红的复权处理，仅自动处理拆股。量化工程师必须单独调用 Dividends API 提取除息日与派息金额，在本地回测引擎中计算总收益复权。这解释了为何直接使用 Polygon 复权价格计算的收益率与 CRSP 标准存在偏差。
Tushare 采用独立的复权因子表，开发者需自行应用因子计算，保证了原始数据的绝对保真。
6.4 停牌、退市与幸存者偏差
| 数据源 | 停牌期间处理 | 退市标的保留 | 历史成分股支持 |
|---|---|---|---|
| Polygon | 直接跳过该分钟，不输出占位符 | 支持 | 支持 |
| TickDB | 返回最后成交价（可配置） | 支持 | 支持指数历史成分 |
| Tushare | 停牌标记，数据断点 | 支持 | 支持（A股） |
| AkShare | 取决于上游 | 不稳定 | 不支持 |
| Alpha Vantage | 返回空值 | 有限支持 | 不支持 |
| Yahoo Finance | 返回最后成交价 | 支持 | 不支持 |
深度讲究：
Polygon 在停牌或无成交的分钟直接跳过该时间戳，不输出任何占位符。这在输入 Pandas DataFrame 时是极度危险的隐患——如果直接对齐两只流动性不同的股票，不同维度的时间索引将导致 Numpy 广播异常。修正方法是显式构造全天交易分钟的理想时间轴，使用 .reindex() 强制对齐，并用前向填充填补缺口。
Polygon ticker 重用问题：Polygon 以 Ticker 为中心的历史查询机制，在代码重用场景下可能将退市公司与新上市公司的数据混淆。当一家公司破产退市后，其代码可能在数年后分配给新公司。若缺乏时间点截面映射，直接请求该 Ticker 会将两家公司的 K 线混为一谈，破坏动量策略的基础假设。这是专业量化团队才会注意到的细节。
6.5 回测场景综合评分
| 回测场景 | Polygon | TickDB | Tushare | AkShare | Alpha Vantage | Yahoo Finance |
|---|---|---|---|---|---|---|
| 美股长周期（15年+） | 最优 | 历史较短 | 不可用 | 不可用 | 可用（日频） | 最优（日频免费） |
| 美股 tick 级回测 | 唯一 | 不可用 | 不可用 | 不可用 | 不可用 | 不可用 |
| 美股分钟级日内 | 最优 | 可用 | 不可用 | 不可用 | 付费可用 | 可用 |
| A股长周期日频 | 不可用 | 历史较短 | 最优 | 可用 | 不可用 | 有限 |
| 跨市场（美股+A股） | 需自建对齐 | 最优 | 需自建对齐 | 不推荐 | 不可用 | 需自建对齐 |
| 指数成分股轮动 | 支持 | 支持 | 支持（A股） | 不支持 | 不支持 | 不支持 |
七、综合技术评分（5 分制）
章节导读
核心知识点：加权评分模型、各维度权重分配、分数的相对意义。
写作意图：前面六章是“分项对比”，本章给出一个“综合量化结果”。但请注意：分数不代表绝对优劣，而是反映“在不同场景下的综合适用性”。Tushare 分高是因为 A 股生态无敌，Polygon 分高是因为美股 tick 数据不可替代。分数只是帮你快速定位“谁在哪方面强”。
阅读收获：读完本章，你将能回答：① 为什么 Tushare 总分最高？② TickDB 的分数为什么排在中等？③ 评分表怎么用才不会被误导？
评分权重设计：美股实时质量 20%、跨市场能力 15%、订单簿深度（美股）10%、订单簿深度（其他）5%、WebSocket 工程健壮性 15%、接口设计 10%、错误处理 5%、文档社区 10%、成本友好 10%。
| 评估维度 | Polygon | TickDB | Tushare | AkShare | Alpha Vantage | Yahoo Finance |
|---|---|---|---|---|---|---|
| 美股实时数据质量 | 5 | 4 | 2 | 2 | 3 | 3 |
| 跨市场能力 | 2 | 5 | 3 | 4 | 3 | 4 |
| 订单簿深度支持（美股） | 3 | 1 | 1 | 1 | 1 | 1 |
| 订单簿深度支持（港股/数字货币） | 1 | 4 | 1 | 1 | 1 | 1 |
| WebSocket 工程健壮性 | 3 | 5 | 1 | 1 | 1 | 1 |
| 接口设计规范性 | 4 | 4 | 4 | 3 | 3 | 2 |
| 错误处理标准化 | 3 | 4 | 3 | 2 | 3 | 1 |
| 文档与社区支持 | 5 | 3 | 5 | 4 | 4 | 5 |
| 成本友好度 | 3 | 4 | 3 | 5 | 4 | 5 |
| 加权综合 | 3.7 | 3.6 | 3.9 | 2.8 | 2.9 | 3.1 |
评分解读：
- Tushare（3.9）：A 股基本面数据的国内事实标准，社区生态极度成熟，财务数据完整度是其核心资产。失分在缺乏 WebSocket 实时推送，不适用日内策略，美股数据支持有限。
- Polygon（3.7）：美股 NBBO 实时报价和 tick 级历史数据的标杆。运营近十年，开发者生态成熟。失分在跨市场能力弱、无原生 L2 深度、分红复权需自行处理。
- TickDB（3.6）：跨市场新贵，2024 年入局即以统一接入六类资产和原生工程健壮性建立差异化。月活开发者约 2 万但增速显著。失分在美股仅一档 NBBO、无 tick 数据、社区规模尚在建设期。
- Yahoo Finance（3.1）：日频历史数据最长（1970 年起），完全免费，全球社区广泛使用。失分在无官方 SLA、接口稳定性不可控、无 WebSocket、错误处理缺失。
- Alpha Vantage（2.9）：免费增值模式，覆盖多类资产，适合轻量级策略验证。失分在免费层限频严格、无 WebSocket、分钟级数据需付费。
- AkShare（2.8）：零成本另类数据入口，国内开源社区活跃。稳定性和实时性存在天然局限，生产环境需配合本地数据库隔离使用。
八、按用户画像与场景的选型矩阵
章节导读
核心知识点：个人开发者 vs 专业团队 vs 学术研究的差异化需求、场景化选型逻辑。
写作意图：前面七章是“分析”，本章是“决策”。不同的人有不同的预算、技术栈和策略复杂度，没有一家数据源能通吃所有场景。本章帮你根据自己的实际情况，找到最适合的那家。
阅读收获：读完本章，你将能直接回答“我是一个做 A 股日频因子的大学生，应该用哪家？”“我是管理千万资金的小型量化团队，跨市场交易，应该选哪家？”
8.1 个人开发者 / 策略验证阶段
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 纯美股日频策略验证 | Yahoo Finance | 免费，历史极长，足够跑通逻辑 |
| 纯美股基础日内策略 | Polygon 免费层 或 Alpha Vantage | Polygon 数据质量高但限频严格，Alpha Vantage 分钟级需付费 |
| A股日频因子挖掘 | Tushare 免费层 或 AkShare | 零成本，覆盖面广 |
| 跨市场概念验证 | TickDB 免费层 | 无需信用卡即可接入多类资产 |
8.2 专业量化团队 / 生产级系统
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 纯美股高频策略（需 tick 级） | Polygon | 美股 tick 数据唯一选择，社区生态成熟 |
| A股基本面量化（无日内需求） | Tushare Pro | 财务数据稳定，国内团队首选 |
| 多资产策略（美股+港股+A股+数字货币） | TickDB | 单一 WebSocket 跨市场，降低运维复杂度 |
| 机构级灾备与冗余 | Polygon（主）+ TickDB（备） | 避免单点故障，兼顾深度与跨市场 |
8.3 学术研究 / 长周期回测
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 美股超长周期回测（1970年起） | Yahoo Finance | 免费，历史数据最长 |
| A股宏观与个股联动研究 | Tushare + AkShare | Tushare 补充财务，AkShare 免费宏观指标 |
| 多市场相关性研究 | TickDB 历史 K 线 | 统一 UTC 时间戳，减少数据清洗工作量 |
九、AkShare 生产级使用模式（重要）
章节导读
核心知识点：爬虫类数据源的正确使用姿势——离线 ETL 抽取器模式、与时序数据库的配合。
写作意图：AkShare 分数不高，但它在特定场景（零成本另类数据）下无可替代。本章不是“劝退”，而是教读者“如何正确使用”——把它的价值榨干，同时避开它的坑。
阅读收获：读完本章，你将知道：如果非要用 AkShare 做生产，唯一的合规架构是什么。
AkShare 在开源社区的隐性共识是：禁止在策略循环中同步调用 AkShare 接口。原因有二：
- 基于 HTTP 轮询的爬虫模式导致单次响应时间极不确定，主交易线程同步等待会导致整个引擎阻塞。
- 高频请求极易触发上游网站的反爬机制，导致服务器 IP 被永久封禁。
正确使用模式：将 AkShare 作为离线 ETL 抽取器，在盘后定时拉取数据并持久化至本地时序数据库（如 ClickHouse、TimescaleDB），实盘策略完全读取本地数据库。这种物理隔离是 AkShare 在生产环境唯一合规的部署方式。
十、结语
数据源选型的本质是技术债务的前置管理。
Polygon 是美股 tick 数据和 NBBO 实时报价的标杆，适合纯美股高频策略，但需自行处理分红复权和 L2 深度的缺失。Tushare 是 A 股基本面量化的基石，适合日频因子，但不适用日内交易。TickDB 作为跨市场新贵，以统一接入和工程健壮性建立差异化，适合多资产团队。Yahoo Finance 以零成本和超长历史成为长期回测的高性价比选择。AkShare 和 Alpha Vantage 在特定场景下各有所长，但需清楚其工程边界。
建议的决策路径是：先明确策略的核心市场和数据粒度需求，再用免费层验证接口适配性，最后综合评估生产环境的稳定性要求和工程预算，做出最终选型。
本文不构成任何投资建议。市场有风险，投资需谨慎。
