“免费 API”清单先别照抄：缺少正文与实测记录时，开发者怎么自己核验

标题问的是“有哪些免费 API 值得用、实测如何”。但本次写作没有拿到任何接口正文、配额说明或可核验的调用记录，因此不能给出推荐名单，也不能声称做过实测。可行的做法是缩小范围：把“推荐与实测”改写成一套开发者自己能执行的核验流程——先确认哪些说法可以查证，再决定是否把一个接口接进代码。

为什么这里不给榜单#

“免费”在接口语境里通常不是单一事实，而是四组条件的组合：免费额度、认证方式、限流规则、数据来源与再分发许可。任何一项缺失，接入后的成本都会从流量费转成维护费。没有正文时，把某个接口写成“免费可用”属于推断，不是事实；把某个响应时间写成数字，则属于虚构。

把“免费”拆成四个可查项#

在阅读任何接口文档时，建议逐项落到原文，而不是记住结论：

• 额度口径：按日、按月还是按总量？计数单位是请求数、记录数还是字节？超额后是拒绝、降速还是转为计费？这些应能在文档或价格页找到明确表述。
• 认证与限流：密钥放在请求头还是查询参数；匿名调用是否存在；限流维度是密钥、IP 还是账号；超限返回的状态码与 Retry-After 是否说明。
• 数据来源与许可：聚合数据是否标注原始提供方，是否允许缓存与二次分发，商用是否需要另行授权。这一项常被忽略，却决定项目能否上线。
• 变更与弃用政策：是否有版本号、弃用公告期、状态页或变更日志。没有这些信息时，应把“接口会变”视为默认前提。

四项中若有任一项在文档里找不到，结论应写成“待核实”，而不是“默认可用”。

最小核验脚本（未执行示例）#

下面的片段只用于演示核验顺序：先打状态端点，再打一个业务端点，记录状态码、耗时、响应类型与重试提示。域名与密钥均为占位，该示例未在任何环境执行，输出不作实际结果。

# 未执行示例：域名 api.example.com 与 YOUR_KEY 均为占位
import json, time, urllib.request, urllib.error

BASE = "https://api.example.com/v1"
KEY  = "YOUR_KEY"

def probe(path, timeout=5):
    req = urllib.request.Request(
        BASE + path,
        headers={"Authorization": "Bearer " + KEY, "Accept": "application/json"},
    )
    t0 = time.monotonic()
    try:
        with urllib.request.urlopen(req, timeout=timeout) as r:
            body = r.read(4096)
            return {"status": r.status, "ms": round((time.monotonic()-t0)*1000),
                    "ctype": r.headers.get("Content-Type"), "bytes": len(body)}
    except urllib.error.HTTPError as e:
        return {"status": e.code, "ms": round((time.monotonic()-t0)*1000),
                "retry_after": e.headers.get("Retry-After")}
    except Exception as e:
        return {"error": type(e).__name__, "ms": round((time.monotonic()-t0)*1000)}

print(json.dumps([probe("/status"), probe("/items")], ensure_ascii=False))

脚本本身不证明接口可用，它只把“我调用过”变成可复核的记录。真正需要观察的是：正常响应与限流响应是否返回一致的错误结构，以及文档承诺的状态码是否实际出现。

把失败边界写进代码#

• 为连接与读取分别设超时，不依赖库的默认值。
• 对 429 与 5xx 使用指数退避，并尊重 Retry-After；对 4xx 中的参数错误直接失败，不重试。
• 为每个外部接口保留降级路径：缓存上一次成功结果、返回空态或切换到备用来源，而不是让上游故障穿透到页面。

什么算一条“实测”记录#

只有按上述字段留下记录，才适合使用“实测”一词；单次成功调用不构成对可用性的判断。

边界#

本文不评价任何具体服务，也不提供配额数字与性能结论——这些需要以各接口的原始文档和发布说明为准，本次材料未提供。对 API.PLUS 的读者而言，更稳妥的下一步是：挑一个候选接口，先补齐四个可查项，再用上面的骨架跑一次记录，然后才谈“推荐”。