exchangerate.host 需要密钥了，有哪些替代方案

如果一个跑了好几年的脚本突然开始返回 401 或"配额超限"的提示，原因几乎可以肯定是这个：exchangerate.host 已经并入 APILayer，原本无需密钥、事实上不限量的端点，现在需要注册，且免费套餐每月只给100 次请求。付费套餐从每月 $14.99 起，可获得 10,000 次请求。以下是现实中的可选方案，包括你应该停止寻找、直接用免费方案的那种情况。

究竟发生了什么变化

exchangerate.host 曾以免费、无需密钥著称：不用注册，直接发一个 GET 请求即可。那个版本已经不存在了。它现在由 APILayer 运营，每个请求都需要一个绑定账号的 apikey 请求头。

免费套餐只允许每月 100 次请求。对于一个原本每天要调用几百次的项目来说，这个上限第一周都撑不过去。付费访问从每月 $14.99 起，可获得 10,000 次请求。

如果每天一次的 ECB 汇率就是你所需要的全部

在比较各家付费方案之前，先想清楚自己是否真的需要其中一个。Frankfurter 是开源的，也不需要任何 API 密钥。它封装了欧洲央行的参考汇率，在每个营业日约 16:00 CET 发布一次，周末没有数据——周六显示的是周五的收盘价，而且现在还有了自己的 MCP 服务器，位于 mcp.frankfurter.dev。

如果你的场景是一个仪表盘、一份报表，或者一个只需要"今天的官方汇率"的批处理任务，这个每日一次的更新节奏，本身可能就已经够用。如果不够，下方附有完整的迁移指南和端点映射表。

现实中的可选方案，逐一对比

各家的差异在于免费套餐限制了什么：基础货币、调用次数，或两者都限。

ExchangeRate-API：无需密钥，但要读清署名条款

ExchangeRate-API 在 open.er-api.com 运行一个开放访问端点，无需密钥，和 Frankfurter 一样每天更新一次。但你需要展示"Rates By Exchange Rate API"并附带回链，且不得转发原始数据。触发请求限制会返回 429，20 分钟后解除。它也有一个带密钥的套餐，每月 1,500 次请求。

Open Exchange Rates：1,000 次请求，但锁定 USD

Open Exchange Rates 每月提供 1,000 次免费请求，每小时更新一次，并包含每日历史数据。问题在于：免费套餐固定使用 USD。如果基础货币是 IDR 或 GBP，就需要自己在客户端做换算，或者每月付 $12 来解锁任意基础货币、时间序列和换算调用。

Fixer：100 次调用，仅限 EUR，没有换算端点

Fixer 的免费套餐每月允许 100 次 API 调用，每小时更新，包含历史数据。基础货币被锁定为 EUR，且在 BASIC 套餐之前没有换算端点——/convert?from=USD&to=IDR 无法使用，你得自己取数再做乘法。

exchangerate.dev 在其中的位置

exchangerate.dev 的免费版每月提供 10,000 次调用、每分钟 12 个请求，注册无需信用卡。匿名、无密钥调用同样可用，便于快速试用，按 IP 限速。任何套餐都没有基础货币限制——目录中 465 个货币对中的任何一个都可以作为基础货币。每个套餐（包括免费版）都免费包含追溯至 1999 年的每日历史数据，不设付费门槛。

主要货币对在交易周内大约每 60 秒更新一次；大多数其他货币对也是如此，其余部分由 ECB 和 FRED 参考汇率补充。每条响应都携带 source、market_session、timestamp、data_updated_at 和 notice 字段，让你的代码无需靠猜测就能分辨实时即期汇率和每日定盘价。每个套餐（包括免费版）都随附一个带密钥的 MCP 服务器，配额与 REST API 相同。

curl "https://api.exchangerate.dev/v1/latest/USD?symbols=EUR,GBP" \
  -H "Authorization: Bearer exr_live_..."

# {
#   "base": "USD",
#   "rates": { "EUR": 0.87531, "GBP": 0.7412 },
#   "source": "live",
#   "market_session": "open",
#   "timestamp": "2026-08-01T09:14:02Z",
#   "data_updated_at": "2026-08-01T09:13:58Z",
#   "notice": "Indicative rates for reference and analytics; not a dealing quote."
# }

迁移过程中真正会踩的坑

脱离一个无需密钥的端点，需要改动的不只是 URL。要加上 Authorization 请求头或 apikey 参数，因为上面除了 Frankfurter 和 ExchangeRate-API 的开放访问端点外，其余方案都需要密钥。字段命名也没有统一标准，一个原本读取 rates.EUR 的脚本，换到字段嵌套方式不同的新服务商时可能悄无声息地失败。

请求限制值得配上重试逻辑，而不是耸耸肩了事。当免费套餐的配额只有低几百次每月时，一个没有退避机制的重试循环可能在几分钟内烧光一整天的配额。请积极使用缓存，把每月配额当作硬性上限对待。

怎么选

按影响你代码的限制来匹配：需要零配置的每日一次 ECB 汇率——选 Frankfurter；愿意加上署名文字——选 ExchangeRate-API 的开放端点；需要 USD 或 EUR 以外的基础货币，或者需要盘中波动——这正是包括 exchangerate.dev 在内的带密钥方案要填补的空缺。