免费API接口资源有哪些

想省钱先试用免费接口，这个思路没错，但很多人卡在两处：一是不知道去哪找还在开放的免费额度，二是拿到 Key 之后没几天就调不通，也说不清是被限流、被回收还是自己写错了。这篇不讲协议细节，只给一份资源分类清单和接入前的核对顺序，让你在动手写代码之前先把边界摸清楚。

想省钱先试用免费接口，这个思路没问题，但很多人卡在两处：一是不知道去哪找还在开放的免费额度，二是拿到 Key 之后没几天就调不通，也说不清是被限流、被回收还是自己代码写错了。先明确一点，免费资源的价值是帮你把原型跑起来、把集成方案验证一遍，不是替你扛生产流量。

下面不讲协议细节，只给一份资源分类清单和接入前的核对顺序。你按顺序走一遍，大概就知道自己手上的免费额度能用在哪一层，以及什么时候该老老实实换方案。

免费 API 资源大致分哪几类

先按供给方分，这一层决定了你能不能长期指望它。官方厂商的试用额度、云平台的新用户配额、模型聚合平台的公共免费档、开源社区的自建托管，这四类的稳定性和开放周期差别非常大，混在一个清单里比较没有意义。

再按能力分就更清楚了：通用对话、嵌入向量、语音转写、图像生成、搜索与联网检索，多数平台的免费位只覆盖其中一两类。别指望一个 Key 把所有能力都试一遍，先想清楚自己最需要验证的是哪一项。

• 按获取方式看：注册即得、申请审批、公测期开放、限时活动，后两种最容易在你代码写完的第二天关门。
• 按调用位置看：能在浏览器直连的和必须走后端的，免费档经常只允许后者。
• 按数据要求看：有些免费档明确写了对输入内容的使用条款，涉及用户真实数据的场景先读清楚再决定。
• 具体哪些平台当前还开放、各自覆盖什么能力，去 /ai-nav/category/ai-api 和 /ai-nav/category/ai-model-platform 逐条核对，别照抄别人半年前的清单。

免费额度不是只有「多少 token」一个参数

只盯总量的人，往往最先撞墙的不是额度用完，而是并发或频率。免费额度至少要同时看四个口径，缺一个都会在后面吃亏。

总量额度

一段时间内累计可用多少，决定你能做多长时间的测试

单次请求上限

一次调用最多能带多少上下文，决定你要不要做切分

调用频率

每分钟或每天的请求次数上限，决定高峰时会不会被挡

并发路数

同时在跑的请求数上限，决定你能不能做批量压测

另一个高频坑是 Key 共用。开发、测试、演示如果都用同一个 Key，额度会互相挤占，出问题时你连是谁用掉的都查不出来。建议至少分三个 Key，命名里带上环境前缀。各家的限流与额度口径，去 /official-api/providers 下逐个厂商页面看，价格与规格类数字以页面当时显示为准。

拿到 Key 之后的核对顺序

Key 到手别急着往项目里塞，按下面四步走一遍。顺序别调，否则出了问题你会同时怀疑三件事。

1. 跑通最小请求用最简单的参数发一次请求，确认鉴权方式和 Base URL 写法正确。端点写法可参考 /ai-nav/category/ai-api 里的说明页面。
2. 量一条延迟基线用 /tools/speed-test 记下首字耗时和整体耗时，之后再说「变慢了」才有参照物。
3. 测边界并发提到多少开始失败、连续调用多少次后返回限流、超时设多少合适，把结论写进项目说明，别只留在脑子里。
4. 做降级准备免费源失败时切到备用源或返回兜底文案，多模型路由与降级的具体做法见本分区相关文章。

什么情况下这套流程不适用？如果你的场景要求稳定 SLA，或者涉及用户数据合规，免费接口从一开始就不该进主链路，它只适合做原型和内部验证。这不是保守，是省后面返工的力气。

日志与验证：让「调不通」变得可解释

免费资源出问题不可怕，可怕的是你只能说「昨天还好好的」。要让它可解释，第一步就是把日志字段固定下来。

• 请求日志至少记四项：发起时间、用了哪个 Key 或渠道、返回状态码、耗时，缺一项就无法复盘。
• 区分三类失败：鉴权类（Key 失效或被回收）、限流类（短时间大量返回限流）、链路类（超时、网关错误），三类处理动作完全不同。
• 给每个渠道加一个健康标记，连续失败到阈值就先自动摘掉，别等线上报错再手动查。
• 关键密钥和端点建议集中检测，而不是逐个手点，中转站与端点的实测做法见 /tools/verify。

想长期跟踪某个资源是否还活着，可以用 /ai-status 这类服务监控页面做交叉参考。注意单次检测结果只能说明那一刻，别拿一次成功就下结论。