免费 API 接口推荐与实测：缺可核验记录时，先做这五项核对
本次写作没有可用的接口文档、条款原文或调用记录，因此无法给出具体接口的推荐清单与实测数据。文章给出的是接入前的核对顺序：读官方条款原文、确认鉴权与密钥暴露面、确认限速维度、确认配额耗尽后的行为与数据保留，并用最小探针记录可复核的字段。文中代码为未执行示例。
如果你在找一份「免费 API 接口推荐 + 实测」的清单，这篇给不出。本次写作没有任何可用的接口文档、条款原文或调用记录，也无法联网核验；具体哪些服务免费、额度多少、延迟多高，都属于待核实。把二手列表页当成结论，是这类选型里最常见的错误来源。本文只做一件事：给出一个可以自己走完的核对顺序，让「免费」这个词变成可检查的条件。
为什么这里没有榜单#
一份可用的推荐清单至少需要三样东西：条款原文（说明免费的范围与限制）、稳定的端点文档（说明参数与错误码）、以及一段有环境与方法的调用记录。三者缺一，「推荐」就退化成传闻。材料不支持的比较指标，这里一律留空，不用印象补。
「免费」通常附带四类约束#
- 额度与限速：每日或每月调用上限、每秒请求数，以及限速按 IP、按密钥还是按账号计算。这三者决定你在多实例部署时会不会互相挤占。
- 用途限制：是否允许商用、是否要求署名、是否禁止与特定类型的业务组合使用。具体条款须读原文，本文不代述。
- 数据处理：请求内容是否被记录、保留多久、是否用于改进模型或对外共享。涉及用户数据时，这一项优先级高于价格。
- 可用性与变更：有没有服务等级承诺（SLA）、弃用是否提前通知、免费层是否会被单方面调整。免费层通常不承诺 SLA，这一点要以条款为准。
接入前的核对顺序#
- 先找到官方文档与条款原文，不要以聚合列表页为最终依据；列表页的更新往往滞后于条款。
- 确认鉴权方式。密钥不进前端：浏览器、小程序、移动端都应通过自己的服务端转发，否则等于公开。
- 确认限速维度与配额耗尽的返回码。配额用尽时返回 429 还是 403，直接决定你要不要写退避重试。
- 确认日志与数据保留策略，尤其当请求里会带用户标识或自由文本时。
- 用一个最小探针跑一次真实请求，记录状态码、耗时、响应头里的配额字段。这一步不能靠读文档替代。
一段未执行的调用骨架#
下面是形状示例，未执行：域名、路径与头部字段均为占位，须替换为你实际核对过的文档值。预期输出不作为结果使用。
# 未执行的示例，仅示意结构
# 环境：任意装有 curl 的 shell；YOUR_KEY 为占位密钥
curl -sS -D headers.txt \
-H "Authorization: Bearer YOUR_KEY" \
"https://api.example.com/v1/resource?limit=1" \
-o body.json
# headers.txt 中通常值得看：状态码、剩余配额、重试等待时间
grep -i -E "^(HTTP/|x-ratelimit|x-retry-after)" headers.txt
探针的意义不是证明接口「能用」，而是先把失败路径暴露出来：鉴权失败长什么样、配额耗尽长什么样、超时如何表现。这些响应如果不提前看到，就会在生产环境的第一次故障里看到。
把「实测」写成别人能复核的记录#
只有当记录同时包含环境（地域、客户端版本）、方法（并发数、样本量、时间窗）和结果（成功率、分位延迟、失败码分布）时，才可以称为实测。缺任何一项，都只是个人轶事。本文没有这类记录，也不代填数字。若你要写自己的评测，建议把时间窗与比较基期一并写清，否则「平均延迟 200 毫秒」没有解释力。
什么时候不该用免费接口#
三种情况建议直接放弃免费层：请求涉及个人数据而你无法确认其保留策略；业务需要明确的可用性承诺；以及调用量已经接近限速上限、靠重试维持的那一类。此时成本不在账单上，而在故障处理与合规解释上。具体服务的付费档位与条款，仍以官方页面为准，本文不作判断。
