摘要：面向准备将研究原型交付为行情看板的金融产品负责人，本文以“20只美股、每10秒刷新”为例，拆解免费股票API的数据范围、更新频率、额度、订阅和使用条件。结合AKShare、Alpha Vantage、Twelve Data与TickDB的官方说明，以及一次TickDB MCP调用记录，提供可填写的选型判断表和可运行的用量计算代码，帮助团队判断免费方案能用到哪一步、交付前还需补什么。
假设你准备把一个个人研究脚本，改成可供同事或客户查看的股票行情看板：先放20只美股，每10秒刷新一次。
最初的进展通常很快：取得Key，调用接口，页面出现价格。真正准备交付时，问题才陆续出现：20只股票都能取到吗？刷新一小时会消耗多少额度？试用结束后还能运行吗？自己电脑上能看的数据，能不能放到客户页面上？
选择免费股票API，先把自己的任务写成使用条件，再逐项判断免费方案是否满足。核心是数据、用量、持续时间和使用范围。某一项尚未确认，就把它留在交付待办里，别让“已接通”替代整个选型结论。
一、先认清“免费”具体免了什么
搜索“免费股票数据API”，会同时看到开源库、免费额度和商业服务试用。它们解决的起点不同，不能只按“有没有费用”排成一张榜。
| 免费形式 | 你实际得到什么 | 使用前最该确认什么 |
|---|---|---|
| 开源工具 | 可安装、阅读或修改的软件，以及获取数据的实现方法 | 上游数据来源、适用用途和接口维护要求 |
| 长期免费额度 | 满足特定条件时可持续使用的一部分服务资源 | 每分钟、每日、每标的或每端点如何计量 |
| 限时试用 | 一段时间内体验指定功能或样本 | 到期时间、试用标的和正式需求有多大差距 |
| 限定用途的访问 | 允许在某种场景中使用数据 | 个人研究、内部计算、内部展示和客户展示分别如何约定 |
这些条件可能叠加在同一个方案上。一个免费层可以既限每日额度，也限数据范围和使用场景。
下面用四个熟悉的入口说明区别。表中为2026年11月9日核对的官方说明，调用记录另列在后文。
| 入口 | 官方说明中的关键条件 | 放进选型表时怎样理解 |
|---|---|---|
| AKShare | Python开源财经数据接口库；项目说明主要用于学术研究，并提示商业风险 | 适合先核对研究所需数据与维护方式；软件开源不自动解决上游数据的使用条件 |
| Alpha Vantage | 常规免费服务为每日25次API请求；经验证的开源或教育项目有单独安排；实时及15分钟延迟美股数据列为付费内容 | 先确认所需数据时效是否可用，再计算调用量 |
| Twelve Data | Basic列出每分钟8个API credits、每日800个；用途标注为内部非展示 | 同时检查端点权重、日额度和展示用途；不能只数HTTP请求 |
| TickDB | 官网Free列为7天试用、指定标的、5个同时订阅、1个WebSocket连接和每分钟30次API请求 | 分别核对期限、目标标的、请求与订阅限制；试用体验不替代正式交付验收 |
这里最容易漏掉的是：免费取得软件、免费发起请求、免费使用某类数据，是三个不同问题。后面还要加上第四个问题——这些数据准备给谁使用。
图1：按项目逐项检查四类条件。某一项通过，不代表其他项已经满足。
二、把需求写具体，才算得出免费额度够不够
“支持股票行情”太宽。对于开头的看板，先写下六个条件：
- 对象：确定的20只美股，列出完整代码，不写“美股若干”。
- 数据：主交易时段的报价；需要哪个时间字段，允许多大的数据年龄。
- 频率：应用每10秒请求一次；接口更新频率另行确认。
- 运行时间：先测试1小时，随后按实际每日运行时长重新计算。
- 使用方式：先个人测试，交付同事或客户前分别确认条件。
- 失败处理：未取得新数据时显示过期状态，不能只留下旧价格。
“每10秒刷新页面”描述的是应用动作。数据源如果只提供日终数据，页面刷新得再快，也不会多出盘中信息。同样，换成WebSocket只是换了接收方式，数据范围和使用条件仍然要核对。
1. HTTP请求、额度单位、同时订阅要分开算
为说明计量区别，先做一个明确的假设：一个接口允许每次查询20只股票；每只股票每轮消耗1个额度单位；一小时内从第0秒开始每10秒查询一次，到3600秒前结束，共360轮。暂不计初始化、重试和其他接口。
由此得到：
| 计算对象 | 算法 | 结果 |
|---|---|---|
| HTTP请求 | 每分钟6轮，每轮1次 | 每分钟6次 |
| 标的额度 | 每分钟6轮 × 20只 × 每只1单位 | 每分钟120单位 |
| 一小时请求 | 6 × 60 | 360次 |
| 一小时额度 | 120 × 60 | 7,200单位 |
一次请求能装下20只股票，只减少了请求次数；按标的计量时，20只股票仍分别消耗额度。Twelve Data的官方计量示例就按端点权重与标的数计算credits。其他服务采用什么规则，仍要看对应端点，不能套用这张演算表。
如果改成推送，并假设每只股票只占一个订阅单位，20只股票需要20个同时订阅。一个WebSocket连接可以承载多少订阅，是另一项限制；连接数不能当成标的数。
图2：假设计量演算。轮询与推送是两种方案；图中的数字不是TickDB收费规则或套餐承诺。
2. 用这段Python先算自己的项目
保存为budget.py，使用Python 3.10或以上版本运行python3 budget.py。仅使用标准库，无需Key，也不会发出网络请求。把开头的参数换成目标接口的真实计量规则。
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线，两项任务可能共同消耗账户额度。
三、额度够了，还要检查数据是否适合任务
个人研究和行情看板对“有数据”的要求不同。
做历史研究，重点是目标日期范围、周期、复权口径和样本：免费返回最近100条，并不能完成需要多年日线的研究；只覆盖当前仍交易的股票，也需要检查是否符合历史样本设计。
做行情看板，重点则是目标证券、需要的交易时段和数据时间。至少保留两种时间：
- 行情时间：返回的数据对应哪个时点。
- 接收时间：自己的程序什么时候收到响应。
程序现在收到响应，并不代表主报价就在此刻更新。主交易时段、盘前和盘后也可能分字段返回，应用要明确展示哪一种。判断数据过期时，应先结合所需交易时段与市场状态，而不是休市期间一律按“超过10秒”报故障。
验收时，用自己的完整标的清单逐个核对：是否返回目标证券、必要字段是否有值、日期范围是否足够、时间与口径是否匹配。目录里出现某只股票，只能先确认产品身份；账户能否查询相应数据，还需实际调用。
四、从个人研究到产品上线，真正变化的是使用方式
把脚本交给同事，不一定会增加上游请求。如果后端统一获取并缓存，多个页面可能共用同一份输入；是否增加请求取决于实现方式。
但接收和使用数据的人发生了变化。个人研究、团队内部计算、内部看板、客户展示、对外提供数据接口，应在需求表中分开写。Twelve Data Basic标注“内部非展示”，就不能直接被当作客户行情页面的使用依据。
上线前，把“我们要商用”改成可以回答的问题：
数据用于哪些市场和字段？谁会看到？是否对客户收费？是否允许导出？是否把原始数据继续提供给第三方？需要保存多久？
将这些具体用途交给服务商确认，并保存适用条款或书面答复。安装了开源库、付费取得Key，或者成功返回一次行情，都没有代替这一步。
一张可直接填写的判断表
以下为开头项目的规划样例，未完成的地方如实留空。它不是已上线项目的验收报告。
| 检查项 | 本项目要求 | 目前记录 | 下一步 |
|---|---|---|---|
| 标的范围 | 指定20只美股 | 目前只验证了AAPL样本 | 补齐20只清单，按目标账户核对 |
| 数据与时段 | 主交易时段报价，页面保留行情时间 | 取得一条主报价时间记录 | 在目标交易时段检查更新情况 |
| 轮询容量 | 每10秒一轮，测试1小时 | 假设批量20只时为360次HTTP请求 | 确认批量能力及账户实际计量规则 |
| 推送容量 | 若用推送，按所选频道计算订阅需求 | 尚未运行WebSocket | 核对频道与同时订阅限制 |
| 试用期限 | 测试后计划持续运行 | 需记录账户到期日 | 确定到期后的安排，避免原型突然中断 |
| 使用范围 | 个人测试后交付内部或客户看板 | 对外展示条件待确认 | 提交具体用途，保存答复 |
| 运行验收 | 目标时段持续更新，失败后有过期提示 | 尚未完成连续测试 | 记录成功、失败、缺失与恢复情况 |
不需要把所有项目都变绿才开始做原型。但若“客户展示条件”未确认，就先保持个人或已获许可的测试范围；若20个目标标的没有检查完，就别把一个样本写成覆盖承诺。
五、用TickDB做一次小范围接入检查
在这个任务中，TickDB的作用是提供研究原型和行情应用所需的数据接入路径。官方股票页列明A股、美股、港股的REST查询和WebSocket推送；这里选择已经连接的MCP，先核对证券，再取得一次报价，留下可检查的返回记录。
实际操作顺序
- 在支持MCP的客户端中，按TickDB当前配置说明连接服务，使用自己的Key；密钥保存在本地配置中，不贴进提问。
- 调用
get_available_symbols，参数为market="US"、type="stock"、limit=1000、offset=0。本次目录页中找到AAPL，名称为Apple Inc.、市场为US。 - 按报价工具的证券代码格式，调用
get_ticker，参数为symbols="AAPL.US"、type="stock"。本次目录和报价使用的代码写法不同，需核对市场与工具规范。 - 保存原始返回，再从中提取证券、行情时间、字段是否存在，并另记本机接收时间。
已连接MCP的读者也可以直接向助手发出这条任务：
使用已连接的TickDB 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失败均保留在取证记录中。所用账户的套餐等级未核验，不能据此判断免费账户也能取得相同样本。
需要继续做同类验证，可从TickDB股票API页面确认当前能力、接入入口和使用条件。这里先完成一个样本的身份与返回检查；20只股票的连续更新、目标账户权限及看板用途，仍按上面的判断表逐项完成。
最后，先决定免费方案可以承担哪一段工作
如果任务是个人历史研究，且所需样本、数据口径和用途条件都满足，免费工具可能已经够用。
如果任务是验证页面、字段和交互，有限额度或限时试用也可以承担原型阶段。此时应记录到期日与尚未满足的条件，方便交接。
如果准备让团队或客户持续使用，就按正式运行时长、完整标的清单和真实用途重新验收。不要只看剩余请求次数：数据范围、持续时间、订阅容量和使用条件，任何一项都可能改变方案选择。
现在就把项目的标的数、刷新频率、每日运行时长和使用对象填进判断表，先解决其中最影响交付的一项未知。这样选出来的免费股票API，才有明确的适用范围。