Frankfurter vs ExchangeRate-API：两个免费、无需密钥的选项对比

Frankfurter 完全没有配额，但每天只发布一次，且只在营业日，数据来自欧洲央行。ExchangeRate-API 的开放访问同样无需密钥，也是每天更新一次，但附带署名要求，并禁止转发原始数据。该选哪一个，取决于你的项目怎么用这些数据，而不是哪个名字更耳熟。

两者免费提供的共同部分

现在就对任意一个服务发一个 curl 请求，都能拿到 JSON 数据。没有注册表单，没有生成密钥的步骤，也不需要信用卡——这在这个领域里比想象中更少见，也是它们双双出现在几乎所有"免费汇率 API"清单上的原因。

但过了第一次请求，两者就不再相似。Frankfurter 是一个独立的开源项目，发布欧洲央行的参考汇率。ExchangeRate-API 是一个带付费套餐的商业产品，open.er-api.com 是这个产品免费、无需认证的那一小块——一个漏斗，之所以比一般免费套餐宽松，是因为公司靠上面带密钥的套餐赚钱。

Frankfurter：无密钥、无配额、仅限 ECB

Frankfurter 把 ECB 参考汇率封装进一个干净的 JSON API。任何套餐都没有 API 密钥，也没有强制的请求配额——这个项目不对你计量。它是开源的，所以在把生产流量指向它之前，代码是可以检查的。

限制在于底层数据，而不是这层 API 封装。ECB 参考汇率每个营业日发布一次，大约在 16:00 CET，周六周日完全不发布——请求一个周末日期，得到的是上一个周五的定盘价，因为 ECB 自己那天就没发布过。

ExchangeRate-API：无密钥、一条署名文字、一项限制

open.er-api.com 这个开放访问端点同样不需要 API 密钥——调用方式和调用 Frankfurter 一样直接，无需任何配置。它每天更新一次，和 Frankfurter 节奏相同，但数据来源不是 ECB。

附带两个条件：署名，展示"Rates By Exchange Rate API"并附回链到 exchangerate-api.com；以及不得转发，你不能重新发布原始数据流，不过为自己的应用做缓存是允许的。超出请求限制会返回 HTTP 429；限制会在 20 分钟后解除。一个不要求署名的带密钥套餐，每月提供 1,500 次请求。

并排对比

# Frankfurter — no key, ECB reference rates
curl "https://api.frankfurter.dev/v1/latest?from=USD&to=EUR,GBP"

# ExchangeRate-API — open access, no key, attribution required in your UI
curl "https://open.er-api.com/v6/latest/USD"

不同场景该选哪个

一个内部仪表盘本来就没有需要展示署名的界面，所以 ExchangeRate-API 的条件也就无关紧要，两个数据源都能用。这时可以按你更想检查代码（Frankfurter）还是更想在流量增长后有个带密钥的升级路径（ExchangeRate-API）来选。

如果是公开的界面——比如一个货币换算器，或产品页上的价格小组件——署名这一行就开始变得重要了。Frankfurter 不带这个义务。如果一条可见的署名链接对你的产品无关紧要，ExchangeRate-API 的开放访问同样好用。

在把高频的定时任务指向任意一方之前，先把细则读清楚。Frankfurter 声明没有强制配额，听起来像不限量，但这不是一份有文档记录的 SLA。ExchangeRate-API 对自己的上限说得很明确——超限、返回 429、等 20 分钟。

周末最清楚地暴露了仅限 ECB 的数据来源问题。想象一个周六的旅行预订流程需要展示一个汇率，而不是一个五天前的占位数字——只要法兰克福那天市场休市，就没有 ECB 定盘价，也就没有新鲜数字，不论是哪个周末。

如果两个都不合适

两者按设计都是每日一次的快照，对相当一部分外汇使用场景——开票、会计导出、周报——来说，这个新鲜度已经够用。如果你的项目需要反映一小时前变化的汇率，那就是另一类数据源了，exchangerate.dev 是其中一个选择：一个带密钥的 API，在主要货币对上有实时更新的数据源。它不是要在各自的规则下替代其中任何一个——而是当盘中新鲜度真正成为需求时的那个选项。