免费 API 接口推荐与实测：没有可核验记录时，结论该缩到哪里
本次材料只有主题名，没有接口正文、官方文档或执行记录，因此不能给出具体免费 API 推荐或实测结论；应把候选接口写成待核验记录，并明确免费条款、配额、许可和可用性需由官方材料支持。
这篇不提供具体免费 API 名单，也不把任何接口称为“实测可用”。原因不是主题不重要，而是本次写作材料只有“免费 API 接口推荐与实测”这一主题名，没有接口正文、官方文档、服务条款、配额说明、响应样本或执行记录。缺少这些依据时，具体推荐以及性能、可用性结论都只能算猜测。本文也省略具体名单、价格比较和性能对比，因为材料不足以支撑这些章节。
来源事实：本次材料未提供可核验的接口清单、文档或测试记录，也未提供来源 URL，因此正文不附具体接口链接。推断：无法据此判断某个接口是否免费、是否允许商用、配额多少、是否稳定。建议：把文章目标缩小为“怎样记录候选接口，直到它有资格被推荐”。
“免费”不是单一属性#
对开发者来说，一个接口被称为“免费”，至少要拆成几类可核验信息：调用配额与限流、商用许可、数据使用条款、鉴权方式与密钥管理、可用性承诺。这些信息应以官方文档、服务条款或发布说明为依据；本次材料未提供，正文不能填写具体值，也不能推断某个接口“应该免费”。
把“推荐”改成待核验记录#
与其先写“十大免费 API”，不如先维护一张候选表。每个字段都应有来源；没有来源就留空或标为待核实，不写推测。下面字段只是记录建议，不是对任何真实服务的评价。
| 字段 | 记录方式 | 用途 |
|---|---|---|
| 接口名与用途 | 一句话描述，不写营销词 | 避免把不同能力混在一起比较 |
| 官方文档 | 记录具体页面地址 | 让读者能复核参数和错误码 |
| 免费计划 | 摘录原文并注明条款位置 | 区分试用、免费额度和长期免费 |
| 配额与限流 | 记录单位、时间窗和超限行为 | 防止接入后才发现容量不匹配 |
| 鉴权与密钥 | 说明密钥是否可放服务端 | 避免密钥进入前端或仓库 |
| 许可与数据使用 | 链接到条款原文 | 判断商用与数据留存边界 |
示例：下面是占位记录模板，不是某个真实接口的记录，也未执行。example.com 与 YOUR_KEY 均为占位。
{
"candidate": "候选接口 A",
"docs_url": "https://example.com/docs",
"checked_at": "YYYY-MM-DD",
"free_plan": "无来源则留空",
"quota": "无来源则留空",
"auth": "无来源则留空",
"commercial_use": "无来源则留空",
"evidence": ["官方文档 URL", "条款 URL"],
"notes": "占位示例，未执行"
}“实测”需要可复现记录#
只有存在可核验测试记录时，才适合写“实测”，并说明环境、方法和范围。若后续要把候选接口变成实测，至少应保留测试日期与时区、调用环境、请求方法与脱敏参数、响应状态码与关键字段、错误样本、配额消耗和复现步骤。本次没有运行任何端点，因此本文不包含实测结果；代码模板也不代表调用成功。
发布时的边界#
不要把摘要当成全文，不要把检索到链接等同于事实已经核验，也不要补造版本、价格、可用性和性能数字。未知项写“待核实”；不能确定是否为最新情况时，不写“最新”。如果文章必须给名单，应把名单标为“候选”并附核验状态，而不是“推荐”。
可交付的窄结论：在本次材料条件下，免费 API 的推荐与实测必须以官方文档、条款和可复现记录为依据；缺少这些依据时，应输出待核验候选表，而不是具体名单或“实测”结论。这样至少能让读者看到哪些信息已经核验、哪些仍需自行确认。
