免费股票API怎么选？从个人研究到产品上线的数据接入评估与云上落地

摘要：面向准备把研究原型交付为行情看板的团队，本文以“20只美股、每10秒刷新”为例，拆解免费股票API的数据范围、更新频率、额度、订阅和使用条件。结合四类免费入口的官方说明与一次行情 MCP 调用记录，给出可填写的选型判断表、本地用量计算代码，以及部署到阿里云时的密钥、缓存、监控和降级检查点。

准备把一个个人研究脚本改成股票行情看板时，免费股票API怎么选，不能只看能不能取到价格。先放20只美股，每10秒刷新一次。取得Key、调用接口、页面出现价格，往往很快；真正准备交付时，问题才出现：20只股票都能取到吗？刷新一小时会消耗多少额度？试用结束后还能运行吗？

本文只讨论数据接入和工程选型，不构成投资建议，也不承诺任何收益。

选择免费股票API，先把自己的任务写成使用条件，再逐项判断免费方案是否满足。核心是数据、用量、持续时间和使用范围。某一项尚未确认，就把它留在交付待办里，别让“已接通”替代整个选型结论。

一、免费股票API先分清四种免费

搜索“免费股票数据API”，会同时看到开源库、免费额度和商业服务试用。它们解决的起点不同，不能只按“有没有费用”排成一张榜。

这些条件可能叠加在同一个方案上。一个免费层可以既限每日额度，也限数据范围和使用场景。

下面用四个熟悉的入口说明区别。表中为2026年11月9日核对的官方说明，调用记录另列在后文。

这里最容易漏掉的是：免费取得软件、免费发起请求、免费使用某类数据，是三个不同问题。后面还要加上第四个问题——这些数据准备给谁使用。

图1：按项目逐项检查四类条件。某一项通过，不代表其他项已经满足。

二、把免费股票API额度算成项目预算

“支持股票行情”太宽。对于开头的看板，先写下六个条件：

• 对象：确定的20只美股，列出完整代码，不写“美股若干”。
• 数据：主交易时段的报价；需要哪个时间字段，允许多大的数据年龄。
• 频率：应用每10秒请求一次；接口更新频率另行确认。
• 运行时间：先测试1小时，随后按实际每日运行时长重新计算。
• 使用方式：先个人测试，交付同事或客户前分别确认条件。
• 失败处理：未取得新数据时显示过期状态，不能只留下旧价格。

“每10秒刷新页面”描述的是应用动作。数据源如果只提供日终数据，页面刷新得再快，也不会多出盘中信息。同样，换成WebSocket只是换了接收方式，数据范围和使用条件仍然要核对。

1. HTTP请求、额度单位、同时订阅要分开算

为说明计量区别，先做一个明确的假设：一个接口允许每次查询20只股票；每只股票每轮消耗1个额度单位；一小时内从第0秒开始每10秒查询一次，到3600秒前结束，共360轮。暂不计初始化、重试和其他接口。

由此得到：

一次请求能装下20只股票，只减少了请求次数；按标的计量时，20只股票仍分别消耗额度。Twelve Data的官方计量示例就按端点权重与标的数计算credits。其他服务采用什么规则，仍要看对应端点，不能套用这张演算表。

如果改成推送，并假设每只股票只占一个订阅单位，20只股票需要20个同时订阅。一个WebSocket连接可以承载多少订阅，是另一项限制；连接数不能当成标的数。

图2：假设计量演算。轮询与推送是两种方案；图中的数字不是任何服务商的收费规则或服务承诺。

2. 用这段Python先算自己的项目

保存为budget.py，使用Python 3.10或以上版本运行python3 budget.py。仅使用标准库，无需Key，也不会发出网络请求。把开头的参数换成目标接口的真实计量规则。

# 测试环境：Python 3.11 / 2026-11-09
from math import ceil
import json

symbols = 20
interval_seconds = 10
duration_minutes = 60
symbols_per_request = 20
credits_per_symbol = 1
channels_per_symbol = 1

polls_per_minute = 60 / interval_seconds
requests_per_poll = ceil(symbols / symbols_per_request)
result = {
   
    "requests_per_minute": polls_per_minute * requests_per_poll,
    "requests_in_test": polls_per_minute * requests_per_poll * duration_minutes,
    "credits_per_minute": polls_per_minute * symbols * credits_per_symbol,
    "credits_in_test": polls_per_minute * symbols * credits_per_symbol * duration_minutes,
    "concurrent_subscriptions_if_streaming": symbols * channels_per_symbol,
}
print(json.dumps(result, indent=2))

本例本地运行输出为6次请求/分钟、360次请求/小时、120额度单位/分钟、7,200额度单位/小时；推送方案的假设需求为20个同时订阅。

计算器用于固定参数的规划估算。历史数据补齐、初始化和重试需另留预算；例如看板持续更新时又下载历史K线，两项任务可能共同消耗账户额度。

三、免费股票API额度够了还要验收数据范围

个人研究和行情看板对“有数据”的要求不同。

做历史研究，重点是目标日期范围、周期、复权算法和样本：免费返回最近100条，并不能完成需要多年日线的研究；只覆盖当前仍交易的股票，也需要检查是否符合历史样本设计。

做行情看板，重点则是目标证券、需要的交易时段和数据时间。至少保留两种时间：

• 行情时间：返回的数据对应哪个时点。
• 接收时间：自己的程序什么时候收到响应。

程序现在收到响应，并不代表主报价就在此刻更新。主交易时段、盘前和盘后也可能分字段返回，应用要明确展示哪一种。判断数据过期时，应先结合所需交易时段与市场状态，而不是休市期间一律按“超过10秒”报故障。

