免费 API 接口怎么选：先核对准入、配额、数据权利与退出成本

先给结论：没有可核验来源和调用记录时，不能给出可靠的具名免费 API 推荐，也不能声称做过“实测”。本文只说明如何核对“免费”的条件，以及怎样留下可复核的试用记录；具体接口、额度与商用条款待核实。

为什么先不列推荐清单#

一条可用的推荐至少需要三样东西：服务方当前文档、可复现的调用记录、对条款的核对。只有标题或摘要，无法判断接口是否仍可用；检索到链接也不等于事实已核验。把“免费”当成单一标签，容易漏掉注册门槛、配额窗口、超限行为和数据使用限制。下面的内容是评估框架，不是对任何服务的背书。

把“免费”拆成四个检查项#

先问清“免费”指哪一种：无需密钥的演示、注册后的免费额度、开放数据，还是可自托管的开源实现。这个分类只用于检查，具体归类以服务方文档为准。

• 准入：是否需要账号、密钥、OAuth 授权或企业认证；密钥作用域有多大。
• 配额：按秒、分钟还是月计数；突发请求如何计算；超限返回什么状态码和错误体。
• 数据权利：响应能否缓存、存储、再分发或商用；是否要求署名。以条款原文为准。
• 变更与退出：是否有版本号和弃用通知；数据能否导出；替换服务时错误信封是否兼容。

每项都应附上核对日期和文档地址；没有日期，结论很快过期。

试用记录：先定义“实测”再调用#

“实测”需要环境、方法、请求样本和观测范围。下面只是记录模板，未执行，字段值均为占位，不构成任何接口的实际结果。

{
  "test_id": "demo-001",
  "checked_at": "YYYY-MM-DD",
  "doc_url": "https://example.com/docs",
  "environment": "待填写：运行时与网络条件",
  "request": {
    "method": "GET",
    "url": "https://api.example.com/v1/items",
    "auth": "YOUR_KEY"
  },
  "observed": {
    "status": null,
    "latency_ms": null,
    "quota_headers": [],
    "response_shape": []
  },
  "error_case": "待填写：超限或参数错误时的状态码与错误体",
  "terms_checked": "待填写：商用、缓存、再分发条款",
  "conclusion": "待填写：仅限本次观测"
}

记录至少保留原始请求、响应状态、耗时测量方式和失败样本。耗时是单次、均值还是分位数要写清；没有样本量，不要写“稳定”。

推荐结论怎么写才不越界#

可以写条件式结论，例如（占位）：“在 YYYY-MM-DD 核对文档，并在某环境完成若干次调用后，该接口满足原型阶段的只读查询；未验证高并发与商用场景。”日期、次数和环境必须来自真实记录；没有记录就写“待核实”，不要补数字。更稳妥的格式是：适用场景、已验证范围、未验证范围、复核日期、退出方案。

本文没有给出具名接口、价格、限额、延迟或可用性排名，因为本次材料没有可核验依据。要把候选变成推荐，下一步是保存文档快照、执行受控请求并记录失败路径；在此之前，候选不等于结论。