免费 API 怎么选：没有实测记录时，先写一份可复核的验证清单
一句话回答
本文材料只有主题标题、没有正文，因此不列具体厂商与端点，也不声称做过实测。文章把“免费 API 推荐与实测”拆成三件可操作的事：先界定“免费”的成本口径，再用固定字段记录一次调用，最后说明在什么条件下才够格写“推荐”。
“免费 API 接口推荐”这类题目，读者真正想要的是一个可以直接粘进代码的地址。但本次素材只有主题标题，没有正文，既没有端点清单，也没有任何调用记录。因此本文不给具体厂商排名，也不写“实测通过”——这两个结论目前都没有依据。能交付的是另一半：把“实测”定义清楚，让你自己在半天内产出一份别人可以复核的记录。
第一步：先界定“免费”的口径#
“免费”不是单一属性。同一个端点，在不同口径下结论可能相反，所以选型前先把问题拆开：
- 额度型免费：每月或每日给一定调用次数，超出后计费或拒绝。需要核实重置周期与时区。
- 永久免费层：额度长期存在，但通常伴随更低的速率上限与无 SLA。
- 开源自建：软件免费，成本转移到服务器、带宽与运维人力。
- 试用期：时间或额度到期即停，属于“短期可用”，不是免费。
把候选端点归入上面四类之后，“哪个更划算”才有可比性。否则比较的是不同东西。
第二步：一次调用要留下哪些字段#
单次成功返回证明不了可用性。要写成“实测”，记录至少覆盖下表各项；缺少任何一项，结论都只能降级为“初步可用”。
| 字段 | 记录什么 | 为什么必要 |
|---|---|---|
| 端点与方法 | 完整 URL、HTTP 方法、必需的查询参数 | 没有它，结论无法复现 |
| 时间与时区 | 调用时刻（含时区） | 配额按日或按月重置，跨时区会错位 |
| 认证方式 | Header 还是查询参数，是否可轮换 | 决定密钥能否留在服务端 |
| 状态码与响应体 | 成功样本、至少一个错误样本 | 错误契约比成功形态更容易出问题 |
| 耗时 | 多次调用的分布，而非单次 | 单次数值不构成性能结论 |
| 限流信号 | 触发限流时的状态码与响应头 | 很多服务用 X-RateLimit-* 一类自定义头，命名不统一，需以实际响应为准 |
| 条款要点 | 是否允许商用、缓存、转售、留存数据 | 技术可用不等于合规可用 |
第三步：脚本骨架（未执行的示例）#
下面这段只示意“把响应头和耗时一起落盘”的写法，端点、密钥、响应均为占位，本文未实际运行，输出也不作为任何结果。
# 未执行的示例：占位端点与占位密钥
curl -sS -o body.json -D headers.txt \
-w 'http=%{http_code} total=%{time_total}\n' \
-H "Authorization: Bearer $YOUR_KEY" \
"https://api.example.com/v1/resource?limit=10"-D 保留响应头用于检查限流字段，-w 输出状态码与总耗时。把这两份文件连同调用时刻写入记录，同一条命令换人执行也能得到可比对的结果。批量跑时至少覆盖：正常调用、参数错误、超配额、断网四种情形。
什么条件下才够格写“推荐”#
建议设三道门槛，全部通过再写进推荐清单：
- 可复现：别人按记录重跑，得到同量级的状态码与耗时。
- 有错误样本：知道它失败时长什么样，以及错误体是否稳定。
- 条款已核对原文：免费层是否允许你的用途。这一条无法靠调用验证。
只满足第一条的，最多写“候选”；一条都不满足的，只能写“待验证”。
三个常见误判#
- 把“注册即送额度”当成免费——额度用尽后的行为（拒绝还是计费）才是关键。
- 用一次成功推断稳定性——没有触发过限流，就不知道降级路径是否可控。
- 跳过条款直接上线——技术可用与授权可用是两件事，前者不能替代后者。
结论#
在缺少可核验材料的情况下，对“免费 API 推荐”最强也只能给到候选清单加待验证项，而不是榜单。具体端点、当前额度、价格与可用性，本次素材均未提供，一律待核实；请以各服务方官方文档与实际调用记录为准。先建记录格式，再谈推荐，顺序反了，后面每个结论都要返工。
