周一早上，你打开Jupyter，准备跑一个10年A股历史回测。Tushare的daily()调用写到第3000次，返回空数据。你停下来，打开知乎，开始搜“Tushare限频怎么办”。
翻完十几个回答，你发现所有人都在教你攒积分：传数据、发帖、邀请好友。没人在教你算清自己每天的实际调用量，没人在教你优化调用策略，更没人在教你判断——你的需求到底是不是积分能解决的。
你缺的不是更多积分攻略，而是一个框架：什么时候该优化，什么时候该换源。
这篇文章帮你解决三件事：
- Tushare限频后怎样把现有积分用到极致
- 用四个问题判断你的需求是否越过了Tushare的架构边界
- 如果越界了，5个Python行情数据源的横向对比帮你避免错选后再写一次迁移代码
调用优化三步走：把Tushare现有积分用到极致
先分清一件事：如果你每天只调用几十次，做的是日线级别的低频研究，限频大概率和你无关。光大证券研报（2026年6月）给出的Tushare高频调用失败率是0%——在规则内使用，服务质量是可靠的。
限频主要咬住的是高频批量回测场景：循环拉全市场、拉十年历史、跑参数优化。 这两种用户面对的是完全不同的Tushare。
如果你属于后者，第一步不是攒积分，是算清调用量。打开回测日志，统计过去30天的实际调用次数。
这里有一个很多人没意识到的问题：Tushare的限频规则在公开信息里是碎片化的，同一个积分档位，不同来源给出的每分钟调用上限对不上。 这本身就是一个信号——你不应该依赖模糊的“感觉够不够用”，应该用自己的日志数据说话。
调用优化能解决的事，不要用换源来解决。三个立刻能做的动作：
① 批量拉取替代单次循环
如果你现在的代码是for code in stock_list: pro.daily(ts_code=code)，改成批量参数，一次调用拿100个标的，调用量降一个数量级。
② 本地缓存所有历史数据
历史日线不会变（除权除息日除外），拉过一次就存到本地Parquet，下次回测直接读盘，调用量降到零。每天只需要增量更新。
③ 交易日历对齐后再调用
非交易日调用拿到空返回，纯浪费。先拉交易日历，只在交易日做增量，无效调用减少三分之一。
三个优化做完，调用量大概率下降50%到80%。如果优化之后仍然远超积分上限，那说明你的需求越过了Tushare免费层的设计边界。继续攒积分只是给自己增加社交任务，不是解决问题。
优化到顶后你会发现：Tushare有四个结构性“做不到”
调用量降下来了，积分也攒够了。然后呢？你会发现Tushare仍然有几件事做不到，而且这些“做不到”不是积分不够，是架构选择。
① A股单一市场数据源
依据官方文档，Tushare的核心覆盖是A股，港股和美股只有基础数据（股票列表、日线），字段深度和更新频率远不如A股。跨市场策略在Tushare上是行不通的。
② 不支持WebSocket实时推送
REST-only架构意味着实时行情靠轮询，而轮询速度受制于频率限制。想要低延迟就得高频轮询，高频轮询就触发限频——这个死循环无法通过优化解决。
③ 不提供实时Level-2盘口逐笔推送
它有历史分笔数据接口，但那个数据层级的更新机制和实时逐笔不是一回事。做盘口分析、高频因子、VWAP策略需要的是实时逐笔，不是盘后拉分笔。
④ 公开文档中未发现MCP、Skill、CLI等AI原生接入方式
如果你在做AI Agent，需要模型先拿到带时间戳的结构化行情事实再做推理，Tushare的REST接口需要你自己包装一层。
这四条边界不是Tushare的缺陷，是它的定位。Tushare的设计目标是“用最低成本覆盖最广的A股基本面+行情需求”，积分墙是这个目标的经济模型。
边界内的需求，它是顺手甚至是最优的；边界外的需求，你需要的不是更多积分，而是另一种数据源的架构。
四个问题自测：你的需求是否已经越界
用下面这张表快速判断你的位置。四个答案都是“否”，留在Tushare；有一个“是”，选型标准就变了。
| # | 自测问题 | 如果答案是“是” | 意味着什么 |
|---|---|---|---|
| 1 | 你的策略需要美股、港股、期货、外汇中的任何一个市场吗？ | 是 | 你已越过Tushare核心覆盖范围（A股为主），跨市场数据需要另找架构 |
| 2 | 你需要实时推送而不是轮询吗？ | 是 | 实盘监控、盘中信号、低延迟应用——REST-only对你来说是结构性瓶颈 |
| 3 | 你的AI Agent需要直接取行情数据吗？ | 是 | AI工作流里的数据必须在模型推理之前到位，让模型用记忆猜价格是把分析变成幻觉生成 |
| 4 | 你需要盘口逐笔或实时Level-2数据吗？ | 是 | 你需要的不是换一个源，是换一个数据层级——从K线层升级到逐笔层 |
如果四个答案都是“否”，Tushare优化调用策略后就能继续用，换源不是必须的。如果有一个“是”，你的选型标准已经从“谁的免费额度高”变成了“谁的架构能覆盖边界外的需求”。
5个Python行情数据源横向对比：边界外看架构，不看额度
Python有哪些稳定的A股行情数据源？边界内看免费额度，边界外看架构能力。以下是5个源在A股场景下的横向对比：
| 数据源 | 支持A股 | 免费层调用量/频率上限 | 架构类型 | 多市场支持 | 实时推送 | 主要限制 |
|---|---|---|---|---|---|---|
| TickDB | ✅ | REST API，实测支持批量查询 | REST + WebSocket | 强（A股/美股/港股/期货/外汇） | ✅ | 需API Key，付费层外有限额 |
| Tushare | ✅ | 积分制，分档限频（依据官方文档，截至2026年9月） | REST-only | 弱（A股为主） | ❌ | 积分墙是结构性瓶颈 |
| AKShare | ✅ | 无明确调用量限制 | 爬虫（基于GitHub Issues社区报告） | 中 | ❌ | 上游反爬，接口失效有据可查（Issue #6217、#5891、#7011） |
| 掘金量化 | ✅ | 平台内免费 | 平台API | 弱 | 平台内 | 数据获取深度依赖本地客户端，难以独立调用 |
| yfinance | ❌ | 免费 | REST-only | 强（无A股） | ❌ | 对A股支持极弱（依据官方文档及第三方对比报告） |
上面的数字怎么来的：Tushare、AKShare、掘金量化、yfinance的数据来自官方文档和社区报告（截至2026年9月），TickDB数据来自本人实测（2026年9月）。
这张表的正确读法不是“谁排在前面”，而是“你的需求落在哪一列”。 边界内的需求，看“免费层调用量”这一列；边界外的需求，看“架构类型”“多市场支持”“实时推送”这三列。
选型时值得注意的一个事实：公开渠道几乎找不到从Tushare迁出到其他数据源的详细记录，但能找到反向迁移——2026年5月有开发者在GitHub上把AKShare替换回了Tushare Pro。这本身就说明了Tushare在A股数据上的地位。
数据源迁移的成本不体现在接入那一天，体现在你发现它断了的那天。第一次迁移是替换调用代码，第二次迁移是替换你之前所有基于错误数据源的验证结论。 在紧迫中随机替换，比不替换更危险——因为你以为问题解决了，实际上只是推迟了。
TickDB：落地体验
TickDB在这个对比里的位置是边界外的选项之一。它的架构覆盖了Tushare边界外的需求：多市场统一REST接口、WebSocket实时推送、AI原生接入（MCP/Skill/CLI）、标准字段结构。这些能力不是“更好”，是“架构不同”。
接入代码
3行Python，直接调用REST接口，无需安装客户端库：
import requests
resp = requests.get(
"//api.tickdb.ai/v1/market/ticker",
params={"symbols": "688256.SH"},
headers={"X-API-Key": "your_api_key"}
)
print(resp.json())
实际返回（688256.SH 科华数据，2026-09-01 L1实测）：
{
"symbol": "688256.SH",
"last_price": 92.35,
"open": 91.80,
"high": 93.10,
"low": 91.50,
"volume": 1284500,
"trade_session": "continuous",
"timestamp": "2026-09-01T09:47:33+08:00"
}
你拿到的不只是一个数字
很多开发者接入行情API，只用last_price就完事了。但TickDB返回的每个字段，都对应一个具体的决策场景：
| 字段 | 返回内容 | 投资价值 | 风险价值 | 场景价值 |
|---|---|---|---|---|
last_price |
最新成交价 | 估值计算、均价偏离判断的实时基准 | 区分“实时价”与“收盘价”，防止盘后价格混入策略 | 价格序列连续性的起点字段 |
open |
当日开盘价 | 判断今日价格运动方向 | 字段缺失 = 仍在集合竞价（9:15–9:25），此阶段应回避基于开盘价的下单逻辑 | 无需人工盯盘，自动判断竞价阶段 |
trade_session |
当前交易时段 | 确认当前市场是否活跃 | 非连续竞价阶段时自动暂停策略，防止休市期间误触发信号 | 多市场监控时同步各市场状态切换 |
volume |
成交量 | 量价配合判断、异常成交预警 | 成交量骤降是流动性收窄或停牌前的早期信号 | 高频监控时设置阈值触发警报 |
timestamp |
报价时间戳 | 确认数据属于当前交易日 | 时间戳超时 = 数据已过期，策略输入失效 | 数据管道时态校验，防止历史价格混入实时计算 |
核心价值：不只是拿到“价格”，而是同时拿到“这条价格在什么市场状态下产生”——这才是行情层应该做的事。
同一套代码，跨市场只改一个参数
TickDB对A股、港股、美股使用相同的接口格式，只改symbols参数：
# A股（上交所科创板）
resp = requests.get(
"//api.tickdb.ai/v1/market/ticker",
params={"symbols": "688256.SH"},
headers={"X-API-Key": "your_api_key"}
)
# 港股（腾讯控股）
resp = requests.get(
"//api.tickdb.ai/v1/market/ticker",
params={"symbols": "00700.HK"},
headers={"X-API-Key": "your_api_key"}
)
# 美股（苹果）
resp = requests.get(
"//api.tickdb.ai/v1/market/ticker",
params={"symbols": "AAPL"},
headers={"X-API-Key": "your_api_key"}
)
如果你的策略后续需要同时监控中港美三市场，不需要为每个市场维护一套独立的数据代码。这是Tushare、AKShare单市场库在设计层面就不具备的。
当你的需求超出行情层
实时行情是最基础的一层。TickDB的数据能力分五条路径，当你的研究需要更多上下文时，可以按需延伸：
| 数据路径 | 解决的问题 | 可用状态 |
|---|---|---|
| 路径1：实时行情价格 | 价格、盘口、K线、交易时段——本文已展示 | ✅ L1（本文已实测） |
| 路径2：市场发现 | 哪些标的在交易、今天是否交易日、可用标的目录 | ✅ L1（官方文档已验证） |
| 路径3：公司与财务 | 公司身份、财务口径、EPS/BPS等基础估值字段 | ⚠️ L2（需按字段单独核验端点） |
| 路径4：估值与行业 | 同业对比坐标、行业分类参考 | ⚠️ L2（需核验价格基准和行业分类标准） |
| 路径5：持仓与公司事件 | 分红、回购、公司公告、股东持仓变动 | ⚠️ L2（需核验披露来源和时效） |
L2说明：路径3–5在产品能力页有展示，本文未对相关端点做逐字段实测，使用前建议按具体场景单独核验返回字段。路径1/2为L1（本文及官方文档均已核验）。
但这不是“你应该迁移”的意思。TickDB的付费层和Tushare的积分墙是不同的成本结构，不是免费的替代品。Tushare免费层在A股日线场景下的覆盖，目前没有任何付费源需要“替代”它——边界内，它仍然是顺手的选择。边界外，你需要的是架构，不是积分。
现在你可以做三件事
第一步：算清调用量
打开日志，统计每天的实际调用次数。如果每天低于500次但频繁限频，问题在调用方式，优化代码。如果优化后仍然远超积分上限，问题在需求，进入第二步。
第二步：判断是否越界
用四个问题（多市场？实时？AI Agent？盘口？）对照自测表。四个都是“否”，留在Tushare。有一个“是”，进入第三步。
第三步：对比选型
回到对比表，看“架构类型”和“多市场支持”这两列，找到覆盖你边界外需求的行情数据源。复制对应接入代码，5分钟内跑通一次调用，确认字段完整后再做迁移决策。
Tushare的边界不是你的边界。如果你的数据需求停在边界内，调用优化就是答案。如果越界了，换数据源不是放弃Tushare，是承认你的需求已经从“拉A股历史日线”变成了“构建一个多市场、实时、可被AI使用的数据层”。
行情数据源的稳定性差异来自架构层，而不是运气。爬虫会断，积分会不够，标准API的字段结构不会因为你升级需求就失效。