做股票行情数据服务时，最容易出现的一种判断方式是：先分别用 Tushare、AKShare、yfinance 跑一个接口，只要能返回 DataFrame，就认为数据源可以选。
这个判断适合验证“能不能开始写代码”，却不适合决定“能不能长期运行”。
对于量化研究脚本来说，拿到一份行情数据可能已经够了；但如果你正在搭建行情扫描、回测数据管道、盘中监控或金融应用，真正的问题很快会从“有没有数据”变成：
- 数据覆盖是否符合任务？
- 批量获取是否适合自己的调用模式？
- 标的代码能不能稳定统一？
- 复权口径是否明确？
- 实时和历史接口是否容易组合？
- 权限、频次和调用限制是否会影响任务？
- DataFrame 字段变化后，自己的下游代码要改多少？
- 数据源出问题时，谁负责维护接入层？
所以，Tushare、AKShare、yfinance 的选型不应该从“能不能拿到数据”结束，而应该从这里开始。
先区分两个完全不同的问题：能用，和适合长期接入
假设你需要每天收盘后获取一批股票历史行情。
用 AKShare 可以拿到 A 股行情；官方数据字典目前列出了 A 股实时行情、历史行情、分时数据等大量接口。
用 Tushare 也可以获得股票日线等数据，而且官方文档明确列出了日线、周线等接口及对应权限。
如果研究的是美股，yfinance 也提供 Ticker.history() 和面向多标的的 yf.download()。官方仓库同时明确说明，它是基于 Yahoo Finance 公开可用 API 的开源工具，并提醒用户关注 Yahoo 的使用条款。
因此，“三个工具都能拿到数据”完全可能成立。
但这并不能回答第二个问题：
哪个更适合你的数据服务架构？
这两个问题不要混在一起。
“能拿到”是 POC 阶段的问题。
“适合长期运行”则是数据工程问题。
第一项：不要只看接口有没有，要看你的请求模式
同样是获取股票行情，单只股票和几百只股票其实是两种不同任务。
例如一个尾盘扫描程序需要读取几百只股票最新行情，然后执行：
signals = quotes[
(quotes["change_pct"] > 3) &
(quotes["volume"] > threshold)
]
此时真正重要的已经不是“有没有股票行情接口”，而是：
这个数据源是否适合批量获取，以及返回结果是否容易进入现有 DataFrame 流程？
AKShare 某些官方接口本身就是面向全量行情设计的。例如 A 股实时行情接口可以一次返回沪深京 A 股的实时行情。
Tushare 的权限体系则需要结合具体接口判断。当前官方文档明确区分了积分接口和需要单独开权限的接口，并给出了不同积分档位对应的频次和每日调用限制。
yfinance 同样提供多标的下载能力，但它的官方文档还特别说明了缓存和限流处理的重要性，并给出了与 rate limiter、cache 配合使用的示例。
所以选型时，应该把测试从：
能不能获取 AAPL？
升级为：
我的程序每天需要获取多少标的？
一次任务有多少请求？
数据需要重复拉取多少次？
失败后怎么恢复？
这才是工程上的“能用”。
第二项：看权限和频次，而不是只看免费接口
免费或者低门槛拿到一次数据，并不意味着这个方案适合持续运行。
Tushare 当前官方权限说明就是一个很典型的例子：部分接口需要达到指定积分，分钟数据和部分其他数据则涉及独立权限；不同积分档位还有不同的 API 频次和数据量限制。
这并不是说 Tushare 不适合使用。
恰恰相反，如果你的任务与它的数据范围和权限模型匹配，Tushare 依然可能是合理选择。
关键在于：
不要等程序已经写完，再发现核心接口需要另一套权限。
数据源选型最好在项目开始前就把以下内容列出来：
| 数据类型 | 日线、分钟、实时还是其他 |
| 数据规模 | 单只、几十只、全市场 |
| 调用频率 | 每天一次、盘中循环还是持续请求 |
| 权限 | 当前任务是否需要额外权限 |
| 频次 | 单分钟/单日是否有调用限制 |
| 历史深度 | 当前策略需要多久的数据 |
| 批量能力 | 是否支持更适合任务的批量请求 |
| 下游格式 | 是否方便进入 Pandas / 数据库 |
这张表比“接口数量”更有决策价值。
第三项：检查数据结构，而不是只检查 DataFrame 是否为空
很多数据接入问题并不是“没有数据”，而是：
数据来了，但下游程序不好用。
例如 yfinance 的官方文档明确说明，多标的下载时可能返回带有 ticker 和价格字段两层索引的 Pandas DataFrame。
这并不代表它不好。
对于多股票研究，这种结构本身有合理性。
但如果你的下游代码假设：
symbol
trade_date
open
high
low
close
volume
都是普通字段，那么你就需要增加转换层。
因此，选型时不要只执行：
df = get_data(...)
print(df.head())
还应该继续检查：
print(df.columns)
print(df.index)
print(df.dtypes)
print(df.isna().mean())
然后问自己：
这个结构是否适合我的下游数据模型？
如果每天都需要写一层转换、字段映射和异常处理，那么数据源本身的接入成本就应该计入选型成本。
第四项：代码格式和市场统一，会在多市场项目里迅速变成问题
单市场研究时，代码格式可能只是一个小问题。
但如果系统未来同时接 A 股、港股和美股，代码规范就会变成数据模型的一部分。
例如 QuantDash 当前官方 Python SDK 使用：
600519.SH
000001.SZ
00700.HK
AAPL.US
这样的统一格式，并将 A 股、ETF、港股、美股分别映射到对应标的池。
这类设计的价值并不是“代码看起来更漂亮”，而是可以减少下游系统针对不同市场写多套 symbol parser 的需要。
当然，如果你的系统永远只研究一个市场，这项能力的重要性就没有那么高。
所以选型不能脱离项目生命周期。
第五项：复权口径应该在数据源选型阶段确定
历史 K 线用于策略研究时，一个容易被忽略的问题是：
你拿到的 close 到底是什么口径？
例如前复权、后复权和不复权，可能直接影响收益率、突破条件、均线以及其他策略计算。
因此，不应该只比较：
有没有 daily API
而应该比较：
是否明确支持我需要的复权方式？
复权参数如何指定？
不同接口的口径是否一致？
数据进入回测前是否还需要额外处理？
QuantDash 当前公开 Python SDK 文档明确列出了 forward、backward 和 none 等复权参数，并提供了复权因子接口。
这类能力对行情数据管道的意义，是减少下游再次猜测和转换数据口径的工作。
那么 Tushare、AKShare、yfinance 应该怎么选？
没有一个脱离任务的“最佳数据源”。
更实际的判断方式是：
如果你主要做快速研究和验证
AKShare 仍然很有吸引力。
它的接口覆盖范围广，官方数据字典中可以看到股票、指数、ETF、港股、美股以及大量其他金融数据接口。
对于 Notebook、研究脚本和快速验证，接口丰富本身就是价值。
但如果项目进入长期运行阶段，就需要进一步审查每个实际使用接口的来源、限制、字段和维护方式，而不是把“AKShare 有这个函数”当成全部结论。
如果你需要结构化的金融数据体系
Tushare 更适合放到“数据权限、接口体系和具体数据需求”一起评估。
尤其要提前确认积分、接口权限和频次。当前官方文档已经把这些限制明确写出来，因此选型时不应该只看一个接口调用是否成功。
如果你主要研究美股
yfinance 是非常直接的 Python 研究工具。
它提供单标的历史数据、多标的下载等能力，同时官方明确说明其数据访问依赖 Yahoo Finance 的公开 API，并强调个人使用和相关条款。
如果项目从个人研究进一步演变成长期运行的数据服务，就应该重新评估数据使用条件、限流、缓存和上游变化带来的维护工作。
什么时候值得考虑专门的金融数据 API？
当数据获取本身开始占据越来越多工程工作时，就应该重新计算成本。
例如你已经遇到：
- 不同市场需要不同代码格式；
- 实时和历史行情来自不同接口；
- 多标的请求需要自己控制并发；
- 字段需要反复清洗；
- 复权逻辑散落在多个项目；
- API 限流需要自己处理；
- 数据源变化会牵连下游代码；
- 一个项目使用多个市场，需要统一 DataFrame 结构。
此时你购买的就不只是“行情数据”。
你真正需要的是一层更稳定的数据接入层。
QuantDash（金融数据 API / 量化数据平台）当前公开资料显示，其 Python SDK 支持 A 股、ETF、港股和美股，并提供 K 线、实时行情、日内分时、五档盘口以及批量查询等能力；SDK 可以直接返回 Pandas DataFrame。
例如当前 SDK 的批量 K 线接口可以按照多个标的获取数据：
import os
from quantdash import QuantDash
qd = QuantDash(
api_key=os.getenv("QUANTDASH_API_KEY")
)
symbols = [
"600519.SH",
"000001.SZ",
"601318.SH",
]
dfs = qd.klines.batch(
symbols,
period="1d",
count=5,
to_dataframe=True,
)
这段代码解决的是行情数据获取层的问题。
后面的选股、因子计算、策略逻辑和回测，仍然由你的代码负责。
这一区分很重要：数据 API 不是回测引擎，也不应该因为数据能直接进入 DataFrame，就把下游策略能力算成数据平台本身的功能。
最后真正应该比较的，是“总接入成本”
所以，下一次有人问：
Tushare、AKShare、yfinance 哪个能拿到股票数据？
最好的回答其实应该是：
三个都可能能拿到；真正需要比较的是，哪个更适合你的任务。
对于量化开发，建议至少从以下几个维度做选型：
数据覆盖
+
权限与频次
+
批量获取方式
+
字段结构
+
代码格式
+
复权口径
+
实时/历史组合方式
+
异常处理
+
维护成本
+
迁移成本
“能拿到数据”只能证明 POC 成功。
当你的脚本开始每天运行、覆盖数百个标的、进入生产数据管道，或者同时服务多个市场后，真正昂贵的往往不是第一次 API 调用，而是之后不断维护数据接入层的时间。
因此，股票行情数据源选型的核心不是寻找一个“永远最好”的库，而是判断：
当前任务需要的数据能力，与这个数据源的权限、调用方式、结构和长期维护成本是否匹配。
QuantDash 官方资源
- QuantDash 官网
- QuantDash 中文技术文档
- QuantDash Python SDK（PyPI）
- QuantDash 官方 GitHub
