说实话接口这个东西刚入行的朋友容易把它想得很神秘其实它就是一个程序对外提供服务的“窗口”。你发一个请求过去它把结果返回给你整个过程跟点外卖差不多。免费 API 接口最大的意义不是让你省钱而是让你在没有预算、没有服务端资源的情况下先把想法跑通把原型做出来。今天这篇不聊虚的把我这些年用过的、实测还能用的常用免费 API 接口整理一份清单顺便把申请、调用、排查的路子都走一遍适合刚接触接口开发的读者也适合想快速验证业务想法的朋友。我见过不少同学收藏了一堆接口列表真到用的时候却不知道怎么下手要么 Key 申请不下来要么请求一直报错最后又把项目搁置了。所以这篇文章不只是列地址而是把免费 API 的选型逻辑、调用姿势、常见坑都讲清楚。你可以把它当作一份查漏补缺的备忘录收藏之后照着操作比单纯存链接有用得多。1. 免费 API 接口怎么选先搞清楚你要的是哪一类1.1 免费 API 的类型与典型场景免费 API 看起来都叫“免费”但来源和性质差别很大。我自己习惯把它们分成三类分类不同使用策略就完全不同。第一类是官方产品对外开放的能力。比如微信小程序接口、企业微信接口、大模型对话接口。这类接口背后是大厂业务文档齐全、权限体系完整但往往需要注册开发者账号、实名认证有时还要审核。优点是稳定适合做正式产品。第二类是数据服务商提供的免费额度比如天气、翻译、股票行情、ISBN 图书查询。服务商提供免费接口是为了引流让你体验之后购买增值服务所以免费额度通常限制较严比如每月 500 次调用、每分钟 1 次。适合做个人项目、教学演示、内部工具不太适合直接扛线上流量。第三类是社区或爱好者维护的公益接口比如随机图片、随机名言、某些免费 API 聚合站。这类接口不需要注册拼一个 URL 就能用很爽但说不准哪天就挂了也没有任何服务承诺。适合做前端演示、做练习千万别用在关键业务上。理解了这三类你就能判断一个接口到底能不能用到生产环境。我的经验是正式项目优先选第一类实在没有合适的才退到第二类第三类只在本地开发或原型阶段用。1.2 选型背后的几个判断标准看完来源还要看具体指标。不同人关注点不一样但以下几条是通用的免费额度和限流是否够用。有的接口写着“免费”仔细一看每天只能调 20 次这种接口对演示都没太大价值。选型前先翻文档里的 Rate Limit 和计费说明。鉴权方式是否顺手。大多数现代接口用 API Key 放在请求头里字段一般是Authorization: Bearer key也有用X-API-Key的。老式接口可能会要求 IP 白名单换网络环境就麻烦如果两人协作开发还要把多台机器的 IP 都加进去。返回格式是否友好。优先选 JSON解析成本最低要是返回 XML 或自定义字符串处理起来很心累能绕开尽量绕开。稳定性是否可信。可以看接口服务商是谁、更新文档的频率、社区反馈。没有任何主体背书的接口默认按“随时会挂”来处理。这里顺带提一个思路如果有多套免费 API 都能满足需求不要一棵树上吊死。比如翻译接口和天气接口完全可以同时申请两家的免费额度平时用一家出问题切备用成本也几乎为零。2. 大模型 API豆包、Groq 等免费接口的调用实战2.1 免费大模型 API 怎么申请密钥大模型是这两年最热门的一类接口很多平台为了拉新都开放了免费体验额度。豆包是字节跳动旗下的大模型通常可以在火山引擎开放平台申请接入。流程大体是注册账号开通模型服务创建一个应用然后拿到 Access Key 和 Secret Key。不同平台的额度和有效期差别很大有的新用户赠送几百万 token有的只给几十次对话体验申请前要看清楚。Groq 是很多人推荐的低延迟推理服务商它推出的免费 API 近期关注度很高核心优势是响应速度快特别适合做聊天机器人、实时翻译之类对首字延迟敏感的应用。使用方式也很简单去官网注册账号创建一个 API Key然后用 OpenAI 兼容的请求格式去调就行。如果你不想逐个平台申请可以考虑聚合 API 服务商它们把多家模型统一封装成一个接口一次申请多个模型随意切换。要注意的是聚合服务意味着你的请求内容会经过第三方中转如果处理的是隐私数据需要谨慎评估是否合规。免费额度通常比官方更少更适合技术评估阶段使用。2.2 用 Python 发起第一次对话请求现在主流大模型的接口格式基本都向 OpenAI 看齐掌握一个就能快速迁移到其他平台。一个很典型的 Python 调用长这样import requests api_key 你的API Key url https://api.xxx.com/v1/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { model: free-model-name, messages: [ {role: system, content: 你是一个友好的助手}, {role: user, content: 请用三句话介绍杭州} ], temperature: 0.7 } response requests.post(url, jsonpayload, headersheaders, timeout30) data response.json() print(data[choices][0][message][content])第一次跑通这个脚本你就算是入门了。有几个容易被卡住的细节首先是model参数不同平台的模型 ID 差异非常大有的叫doubao-pro-32k有的叫llama-3.1-8b-instant直接照抄别家示例一定会报错务必以你申请平台的控制台看到的为准。其次是超时时间。大模型接口首字返回慢是常态本地网络慢的时候 10 秒都可能没响应timeout30是比较保守的起步值。再者返回结果不一定总是成功的请求报错时data里可能没有choices这个字段所以正式代码里要增加状态码判断和异常处理不要把data[choices]直接裸奔。2.3 Java 开发中如何封装供外部调用如果你做 Java 后端场景会不太一样。你不是自己调完就完事还要把大模型能力封装成接口供前端或者其他系统调用。我建议按这个方式组织代码第一步用配置类保存 API Key、基础 URL、模型名app: llm: api-key: your-key base-url: https://api.xxx.com model: your-model-id第二步写一个 LLMClient把请求、鉴权、超时、异常全部收敛起来对外只暴露一个干净的方法Service public class LLMClient { Value(${app.llm.api-key}) private String apiKey; Value(${app.llm.base-url}) private String baseUrl; Value(${app.llm.model}) private String model; public String chat(String userMessage) { // 构造请求头、请求体调用远程接口解析返回 // 统一处理超时、重试、错误码 return resultContent; } }第三步在 Controller 里暴露 HTTP 接口RestController RequestMapping(/api/ai) public class AIController { private final LLMClient llmClient; public AIController(LLMClient llmClient) { this.llmClient llmClient; } PostMapping(/chat) public String chat(RequestBody ChatRequest request) { return llmClient.chat(request.getMessage()); } }这个封装的核心价值在于上层调用方不需要关心 API Key 放哪里、模型名是什么、超时重试怎么做只传一个 message 就能拿到结果。等以后要换模型服务商只需要改配置和 LLMClient 内部实现Controller 层完全不用动。这种“门面”思想不管是接大模型还是接任何第三方 API 都适用。3. 通用工具类 API翻译、ISBN、股票行情3.1 搜狗翻译 API 的接入方式翻译 API 在个人项目和产品原型里使用频率很高。搜狗翻译曾经提供过免费接口适合做网页里嵌入的一句话翻译。这类接口本质上就是一个 HTTP 调用传入原文和语言代码返回 JSON 结果。比较麻烦的是鉴权方式经常变有的版本用简单参数有的版本需要计算签名。动手前一定先去对应开发者页面确认当前生效的规则不要拿网上两三年前的示例硬套。如果只是自用可以这样拼请求import requests url https://fanyi.sogou.com/api/trans/text params { from: auto, to: zh, text: hello world } response requests.post(url, dataparams) print(response.json())翻译接口的免费额度通常按字符数算长文本几段就耗完了。我遇到过一个项目上线前测试时一切正常上线后用户大量使用当天就把免费额度打满第二天所有翻译全挂了。后来把结果做了本地缓存同一个句子只翻译一次额度立刻够用了。这个思路对很多限流接口都适用缓存是成本最低的防线。3.2 ISBN 图书查询 API 与典型场景ISBN 接口适合做图书管理、二手书交易、读书打卡、图书馆小程序这些场景。最常见的方法是输入 ISBN 号返回书名、作者、出版社、出版时间、封面图。很多人第一时间会想到豆瓣读书接口但说实话豆瓣开放接口近几年已经不太稳定而且页面解析和反爬限制让人头痛不适合作为清单一劳永逸。更稳妥的方式是用专门的 ISBN 数据库服务商虽然免费版可能有每日请求上限但返回数据规范用起来省心。一次典型的请求长这样curl https://api.example-isbn.com/v1/isbn/9787020002207?keyYOUR_KEY返回结构通常类似{ isbn: 9787020002207, title: 红楼梦, author: 曹雪芹, publisher: 人民文学出版社, pubdate: 1996-12, image: https://example.com/cover.jpg }这类接口有个隐性问题很多 ISBN 数据库服务商在国外对中文图书的收录可能不全老版本图书尤其容易查不到。接入前先拿 20 本不同年份的中文书测试一下覆盖率。还有如果一个 ISBN 被频繁查询建议在本地建一张缓存表能少调一次接口就少调一次免费额度要用在刀刃上。3.3 免费股票 API 的取数逻辑股票行情接口是很多人会搜的常见选择是新浪财经和腾讯财经公开接口。它们的好处是不需要注册、不需要 Key拼一个 URL 就能拿实时报价适合做股票数据可视化、个人盯盘工具、学习爬虫和接口调试的练手项目。一个经典的新浪行情请求长这样import requests url https://hq.sinajs.cn/listsh600519 headers {Referer: https://finance.sina.com.cn} response requests.get(url, headersheaders, timeout10) print(response.text)这里有两个非常经典的坑。第一个是编码新浪接口返回的是 GBK 编码response.text直接用 UTF-8 解析会乱码需要先用response.content.decode(gbk)处理。第二个是 Referer 校验新浪最近加了防盗链不带Referer头直接请求会返回 403我周围不止一个人栽在这里。再说一遍免费股票接口只能用于个人学习和研究不能用于正式交易系统。如果你要做面向用户的行情功能必须接有合规资质的行情服务商这既是稳定性的要求也是合规底线。4. 开放平台与接口地址微信、FaceFusion 这类特殊 API 怎么找4.1 微信接口 API 常见地址与权限说明微信生态是绕不开的接口来源。公众号、小程序、企业微信都有官方 API文档地址统一在微信开放文档里。无论你要做什么第一步都是注册账号、成为开发者、拿到 AppID 和 AppSecret。几个最常用的接口地址值得收藏获取 AccessTokenhttps://api.weixin.qq.com/cgi-bin/token?grant_typeclient_credentialappidAPPIDsecretSECRET发送模板消息https://api.weixin.qq.com/cgi-bin/message/template/send?access_tokenACCESS_TOKEN小程序登录凭证校验https://api.weixin.qq.com/sns/jscode2session获取微信支付证书以微信支付官方文档为准使用微信接口有一个必须记住的原则AppSecret 绝对不要暴露在客户端代码里它在浏览器里等于公开秘密任何人拿到都能替你调接口。正确做法是把敏感调用放到自己的后端服务里前端只跟后端通信。同时AccessToken 有有效期通常是 7200 秒不要每次请求都重新获取要全局缓存并主动刷新。4.2 FaceFusion 有没有官方 APIFaceFusion 是近几年关注度比较高的开源人脸处理项目很多人搜它的 API 接口也很正常。实际情况是FaceFusion 主要提供源码部署和 Docker 启动两种使用方式官方并没有像大模型厂商那样提供一个云端 HTTP API 让你传一张图就能拿到结果。如果你想把它封装成接口思路是先在服务端把项目跑起来然后用 Python Web 框架比如 FastAPI写一个上传接口内部调用 FaceFusion 的处理函数处理完把结果图片返回给前端。这个过程并不复杂但涉及人脸数据时一定要慎重要确保用户明确授权、数据在传输和存储过程中加密、处理后的图片及时清理这些不仅是技术问题更是责任问题。4.3 其他值得收藏的开放 API 集合除了前面几类还有一批零散但特别好用的接口我平时会放在收藏夹里备用天气类和风天气、彩云天气都有个人开发者免费额度适合做天气卡片、旅行建议。随机数据类随机图片、随机名言、随机头像适合前端开发时填充假数据。GitHub API查询仓库信息、用户信息无需密钥也有免费限额适合做开发者工具。二维码生成/短链接服务很多平台提供免费接口适合做分享功能。每日一句/诗词接口适合做内容型产品的边角功能。如果你愿意花点时间可以在 GitHub 上逛逛 Public APIs 这类仓库里面按文字、图片、金融、教育等分类整理了上千个免费接口找灵感非常方便。唯一要留意的是这些接口的维护质量和法律条款参差不齐用之前至少看看是否要求署名、是否禁止商用。5. 实操过程与核心环节实现从申请到调用的一条龙记录5.1 完整的调用链路设计很多朋友接口调不通不是因为请求写错而是因为整个调用链路没有设计好。我建议在写代码之前先画一个简单的流程明确每一步做什么。以一个图书管理小工具为例我需要实现用户输入一个 ISBN系统返回书的基本信息并顺便把书名翻译成英文。链路大概是这样用户请求进入后端接口后端先查本地数据库缓存如果之前查过这本书直接返回不调任何远程 API缓存未命中调用 ISBN 查询接口拿书的基本信息判断是否需要翻译书名如果需要再调用翻译接口把结果存入缓存数据库然后返回给前端。这个链路清楚之后每个外部调用都有独立的超时、异常处理。比如翻译接口挂了只影响翻译这个附属功能不应该影响 ISBN 查询主流程。这个思想叫“故障隔离”做多接口项目非常关键。5.2 关键代码与配置参数把多个 API 接入同一个项目最怕的就是密钥散落在代码各处。我习惯用一个统一的配置文件管起来以 Spring Boot 为例app: isbn: url: https://api.example-isbn.com/v1/isbn api-key: your-isbn-key translation: url: https://xxx.com/api/trans/text api-key: your-trans-key qps: 1 llm: api-key: your-llm-key base-url: https://api.xxx.com model: your-model-id然后写一个通用的 HTTP 工具类统一设置连接超时、读取超时、默认请求头public class HttpClientUtil { private static final int CONNECT_TIMEOUT 5000; private static final int READ_TIMEOUT 30000; public static String get(String url, MapString, String headers) { // 用 Java HttpClient 或 OkHttp 实现 } public static String postJson(String url, String json, MapString, String headers) { // 处理 JSON 请求体 } }这样做的好处是以后任何一个接口的请求头规则变了只需要改一个工具类任一接口挂了日志里也容易定位。如果多个 API 的 Key 都不相同也建议按业务前缀分开不要全部塞在同一个配置对象里。5.3 限流与错误处理的防御式写法免费接口几乎没有不限流的调用时不做防御很容易把额度用爆。我自己会写一个小工具对需要稳定性的接口加上指数退避重试import time def call_with_retry(func, retries3, base_backoff1): for i in range(retries): try: return func() except Exception as e: print(f第 {i 1} 次调用失败: {e}) if i retries - 1: time.sleep(base_backoff * (2 ** i)) raise RuntimeError(多次调用仍然失败)注意重试逻辑不能对所有错误一视同仁。如果返回 429 表示限流盲目的快速重试只会加重服务器负担应该休息更久或者直接放弃本次调用改用备用接口或者返回缓存数据。如果返回 4xx 业务错误比如参数错误或 Key 无效重试一万次也没用直接抛出让技术人员处理才是正确的。6. 常用免费 API 的常见问题与排查技巧实录6.1 返回 401 / 403 怎么排查这两个状态码是接口开发里最常碰到的表现形式相似原因却完全不同。401 表示身份认证失败就是服务器不知道你是谁先查 API Key 是否复制完整、是否多了空格、是否被代码里的转义改变。很多人在控制台复制 Key 时容易把末尾换行符也带进去肉眼看不出来但在代码里就是一大坑。403 表示权限不足通常意味着服务器认识你但你不该访问这个资源。常见原因有免费额度已用完、账号未实名认证、请求 IP 不在白名单、接口有地域限制。排查方法很简单先把错误返回的 body 打印出来里面的错误码和信息基本都在比如微信接口会返回errcode和errmsg照着文档查就行。6.2 限流、超时、频率限制的应对限流是免费接口的常态。不同接口触发限流后的表现不一样有的返回 429有的返回 200 但里面带错误码还有的直接断开连接。应对手段不外乎几种加缓存高频查询结果在本地存一份减少重复请求用令牌桶或信号量限制自己发出的请求速率比如每秒最多 1 次给不同接口设不同的超时时间行情类接口要快几秒就超时大模型接口要给足时间准备降级策略比如翻译挂了就展示原文天气挂了就展示缓存数据。还有一个小技巧在日志里记录每次外部调用的耗时和状态码收集一段时间后你就能发现哪些时段限流最严重、哪些接口平均耗时最长再做针对性优化。6.3 接口地址变更与兼容性处理免费接口最大的不稳定因素就是地址变更和参数结构变化。我接过的接口里有把 URL 从v1升到v2的有突然要求加签名的有返回字段改了名字的。应对方法其实不复杂只要遵守几条习惯一是把所有 API URL、Key、模型名统一配置化不要硬编码在业务代码里。这样接口地址一变改一行配置就能恢复。二是解析响应时不要直接访问深层 JSON 字段先用一个统一的响应包装类接收原始数据再做字段映射。这样即使上游返回结构略有调整影响也能控制在一个类里。三是新建项目时给每个外部接口做一个简单 Mock 本地跑通。实测一段时间把返回样例存下来后面接口变了你还有基线数据可以对照。写在最后写到这里常用免费 API 的选型、申请、调用和排坑基本都过了一遍。我个人在实际操作中的体会是免费接口不是用来长期扛业务的而是用来快速验证和学习。用的时候一定要想好异常处理和降级方案不然接口一挂你的功能也跟着挂。最后再分享一个小技巧每接入一个免费 API记得把申请时间、密钥、限额、接口文档链接记录到一个表格里免得三个月后再看完全想不起这个接口是干嘛用的。收藏不叫备用测过才算备用。