免费 API 接口怎么筛、怎么验证：先写核对表，再谈推荐
一句话回答
本次没有可核验的接口文档与测试记录，因此不给出具体免费接口名单。文章把“免费”拆成永久额度、限速免费、试用金、开源自托管四类核对项，并给出可复核实测记录应包含的字段与一段未执行的测量骨架，结论是先建记录再谈推荐。
这篇不给具体的免费接口名单。本次写作没有可核验的接口文档、价格页或测试记录，任何“某某接口免费又好用”的写法都只能算猜测。能交付的是两件事：把“免费”拆成可以逐项核对的条件，把“实测”写成别人能重放的记录。具体接口的额度、限速与条款，需以各发布方官方文档为准，本次材料未提供，标为待核实。
“免费”至少是四种不同的东西#
把下面四类混在一起谈，选型就会失真。每一类要核对的东西不一样。
- 永久免费额度：通常按每月请求数或每日配额计。要核对重置周期、按账户还是按 IP 计数、超额后是直接拒绝还是转入计费。
- 限速免费：总量不设上限，但限 QPS 或并发。要核对超限时的状态码、响应体里是否给出重试等待时间。
- 试用金 / 试用期：到期后自动转付费是常见设计。要核对是否需要预先绑定支付方式、试用金是否可累积。
- 开源可自托管：成本从“钱”变成机器与运维。要核对许可证、镜像来源、数据从哪里来。
以上是核对项，不是任何一家的实际情况。逐项填完，才知道一个接口对你这个场景算不算免费。
让“实测”可被复核：一条记录至少要有什么#
只写“跑通了、挺快”，别人无法验证，也无法在出问题时定位。建议每次测量落一条结构化记录，字段如下。
| 字段 | 为什么需要 |
|---|---|
| 时间窗（含时区） | 限速与配额按周期重置，脱离时间窗的数字没有意义 |
| 出口位置与网络 | 延迟和可达性高度依赖链路 |
| 样本量与请求间隔 | 并发一高，结论就变，必须能重放 |
| 成功/失败计数、状态码分布 | 区分“慢”和“被限流” |
| 延迟分位，注明口径 | 是客户端总耗时还是首字节时间，两者不可混用 |
| 响应字节数 | 体积直接决定带宽与缓存策略 |
| 是否消耗免费额度 | 同一接口不同端点的计费口径可能不同 |
| 接口版本与文档地址 | 接口会变，记录要能对上是哪一版 |
字段齐全才叫实测；缺项就只能说“我这边跑过一次”。
一段记录骨架（未执行示例）#
下面的命令本次未执行，端点与鉴权头都是占位，仅示意该把哪些量抓下来。真实端点和鉴权形式必须以官方文档为准。
# 未执行示例：只演示需要落盘的字段
curl -sS -o /dev/null \
-w '%{http_code} %{time_total} %{size_download}\n' \
-H "Authorization: Bearer YOUR_KEY" \
"https://api.example.com/v1/demo"把每次输出追加进一个 jsonl 文件，连续跑一段固定时间窗，再统计状态码分布和延迟分位。样本量、间隔、时长都写进记录，别人才跑得出同一组数。
先定条款边界，再谈速度#
- 返回内容的许可与再分发条件，能否缓存、能否二次分发。
- 是否允许商业或生产环境使用，是否要求署名或回链。
- 请求内容是否被留存、留存多久。
- 对脚本、代理、自动化流量的限制。
这四项都要回到发布方文档核对，本次未核验。速度再快，条款不允许就不能进生产。
结论#
顺序是：先写核对表，把小样本记录跑成可重放的格式，再决定推不推荐。在拿到官方文档和可核验记录之前，给出“推荐清单”只是在替读者猜。
