免费 API 接口推荐与实测怎么写才可核对：把榜单换成候选记录，把实测换成调用记录
一句话回答
本次没有可用的接口正文材料，因此不列具体接口榜单，任何接口的可用性、额度与性能均待核实。文章给出可操作的替代做法：把“推荐”降级为带条件和记录日期的候选记录，把“实测”定义为包含环境、方法、范围和结果的可重跑调用记录；未实际运行的请求只能标为未执行的示例。
这篇不能给出“免费 API 接口推荐榜”。本次没有可用的正文材料，任何具体接口的可用性、免费额度、价格和性能都待核实；在这种情况下编一份清单，等于把不确定性包装成结论。可以给出的是一套写法：让“推荐”变成可撤回的候选记录，让“实测”变成别人能重跑的调用记录。
免费清单最容易漏掉的是条件#
“免费 API”不是一个稳定属性，而是一组条件的组合：额度按分钟、按天还是按月计；是否需要实名或企业认证；是否仅限非商业用途；响应数据能否缓存或再分发。条件变一条，结论就可能反转。这是推断，但足以说明为什么清单必须带条件、带记录日期，而不是只带名字和一句话介绍。
推荐部分：每条候选至少记六个字段#
下面的字段是记录格式，不是接口清单。没有材料支持的条目一律留空并标注状态，不要用“常见”“据说”补齐。
- 用途与文档入口：原始文档地址，而不是聚合站的转载页。
- 免费口径：时间窗、单位、是否区分成功与失败请求。
- 认证方式：是否需要密钥，密钥放在请求头还是查询参数。
- 条款要点：与数据留存、二次使用相关的那一句原文。
- 记录日期：这条信息是哪天看到的。
- 未核实项：明确列出，不藏在正文里。
实测部分：一次调用要留下什么#
“实测”是强度很高的说法。只有保留可核验的调用记录，才能使用；否则应写成“未执行的示例”或“根据文档推断”。一次合格的调用记录包含四块：
- 环境：语言与版本、运行位置、是否经过代理。缺一项就视为不可复现。
- 方法：请求行、必要请求头、脱敏后的参数。密钥只写
YOUR_KEY。 - 范围：调了几次、覆盖哪些响应分支、是否包含异常路径。
- 结果：状态码、耗时区间、响应体结构。不要贴完整原文，避免把账号数据带进文章。
# 未执行的示例：只演示记录格式，域名与密钥均为占位
curl -sS -D headers.txt \
-H "Authorization: Bearer YOUR_KEY" \
"https://api.example.com/v1/items?limit=1"
示例中 -D 用于保存响应头，便于事后核对限流相关字段。真实端点、参数名和认证头需按目标文档替换——这些内容本次材料未提供，同样待核实。该命令未在本机运行，不能当作实测结果。
免费额度上的三条边界#
| 边界 | 要核对什么 | 查不到时怎么写 |
|---|---|---|
| 计量口径 | 时间窗、计数单位、重置时刻 | 标注“文档未提供，待核实” |
| 失败请求 | 4xx / 5xx 是否计入配额 | 不要默认不计入 |
| 数据去向 | 请求内容是否留存、是否用于训练 | 读条款原文，不转述二手总结 |
把“待核实”写得简短#
不要在每个小节重复同一句“需进一步确认”。做法是集中一张状态表：字段、当前状态、复查日期。后续更新只改状态行，不重写全文；读者也能一眼看出哪些结论已经过期。
如果要把这套方法用起来，先挑一个候选接口，把六个字段填满，再决定要不要写“推荐”。填不满的那几行，就是这篇文章真正的边界。
