“免费 API 接口推荐与实测”：没有测试记录时，先交一份可复现的验收标准

先说结论：本文无法给出“免费 API 接口推荐 + 实测”的名单。本次可用的只有主题标题，没有接口正文、没有发布方文档、也没有任何可核验的调用记录。在这种情况下，把某个服务写进“推荐”或标成“实测”，都会越过事实边界。下面给的是替代方案——怎样把“推荐”降级为条件式结论，以及一条测试记录至少要写清什么，别人才可能复核。

为什么“实测”两个字不能顺手用#

“实测”是一项承诺：它意味着说明运行环境、测试时间窗、调用方法、样本量与结论范围。缺任何一项，读者都无法判断结论是否适用于自己的场景。常见的问题是只写“很快”“比较稳定”“免费额度够用”，却不写样本量多大、什么算成功、失败怎么分类；或者把一次成功请求当成可用性结论。这类文字读起来像结论，实际只是印象。

一条测试记录至少要包含什么#

下面这张表可以直接当作模板用。它的作用不是让记录变长，而是让第二个读者能重现同一件事。

这张表里最容易被省略的是“成功判定”和“条款核对日期”。前者决定失败率怎么算，后者决定这条结论还能用多久。

最小调用骨架：只负责记录，不负责下结论（未执行示例）#

下面的片段是骨架代码，本次未执行，不包含任何真实端点；域名与密钥均为占位。它只做三件事：固定超时、把每次调用写成结构化一行、失败也照写。

import time, json, urllib.request

ENDPOINT = "https://api.example.com/v1/demo"   # 占位，非真实地址
KEY = "YOUR_KEY"                                # 占位，不写入报告

def probe(i, timeout=5.0):
    req = urllib.request.Request(ENDPOINT, headers={"Authorization": f"Bearer {KEY}"})
    t0 = time.perf_counter()
    row = {"n": i, "ok": False, "status": None, "ms": None, "bytes": None, "err": None}
    try:
        with urllib.request.urlopen(req, timeout=timeout) as r:
            body = r.read()
            row.update(ok=200 <= r.status < 300, status=r.status, bytes=len(body))
    except Exception as e:            # 超时、连接失败、非 2xx 都落到同一行的 err 字段
        row["err"] = type(e).__name__
    row["ms"] = round((time.perf_counter() - t0) * 1000, 1)
    return row

for i in range(3):                    # 样本量示意，不是一次实测的规模
    print(json.dumps(probe(i), ensure_ascii=False))

样本量、请求节奏和是否并发，要按你的目标写死并记进报告。跑一轮就贴出结论，风险不在脚本，而在把“跑通一次”当成了“测过”。

把推荐写成条件式结论#

• 先写适用条件。例如：“若用途是原型期的低量读取、单次调用可接受数秒级超时，则该端点可作候选。”条件之外的情况，读者自己会排除。
• 免费边界单列。速率限制、配额重置口径、鉴权方式、数据使用与商用条款需逐项核对，以官方文档当前版本为准；本文无法代为断言这些条款的具体内容，均属待核实。
• 失败路径写清。超时、限流、空响应各自的重试次数、退避与降级动作，要能被别人照着实现。
• 标注保鲜期。写明条款与端点的核对日期，过期即重新核对，不沿用旧结论。

本文的边界#

本文不提供厂商名单，不声称访问或调用过任何端点，不给出任何性能数字或额度数字。若确实需要发布一份带“实测”字样的内容，顺序只能是：先有可复现的记录，再由记录推出结论。反过来做，就只是转述。