免费 API 接口推荐与实测：没有可核验记录时，先写清记录格式
一句话回答
本文不提供具体免费接口清单：本次写作没有可引用的接口文档、条款或测试记录，具体接口名、配额与延迟数据均无法核实。文章给出一条可核验记录的字段清单、一份未执行的记录骨架示例，并区分一次成功调用能证明与不能证明的范围。
核心要点 TL;DR
- 没有原始文档链接、测试时间与样本量的“实测”，只能算一次调用记录，不能当作稳定性证据。
- 记录时把来源事实、本人观测与推断分开写，未知项直接标“待核实”，比填一个看似精确的数字更有用。
先说结论：如果你想要的是“免费 API 接口清单 + 实测数据”，这篇文章不提供。本次写作没有任何可引用的接口文档、服务条款或测试记录，因此任何具体接口名、免费额度数字、延迟与成功率都会是编造。能给出的，是一套把“推荐”变成可核验条目的记录格式，以及判断别人写的“实测”值不值得采信的最小标准。
为什么“推荐清单”本身不构成证据#
- 时效无法判断。免费额度、鉴权方式和商用条款会变。没有来源发布日期的条目，你无法知道它描述的是哪一版规则。
- “实测”缺少范围。一次返回 200 的调用，只说明某个时刻、某个网络、某组参数下的结果，不足以支撑“稳定可用”。
- 转述链会丢信息。清单类文章常互相转抄，读到的第 N 手描述可能已经不是原始文档的表述。摘要不等于全文，链接存在也不等于事实已核验。
一条可核验的记录应该写清什么#
下面这张表不是验收标准，而是记录字段：字段缺一项，结论的适用范围就窄一档。
| 字段 | 记录要求 | 缺失时怎么写 |
|---|---|---|
| 文档地址 | 指向官方原始文档，而非二手文章 | 标“来源待核实”，不填替代链接 |
| 时间 | 来源发布日期与你测试的时间分开记 | 标“时间未知” |
| 免费额度口径 | 按日还是按月、按 IP 还是按 Key、是否需要信用卡 | 标“待核实”，不写“免费”二字了事 |
| 鉴权方式 | Key 放在 Header 还是 Query，是否支持轮换 | 标“待核实” |
| 限流行为 | 超限返回什么状态码、是否带重试提示 | 标“未测试” |
| 数据来源与许可 | 数据出处、是否允许商用、是否要求署名 | 标“条款待核实” |
| 观测范围 | 若声称稳定，需给出窗口、样本量与失败定义 | 不写稳定性结论 |
未执行的示例：把一次调用写成一条记录#
下面的骨架未执行，域名与密钥均为占位（example.com、YOUR_KEY），时间戳字段留空表示待填。它示范的是格式，不是任何真实接口的结论。
{
"endpoint": "https://api.example.com/v1/items",
"doc_url": "待填：官方文档地址",
"doc_published": "待核实",
"tested_at": "待填：ISO 8601 时间",
"environment": "待填：运行时版本、出口地区、是否走代理",
"auth": "Header: Authorization: Bearer YOUR_KEY",
"request": "GET /v1/items?limit=10",
"observed": { "status": 200, "body_bytes": 0, "latency_ms": null },
"sample_size": 1,
"claim": "仅记录本次观测",
"inference": "待补充：可复现后再写",
"unknowns": ["免费额度口径", "限流行为", "商用条款"]
}一次成功调用能证明什么，不能证明什么#
能证明的：在该网络、该时刻、该参数下，服务返回了该状态码与该形状的载荷。不能证明的：额度是否够你的用量、条款是否允许你的用途、峰值时是否限流、跨地区表现是否一致、接口是否会在下个版本变更。把这两类写在同一段里，读者就没法判断哪句是事实、哪句是推断。
采用之前先写下三行#
- 用途与替代方案：这个接口不可用时，退回到什么。没有退路就不要把它放进关键路径。
- 失效条件：额度变更、条款变更、连续失败达到多少次就切换。
- 复核时间与负责人：谁在什么时候重新核对文档，避免记录变成过期传闻。
读别人的“免费 API 实测”时，先找三样东西：原始文档链接、测试时间、样本量。三样都没有，可以当线索，不要当依据。
至于具体哪些接口值得用，本次材料不足以支撑任何推荐，相关配额、条款与可用性均需你自己对照官方文档核实。
