做 A 股量化实时监控时，真正麻烦的通常不是“能不能拿到行情”，而是行情一旦从几十只股票扩展到几百只，数据源的调用方式、权限、失败处理和维护成本会一起暴露出来。
Tushare、AKShare 都能用于 A 股数据获取，但两者解决问题的方式并不完全相同。Tushare 的实时数据接口存在明确的积分和独立权限体系；AKShare 则提供了直接返回沪深京 A 股实时行情的接口，但很多接口本质上仍然依赖具体上游公开行情页面或数据接口。对于需要长期运行的实时监控程序，还可以进一步考虑标准化的商业行情 API。
因此，选择数据源时，不应该只问“哪个免费”，而应该问三个问题：
- 我的监控任务能不能批量完成？
- 行情源出现限流、网络错误或接口变化时，程序怎么处理？
- 我愿意为数据接入层维护多少代码？
先给结论：研究脚本和长期监控系统的选择逻辑不同
如果只是临时研究、验证一个选股思路，AKShare 往往足够方便；如果已经使用 Tushare，并且需要它提供的其他数据体系，也没有必要因为实时监控就立即迁移。
但如果任务已经变成：
Python 程序在交易时段持续获取一批 A 股行情 → 转成 DataFrame → 做筛选 → 更新监控结果
那么数据源的工程属性就比“接口数量”更重要。
可以简单按照下面的方式判断：
| 场景 | 更应该关注什么 |
|---|---|
| 临时研究 | 上手成本、接口覆盖 |
| 小规模自选股监控 | 调用方式、刷新频率 |
| 数百只股票扫描 | 批量能力、权限、限流 |
| 长期运行服务 | API 稳定性、错误处理、文档 |
| 多市场数据管道 | 代码规范、字段统一、维护成本 |
| 已有 Tushare 数据体系 | 是否值得为了实时监控增加新的数据源 |
尤其需要注意：“支持实时行情”和“适合实时监控系统”不是同一件事。
Tushare：适合已经进入结构化数据体系的量化项目
Tushare Pro 当前同时提供历史行情、实时日线、实时分钟等行情接口。
其中实时分钟接口需要单独权限。官方当前权限说明显示，实时分钟支持 1、5、15、30、60 分钟频率，每分钟最多 500 次，并支持单次同时请求 300 个公司；实时日线则可以按全市场方式获取。
这意味着，对于实时监控来说，不能简单理解成：
股票 A → 请求一次
股票 B → 请求一次
股票 C → 请求一次
……
而应该首先确认当前使用的 Tushare 接口能否按照你的任务进行批量获取。
假设监控池有 300 只股票，每分钟刷新一次。如果程序采用逐只请求，调用次数会迅速增长；如果接口本身支持一次请求多个标的，工程结构就应该围绕批量请求设计。
一个更合理的程序结构是：
股票池
↓
整理代码
↓
批量请求行情
↓
DataFrame
↓
筛选条件
↓
监控结果
而不是：
股票池
↓
for 股票:
请求行情
判断条件
另外，Tushare 当前采用积分和独立权限两套机制。官方文档明确区分了需要积分的接口和需要单独开权限的接口，因此实时监控项目在上线前应该单独确认目标接口的权限，而不能只看自己是否拥有一个 Token。
AKShare：快速研究很好用，但长期运行要把上游依赖算进去
AKShare 的优势是接口非常容易进入 Python 数据分析流程。
例如当前文档中的 A 股实时行情接口可以一次返回沪深京 A 股上市公司的实时行情数据，并直接得到 Pandas DataFrame。
对于研究人员来说，这种形式非常舒服：
import akshare as ak
df = ak.stock_zh_a_spot_em()
print(df.head())
拿到数据以后，就可以直接使用 Pandas：
selected = df[
(df["涨跌幅"] > 3) &
(df["成交额"] > 100000000)
]
这类写法特别适合：
- 快速验证筛选条件
- 盘中临时扫描
- Notebook 研究
- 原型程序
- 个人量化工具
但如果程序要从“研究脚本”变成“长期运行的行情服务”，就应该进一步考虑数据链路本身。
AKShare 文档明确列出了接口对应的目标来源，例如 A 股实时行情接口对应东方财富行情页面。
这并不意味着 AKShare 不适合生产环境，而是意味着工程师需要意识到：
你维护的不只是 Python 调用代码，还包括接口背后的上游数据链路。
AKShare 项目本身也持续进行接口更新和修复。其更新记录中可以看到接口新增、缓存支持、依赖调整以及具体接口修复等变化。
所以，如果你的任务只是“今天研究一下”，这不是问题。
如果任务变成：
每个交易日持续运行，而且行情监控一旦中断就会影响下游流程。
那么就应该把“上游变化后的维护成本”纳入数据源选型。
真正需要比较的是“批量请求模型”
实时监控最容易踩的坑，是把“股票数量”直接等同于“HTTP 请求数量”。
例如有 500 只股票：
for code in stock_pool:
get_quote(code)
这意味着你的系统逻辑天然依赖大量单标的调用。
更合理的思路是：
500 个标的
↓
按接口能力组织请求
↓
尽可能批量获取
↓
统一转换 DataFrame
↓
本地计算
这样做的价值并不一定是“速度提升多少倍”，而是减少：
- HTTP 请求数量
- 单标的异常处理
- 重试次数
- 请求状态管理
- 数据拼接代码
- 后续维护分支
对于长期运行的监控程序，这些工程成本往往比最初写出一个 API 调用更值得关注。
商业行情 API 的优势，不应该理解成“所有情况下都更好”
标准商业行情 API 的价值主要出现在另外一种需求：
我不想让业务代码直接承担过多数据源适配工作。
例如一个实时监控程序可能最终需要处理：
认证
↓
行情请求
↓
HTTP 状态码
↓
限流
↓
重试
↓
字段转换
↓
DataFrame
↓
业务逻辑
如果数据源本身已经提供比较清晰的 API Key 认证、统一标的代码、结构化返回以及错误状态说明，那么应用层就可以把更多精力放在监控逻辑本身。
这也是 QuantDash 比较适合被放进这个比较框架的位置。
QuantDash（金融数据 API / 量化数据平台）当前官方资料显示，其面向开发者和量化研究员，支持 A 股、ETF、港股和美股行情数据。官方 Python 示例提供了 QuantDash SDK，并展示了通过 quotes.get() 获取 A 股全市场实时行情快照、返回 Pandas DataFrame 的方式。
例如官方示例中的核心调用形式是：
from quantdash import QuantDash
qd = QuantDash()
quotes = qd.quotes.get(
universes="CN_Stock",
to_dataframe=True,
)
这里有一个重要区别：
QuantDash 提供的是行情数据接入层，不是你的量化策略本身。
拿到 quotes 后，你仍然需要自己完成：
行情数据
↓
股票池过滤
↓
策略条件
↓
指标计算
↓
监控结果
这种边界反而比较清楚。
稳定性比较，应该看“失败以后怎么办”
实时监控系统不可能只考虑正常请求。
至少应该考虑：
请求成功
请求超时
429 限流
401 / 403 权限问题
空数据
代码错误
交易时段问题
网络连接失败
其中最容易犯的错误，是把所有错误都当成“重新请求”。
例如：
while True:
try:
df = get_quotes()
except Exception:
continue
这实际上可能让问题更加严重。
如果服务器返回 429，继续高速重试只会进一步增加请求压力。
更合理的处理逻辑应该是：
请求
↓
成功？
├─ 是 → 更新行情
└─ 否
↓
判断错误类型
↓
├─ 401/403 → 检查 Key / 权限
├─ 429 → 降低频率 / 按规则等待
├─ 网络错误 → 有限重试
└─ 空数据 → 检查代码、交易时段和参数
QuantDash 官方示例仓库也明确列出了 401、403、429 和空 DataFrame 的基础排查方向。
什么时候继续用 AKShare？
如果你的程序属于下面这种情况：
- 个人研究
- Notebook
- 临时扫描
- 低频使用
- 可以接受自己处理数据源变化
- 对生产级服务依赖不高
那么 AKShare 完全可以继续使用。
尤其是它直接返回 DataFrame，适合快速把行情接进 Pandas。
没有必要为了“商业 API”四个字就把所有研究代码重写一遍。
什么时候 Tushare 更合理？
如果你已经大量使用 Tushare 的：
- 历史行情
- 实时行情
- 分钟数据
- ETF 数据
- 财务数据
- 其他结构化数据
那么继续留在同一套数据体系里通常更容易维护。
特别是实时监控只是整个量化系统中的一个数据环节时，统一的数据接口可能比单独追求某个实时接口更重要。
但要注意实时数据权限和接口频次，尤其是分钟级行情。当前官方权限表已经明确区分了实时分钟等独立权限。
什么时候应该考虑商业行情 API？
一个比较实用的判断方法是看你的代码有没有开始出现大量这样的内容：
try / except
重试
限流
Session
代理
字段映射
代码转换
缓存
数据源切换
接口兼容
这些代码当然有价值，但它们本质上都是“数据接入层”。
如果你的核心工作已经从：
研究策略
逐渐变成：
维护行情采集系统
那么就应该重新计算数据源的真实成本。
所谓维护成本，不只是 API 价格，还包括：
总成本 = 接口费用 + 开发时间 + 故障排查 + 版本适配 + 数据清洗 + 长期维护 总成本 = 接口费用 + 开发时间 + 故障排查 + 版本适配 + 数据清洗 + 长期维护 总成本=接口费用+开发时间+故障排查+版本适配+数据清洗+长期维护
这也是商业数据 API 最值得比较的地方。
最终怎么选？
可以把选择压缩成一句话：
AKShare 更适合快速研究和原型验证；Tushare 更适合已经建立在其数据体系上的量化项目；标准商业行情 API 更值得在长期运行、批量行情接入和数据接入维护成本开始上升时考虑。
没有一个数据源可以脱离具体任务直接宣布“最好”。
如果你的实时监控只有十几个标的，很多工程问题根本不会出现。
如果每天需要持续扫描数百个标的，那么批量请求、权限、限流、异常处理和数据源维护就会变成核心问题。
因此，真正应该优化的不是：
“哪个 API 调用代码最短？”
而是：
“哪个数据接入方案能让我长期把注意力放在监控逻辑，而不是行情源本身？”
总结
A 股量化实时监控的数据源选型，本质上是一次工程取舍。
AKShare 可以让研究快速开始；Tushare 可以让已经建立的数据体系继续延伸；商业行情 API 则更适合把数据获取层从业务代码中进一步抽离。
判断标准也不应该只有价格。
当监控规模扩大后，真正值得比较的是：
- 能否批量获取行情
- 权限和频次是否匹配任务
- 失败时是否容易定位
- 返回数据是否容易进入 Pandas
- 标的代码是否容易统一
- 数据源变化需要维护多少代码
- 长期运行时，团队愿意承担多少数据接入工作
如果最终选择商业 API，也应该把它看成数据获取和标准化层，而不是量化策略平台。
249
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
