稳定、快速、免费的 api 接口服务

免费接口最坑的不是慢，而是你不知道它什么时候慢、什么时候直接不通，等你上线了才发现。这篇不讲协议怎么兼容，也不讲客户端怎么配，只讲一件事：拿到一批免费接口候选后，怎么用可重复的方法量出稳定性与速度，再决定哪个能长期挂在生产链路上。

免费接口最坑的不是慢，而是你不知道它什么时候慢、什么时候直接不通。等业务上线、用户开始用了才发现某条链路三天两头上不来，那时候换接口的成本比一开始挑接口高得多。所以这篇只讲一件事：拿到一批免费接口候选之后，怎么用可重复的方法量出稳定性和速度，再决定哪个能长期挂在生产链路上。

不讲协议怎么兼容，也不讲客户端怎么配，那些是别的文章的事。这里默认你手上已经有一份候选清单，缺的是一套判断标准，以及能反复执行的验证动作。核心思路很简单：先把底线写死，再用探针和日志拿到数字，最后按数字和条款做取舍。

先定基线，再谈稳定和快

没有底线就没法判断什么叫稳定。你要先明确自己能接受多长的首字延迟、连续失败几次就重试、一天断几回还能忍。这些数字每个人不一样，但必须提前写下来，否则评测到最后只会变成「感觉还行」。

连接延迟

建立连接握手花的时间，反映网络路径和入口质量。

首字延迟

从发出请求到收到第一个字符，聊天类交互主要看这个。

整段完成时间

从请求到全部内容收完，批处理和长文本任务看这个。

永久免费额度

额度长期存在、可按周期重置，适合做长期方案。

活动期免费

只在特定窗口内免费，只适合做临时兜底。

关于「免费」还得拆开看：是永久额度、按天或按周期重置的额度，还是活动期免费。这三类能承担的角色完全不同，把它们混在一个清单里比较是没有意义的。先量出自己的网络延迟基线，之后讨论接口本身快不快才成立，可以到 /tools/speed-test 做这件事。

用探针和日志把「感觉慢」变成数字

只跑一次的结果没有参考价值，网络抖动、对方临时扩容都能让单次结果偏得离谱。固定同一提示词、同一时段、同一台机器，连续跑多轮，记录成功率和各段耗时，才是有意义的数据。

• 日志至少记四个字段：请求时间、耗时分段、状态码、错误类型，缺了任何一个事后都难以复盘。
• 把失败分类：连不上、读超时、被限流、内容被截断，这四类的处理方式完全不同。
• 对比同一接口在高峰期和非高峰期的耗时，差异过大说明它用的是共享资源。
• 每次改动（换参数、换网络、换入口）之后重新跑一遍，保证数据可比。

记录口径尽量统一，否则几轮数据放在一起会互相打架。站内 /tools/verify#probes 和 /tools/quality-monitor 里有现成的检测与监控口径，可以拿来对齐自己的字段定义，别自己发明一套再对不上。

超时、并发与降级的参数怎么设

1. 从小并发开始试先跑一个很低的并发，确认全成功，再逐步往上加，记录每一档的错误率。
2. 找到拐点就退回一旦错误率或耗时明显抬头，说明触到了对方的限流或资源上限，退回上一档作为稳定工作点。
3. 把兜底接上主接口失败时切备用源，或降级到更轻的处理方式，保证业务不中断，而不是把错误直接抛给用户。
4. 验证兜底真的会生效手动把主接口指向一个不可用地址，看备用链路是否按预期接管，这一步不能省。

上线前的自测清单

下面这些是上线前必须跑一遍的项，任何一项没过，都不建议把它放进核心链路。注意这里说的都是「怎么做」，具体达标线按你自己的业务底线来定。

• 连续多天、跨不同时段跑通过率，而不是某一晚跑得挺好就下结论。
• 对比高峰期与非高峰期的耗时差异，差异大的只适合做非关键任务。
• 模拟触发限流，观察多久恢复；恢复时间长的要准备长期备用方案。
• 确认接口方明确写了使用条款与额度口径，条款含糊的先不要上生产。
• 确认返回内容的格式稳定性，避免出现偶发截断或结构变化。

免费接口能长期用，靠的不是它一次都不出错，而是它出错的时候你有准备。

什么情况下别用免费接口

免费接口不是不能用，而是有些事情不适合交给它。判断标准就一条：这条链路的失败或延迟，会不会直接伤害到你的用户或数据。

• 涉及用户隐私或商业数据的场景，先确认对方的条款与数据留存口径，说不清就别接。
• 对延迟有硬要求的实时交互场景，免费接口的抖动通常扛不住。
• 流量已经上量、按当时的成本核算已经明显不划算时，省这点不划算，去 /official-api 和 /plans 对比当时的数字再决定。
• 需要长期可追溯和稳定 SLA 的关键业务，免费接口给不了这类承诺。

反过来，对延迟不敏感、可重试、失败了也不影响用户体验的内部任务，免费接口很合适。判断依据始终是你那条链路的底线，而不是别人说某家快不快。