免费 API 的实测边界：先定义观察项，再谈推荐结论
没有可核验调用记录与服务商条款正文时，“推荐一批免费 API 并给出实测结论”无法完成。本文把“测过”拆成可达性与解析、响应契约、限额行为、失败与降级四类观察项，说明每类能支持与不能支持的结论，并给出一个仅用于边界探测、未执行的请求骨架，最后划定结论可写的范围。
如果目标是“推荐一批免费 API，并给出实测结论”，那么在既没有可核验调用记录、也没有服务商条款正文的情况下，这个目标无法完成。本文只回答更窄的一层问题：一次调用要观察到什么，才算“测过”；哪些结论即使测过也推不出来。具体服务商名单、免费额度数字、限流阈值与可用性，本次材料未提供，待核实。
“能用”为什么不等于“测过”#
一次 200 响应只说明某个时刻、某条路径通了。从工程角度看，通常需要分开观察的是：端点是否可达、响应结构是否符合预期、超限时返回什么、客户端在失败时怎么表现。前四者是观察项，可以记录；“稳定”“推荐”是结论，需要跨时间窗的样本支撑。这里的分类是写作时的工程取舍，不是行业标准定义。
四类观察项与各自的证据边界#
| 观察项 | 需要记录 | 可以支持的结论 | 不能支持的结论 |
|---|---|---|---|
| 可达性与解析 | 请求方法、路径、状态码、DNS 与 TLS 是否成功 | 该端点在记录时刻可达 | 服务长期稳定 |
| 响应契约 | 成功体字段与类型、错误体结构、Content-Type | 文档示例与实际响应是否一致 | 所有参数分支都一致 |
| 限额行为 | 超限时的状态码、错误体、是否存在重试提示 | 该路径在超限时的表现 | 具体配额数字（需条款或响应头佐证） |
| 失败与降级 | 超时、5xx、空体、字段缺失时客户端的行为 | 客户端在这些失败下的表现 | 服务端的故障率 |
表中刻意不填任何数值：没有条款正文与长期记录，数字只能写成“待核实”，而不是估一个看起来合理的区间。
一个只做边界探测的请求骨架#
下面的示例只用于确认“能不能拿到结构化响应”，不评估性能。域名与密钥均为占位，示例未执行，输出不应当作实际结果。
# 环境：任意带 curl 的 shell；未执行
curl -sS -D headers.txt -o body.json \
-H "Authorization: Bearer YOUR_KEY" \
"https://api.example.com/v1/status"保留响应头（-D）是因为限额、缓存与内容类型信息常出现在头部，而正文里往往看不到。运行前需把 api.example.com 换成经确认的端点，并核对密钥的可用范围。
三种常见误读#
- 把文档示例当契约。示例通常只覆盖一条成功路径，参数组合与错误分支需要单独观察。
- 把单次 429 当故障。超限属于限额语义的一部分，应与错误体和重试提示一起读，而不是直接记为不可用。
- 把免费额度当容量依据。额度是准入条件，不是容量承诺；生产容量需要另行评估，这一点在没有条款正文时尤其不能默认。
结论能写到什么程度#
在没有条款正文与长期记录的情况下，可写的结论只有两类：一是客户端侧的契约与降级设计，它不依赖具体服务商；二是“某时、某环境、某路径返回了什么”，它必须随时间与环境一起出现。任何“最推荐”“最稳定”的排序，都属于待核实。
若要把评估写成对外文档，最低要求是记录可复现：端点、时间、方法、状态码、响应片段，以及明确标注未覆盖的部分。缺了这些，“实测”只是一个词，不构成证据。