验收时，用自己的完整标的清单逐个核对：是否返回目标证券、必要字段是否有值、日期范围是否足够、时间与计算方式是否匹配。目录里出现某只股票，只能先确认产品身份；账户能否查询相应数据，还需实际调用。

四、从个人研究到产品上线免费股票API的使用边界

把脚本交给同事，不一定会增加上游请求。如果后端统一获取并缓存，多个页面可能共用同一份输入；是否增加请求取决于实现方式。

但接收和使用数据的人发生了变化。个人研究、团队内部计算、内部看板、客户展示、对外提供数据接口，应在需求表中分开写。Twelve Data Basic标注“内部非展示”，就不能直接被当作客户行情页面的使用依据。

上线前，把“我们要商用”改成可以回答的问题：

数据用于哪些市场和字段？谁会看到？是否对客户收费？是否允许导出？是否把原始数据继续提供给第三方？需要保存多久？

将这些具体用途交给服务商确认，并保存适用条款或书面答复。安装了开源库、付费取得Key，或者成功返回一次行情，都没有代替这一步。

一张可直接填写的判断表

以下为开头项目的规划样例，未完成的地方如实留空。它不是已上线项目的验收报告。

不需要把所有项目都变绿才开始做原型。但若“客户展示条件”未确认，就先保持个人或已获许可的测试范围；若20个目标标的没有检查完，就别把一个样本写成覆盖承诺。

在阿里云上落地时的检查点

如果看板准备部署在阿里云上，选型表之外还要把运行环境写清楚。以下为部署建议，不改变前文对接口条件的判断。

• 运行位置：轮询服务可以放ECS常驻，也可以用函数计算FC定时触发；刷新间隔要与函数超时、并发和下游额度匹配。
• 密钥管理：API Key放KMS或服务端环境变量，不进前端代码；日志里对Key和完整请求头做脱敏。
• 缓存复用：用Redis缓存同一轮批量结果，让多个页面共用一份输入，避免每个浏览器各自打上游。
• 对外入口：用API网关统一鉴权和限流，安全组与VPC控制出口；不要把手里的Key直接发给前端。
• 监控告警：用日志服务SLS记录原始返回、接收时间和错误码，用云监控对失败率、数据过期和额度接近上限做告警。
• 失败降级：未取得新数据时返回最近成功时间和过期状态，页面不要继续显示成当前价格。

五、接入检查：先核对证券再取一次报价

在这个任务中，数据接入路径要能同时服务研究原型和行情应用。这里选择已经连接的行情 MCP，先核对证券，再取得一次报价，留下可检查的返回记录。TickDB 为开发者和 AI 应用提供统一的全球行情数据接口，让团队通过一套接入获取多市场实时与历史数据，更快构建行情、分析和监控产品。

实际操作顺序

1. 在支持MCP的客户端中，按服务商当前配置说明连接服务，使用自己的Key；密钥保存在本地配置中，不贴进提问。
2. 调用get_available_symbols，参数为market="US"、type="stock"、limit=1000、offset=0。本次目录页中找到AAPL，名称为Apple Inc.、市场为US。
3. 按报价工具的证券代码格式，调用get_ticker，参数为symbols="AAPL.US"、type="stock"。本次目录和报价使用的代码写法不同，需核对市场与工具规范。
4. 保存原始返回，再从中提取证券、行情时间、字段是否存在，并另记本机接收时间。

已连接行情 MCP 的读者也可以直接向助手发出这条任务：

使用已连接的行情数据 MCP，先在US股票目录中确认Apple，
再查询AAPL.US的股票报价。保存完整原始JSON，
另列symbol、timestamp及last_price是否有值，记录接收时间。
不要把一次查询写成连续测试；权限不足时保留实际错误。

2026年11月9日，本次MCP调用返回的摘要如下。摘要从原始返回提取；未展示行情价格数值。

entry: TickDB MCP / get_ticker
API code: 0
symbol: AAPL.US
timestamp_ms: 1793998800000
main_quote_time_utc: 2026-11-06T21:00:00Z
retrieved_at_utc: 2026-11-09T04:39:46Z
has_last_price: true

返回同时包含扩展时段报价对象，上面只提取主报价的timestamp。准备展示盘前、盘后或其他时段数据时，应按目标字段分别处理，不能把主报价时间改写成本次取数时间。

同轮另用Python测试REST入口时，网关返回HTTP 403，错误为Cloudflare 1010；该入口本次未通过。MCP结果与REST失败均保留在取证记录中。所用账户的套餐等级未核验，不能据此判断免费账户也能取得相同样本。

需要继续做同类验证，可在服务商官网确认当前能力、接入入口和使用条件。这里先完成一个样本的身份与返回检查；20只股票的连续更新、目标账户权限及看板用途，仍按上面的判断表逐项完成。

最后，免费股票API能承担哪一段工作

如果任务是个人历史研究，且所需样本、数据定义和用途条件都满足，免费工具可能已经够用。

如果任务是验证页面、字段和交互，有限额度或限时试用也可以承担原型阶段。此时应记录到期日与尚未满足的条件，方便交接。

如果准备让团队或客户持续使用，就按正式运行时长、完整标的清单和真实用途重新验收。不要只看剩余请求次数：数据范围、持续时间、订阅容量和使用条件，任何一项都可能改变方案选择。

现在就把项目的标的数、刷新频率、每日运行时长和使用对象填进判断表，先解决其中最影响交付的一项未知。这样选出来的免费股票API，才有明确的适用范围。