最佳免费金融数据 API

1. 覆盖范围必须对应真实问题

覆盖很多证券代码，并不等于数据真正可用。回测需要复权历史和公司行为，基本面分析需要报告期与披露日期，宏观研究需要发布日期和修订记录，行情应用则需要明确的交易所标识。我们还会检查是否提供退市证券、拆股分红、财报重述和历史时点数据。

2. 数据时效必须写清楚

“最新”可能指实时、延迟 15 分钟、日终，也可能只是最近一次修订后的宏观观测值。研究型产品使用日线通常没有问题，但提醒和交易类应用就可能不够。可靠的数据源应当明确时间戳、更新周期和复权口径，而不是让开发者靠猜。

3. 免费额度要能完成一次真实验证

每天能请求多少次只是第一层限制。有的接口会消耗多个积分，有的免费套餐限制历史深度，还有的只允许个人研究，不允许公开展示。我们会把“技术上能够调用”和“法律上能够用于产品”分开判断。接口返回 200，并不代表你拥有再分发数据的权利。

4. 数据要便于复现和维护

稳定的证券标识、清晰的空值、统一的时区、分页规则、修订信息和批量下载能力，往往比一个好看的 SDK 更重要。进入生产环境后，团队必须能重放请求、追溯来源、发现字段变化，并解释同一个指标为什么前后不同。

Twelve Data：适合快速搭建多资产原型

如果一个应用希望用相近的接口同时读取股票、外汇和加密资产，Twelve Data 是比较省事的起点。官方公布的 Basic 免费额度足以支撑小型自选列表或概念验证，但积分会按接口和证券数量计算。一个看似只有一次的多标的刷新，可能消耗多份额度。因此，真正做成面向用户的行情页之前，还要单独确认交易所覆盖和展示授权。

Alpha Vantage：功能很多，但免费日额度较小

Alpha Vantage 覆盖时间序列、公司基本面、经济指标、技术指标、外汇和加密资产。官方支持页写明，多数免费数据集每天最多可请求 25 次。这个额度适合学习、定时抓取少量标的或验证解析程序，却很难支撑频繁刷新的行情看板。另外，官方明确说明美国股票实时和延迟 15 分钟的数据属于付费内容，因此不能把默认免费响应直接标成“实时行情”。

FMP：适合需要标准化公司数据的研究产品

Financial Modeling Prep 把公司资料、三张财务报表、财务比率、关键指标、分析师预期、电话会文本、申报文件和历史价格放在同一套 API 下。稳定版文档包含 100 多个端点，并区分标准化报表、原始披露和衍生指标。对研究型产品来说，这能省掉大量字段映射工作。不过，不同套餐对应的端点、历史深度和额度并不完全相同，接入前应在账户中逐项验证，不能因为文档里有这个接口就默认免费套餐也能使用。

SEC EDGAR：美国公司披露的一手来源，不是现成财务比率库

SEC 的数据 API 不需要认证密钥，可读取公司申报历史和从 XBRL 中提取的公司事实数据。若目标是核对美国上市公司的原始披露，它是这份清单中最权威的一手来源。但开发成本也更高：不同公司可能使用不同标签，财年并不统一，修订文件会覆盖旧值，而且 data.sec.gov 不支持浏览器跨域调用。请求时应提供清晰的 User-Agent，遵守 SEC 的公平访问规则；抓取大范围公司时，优先使用其夜间更新的批量 ZIP 文件。

FRED 与世界银行：用来补充宏观和跨国背景

FRED 面向经济序列、发布批次、分类和观测值，第一版 Web API 需要申请密钥。对于历史回测，带有当时版本信息的数据尤其重要，否则模型可能误用后来修订过的数值。世界银行 Indicators API 更适合跨国指标，支持按国家、指标和日期范围查询，也支持分页、JSON、XML、JSON-stat 以及文件下载。二者都不是实时股票行情源，不应拿来替代市场报价。

CoinGecko 与交易所原生 API：一个用于发现，一个用于执行

CoinGecko 适合做加密资产发现、市值比较、市场快照和交易所覆盖。如果产品需要可成交的买卖价、订单簿深度或特定交易所的低延迟数据，就应改用对应交易所的原生 API，并保留交易场所时间戳。聚合市场价格和可执行报价回答的不是同一个问题。

如果统一覆盖股票、外汇和加密资产比深度基本面更重要，可优先考虑 Twelve Data。

美国权威申报优先使用 SEC EDGAR；需要标准化财报与比率时再补充 Financial Modeling Prep。

利率、通胀、就业、产出等宏观序列优先选择 FRED。

广泛资产发现与市场快照可选 CoinGecko；若需要订单簿或交易级延迟，应使用交易所原生 API。

第一步：先写清楚数据契约

列出必需字段、计量单位、时间戳、可接受延迟、复权方式和空值规则。以日线为例，要明确收盘价是否复权、采用哪个交易日历、成交量是否随拆股调整；以财报为例，则要明确报告期、披露日期、币种、原始值或标准化值，以及遇到重述时如何处理。

第二步：发起一个能人工检查的请求

请求最好能直接复制到浏览器或 HTTP 客户端中。世界银行官方文档给出的 URL 结构很适合做无密钥测试，例如 https://api.worldbank.org/v2/country/US/indicator/NY.GDP.MKTP.CD?format=json&date=2020:2024。它的响应包含分页元数据和观测值，解析程序不能想当然地把第一个数组当成数据行。

第三步：用一手记录对账

抽取几个返回值，与公司申报文件、交易所公告或统计机构原始发布进行核对。比较数字之前先比较日期和单位。同一个金额，一个以千美元计，一个已经换算成美元，看起来会相差一千倍，但两边可能都没有错。

第四步：主动制造失败场景

尝试无效证券代码、没有观测值的日期、触发本地限速，并在分页中途断开连接。记录状态码、重试响应头、错误正文以及部分结果的处理方式。只有成功路径跑通，并不能说明采集任务足够可靠。

第五步：按真实用量计算额度

用“标的数量 × 接口数量 × 刷新次数 × 用户规模”估算请求量，再加上重试和历史回补。多个用户需要同一份数据时应共享缓存，不会变化的历史数据只抓一次。如果免费套餐支撑不了测算后的负载，就把它用于评估，生产阶段购买合适授权，而不是依赖轮换密钥规避限制。

先描述所需能力，再检查具体工具

可以直接描述业务任务，例如“读取某家公司最近披露的营业收入”或“比较多个国家的同一经济指标”，不必一开始就写死供应商名称。正式发起请求前，应先检查工具说明、必填参数和返回字段。

数据校验不能交给路由层代替

应用仍然需要执行时效阈值、证券代码映射、单位转换、许可范围和对账规则。路由负责找到可调用的能力，数据契约负责判断结果能不能被产品接受。

备用方案必须语义等价

备用来源不能只是“还能返回数据”。用未复权的盘中成交价替换复权日收盘价，或用预测指标替换公司已经披露的 GAAP 数值，都会悄悄改变问题本身。每次请求最终由哪个来源完成，应当被明确记录。