GitHub 47万星的 public-apis：免费API清单如何重塑开发者的数据获取方式

1. 项目概述：为什么一份列表能拿下 474k Star

在 GitHub 上摸爬滚打的开发者，应该都见过 public-apis 这个仓库。它不写框架、不封装 SDK、不提供任何一行让你“跑起来”的业务代码，就干一件事：把互联网上可用的免费公共 API 按领域整理成清单。但正是这份“朴素”，让它在 GitHub 上累计拿下了超过 47 万 Star，成为整个平台 Star 数最高的项目之一。

我第一次刷到这个项目时也纳闷，一个 markdown 格式的目录凭什么这么火？后来实际用了几次才明白，它的价值不在于代码，而在于帮所有人省掉了“找接口”这个过程。做个人项目、写练手 demo、搭 side project、给学生做课设，第一步往往不是写代码，而是到处搜有没有合适的免费数据源。public-apis 把这一步彻底变成了“打开仓库、Ctrl+F、复制链接”三连操作。

这个项目适合谁来用？在我看来，覆盖面非常广：刚学前端想找免费天气接口做练习的新手，后端开发需要随机用户数据来模拟测试的工程师，做数据分析想找公开数据源的研究者，甚至产品经理想做竞品调研都会用到它。无论你是哪一类，只要你有“获取外部数据”的需求，public-apis 就是你最该先收藏的仓库。而且它不只是“一份列表”，每条 API 都标注了认证方式、HTTPS 支持情况、CORS 是否可用，等于连选型评估都帮你做完了。

2. 深度拆解：这份清单是怎么组织起来的

2.1 分类体系：从天气到金融，覆盖日常开发全场景

public-apis 对 API 的分类非常细，第一眼看上去会有点眼花缭乱，但实际使用中你会发现这种分类方式极其“开发者友好”。它不是按技术栈分，而是按业务场景分，和你做项目时的思考路径天然对齐。想做和天气相关的应用？直接进 Weather 分类。要调地图数据？Geography 分类里躺着各种选择。这种语义化分类是它区别于普通收藏夹的核心优势。

以我自己的经历来说，有一次我要做一个数据大屏 demo，需要几类随机数据来填充图表：股票行情、体育比赛结果、随机笑话。这三个需求分别在 Finance、Sports、Programming 分类里找到了对应接口，整个过程没有超过五分钟。换作以前，我得先去搜股票 API、再去翻比赛数据源、最后还要找个备用笑话接口，光验证可用性就能耗掉半天。

分类的另一个好处是“行业内横向对比”。比如你想接一个天气预报接口，Weather 分类下可能有十几个备选，每个的权限要求、HTTPS 支持、CORS 配置都列在同一张表里，一眼就能对比出哪个最省事。这种体验是搜索引擎给不了的，搜索引擎给你一堆博客和技术帖子，你还得自己去甄别信息的时效性。

2.2 核心表格：三大筛选指标快速锁定可用接口

public-apis 最有含金量的部分，是每一类下面的表格结构。每一条 API 都对应四列：API 名称与链接、描述、认证方式（Auth）、HTTPS 支持、CORS 支持。这几个字段看起来简单，实际上直接决定了你接入这个接口的开发成本。

先说 Auth 这一列。它有三种常见取值：No、apiKey、OAuth。如果显示 No，说明这个接口完全开放，不需要任何申请步骤，复制链接就能直接请求，最适合做快速验证和个人小项目。apiKey 表示你需要去对应网站注册申请一个密钥，然后在请求时带上参数。这个流程也不复杂，但需要注意有些平台申请 Key 需要审核时间，甚至会限制免费额度和调用频率。最麻烦的是 OAuth，意味着你需要走完整的授权流程，拿 access token，还要处理 token 过期刷新。对于只想快速拿点数据的场景，看到 OAuth 我一般直接跳过。

再说 HTTPS 和 CORS 这两列。HTTPS 为 Yes 代表接口支持加密请求，现在浏览器对混合内容限制很严格，如果你的页面部署在 HTTPS 环境下，调 HTTP 接口会被浏览器直接拦截，所以尽量选 HTTPS 为 Yes 的。CORS 这一列就更关键了，它直接决定你在浏览器端能不能“裸调”这个接口。CORS 为 Yes 意味着服务端允许跨域请求，前端代码里拿 fetch 直接调用就行；为 No 或者 Unknown 的话，你就得想办法绕过，比如自己写个后端代理转发请求，或者在开发环境配置代理。一个常见误区是很多新手不看 CORS 列，写完前端代码发现接口报跨域错误，然后又不知道怎么回事。

2.3 收录原则与质量门槛：为什么它不会变成“垃圾场”

一个开放编辑的列表类项目，最怕的是什么？是内容失控，塞进大量失效链接、低质接口、甚至需要付费才能使用的“伪免费”接口。public-apis 在这一点上做得比较克制。它的维护者明确了收录门槛：必须可公开访问、必须提供真实可用的数据、接口本身要符合免费或开放的要求。当然，随着项目规模越来越大，偶尔也会出现个别链接失效的情况，但整体质量控制在国内外的开源项目里都算相当不错的。

另一个值得注意的细节，是项目对 API 的排序充分考虑了实际开发中的容错需求。例如同一分类下，优先列出免认证的接口，而需要复杂授权的接口会排在后面。这种排列方式看起来微不足道，却能实实在在减少使用者的决策时间，也体现出了维护者对使用者场景的理解。

3. 实操指南：用 public-apis 快速搭建一个可用服务

3.1 三分钟定位免费接口：检索与筛选实操

实际操作时，我们不可能一页一页去翻分类。public-apis 的使用诀窍是“关键词优先”。打开仓库主页后，直接用浏览器的页面查找功能，搜索你脑子里浮现的核心领域词。想找跟猫有关的图片接口？搜 cat。想找数字货币行情？搜 crypto。这个方法比逐级打开分类要快得多，而且能直接命中多个相关分类。

拿到初步结果后，再按三条标准快速过滤：优先选 Auth 为 No 的，优先选 HTTPS 为 Yes 的，优先选 CORS 为 Yes 的。三个条件全部满足的接口，可以直接无脑用在 demo 里；如果找不到全满足的，优先牺牲 CORS 条件，通过后端代理绕过去，这个成本相对可控。

我举一个自己的实操例子。有一次我在做 ChatGPT 套壳应用的辅助功能，想加一个“今日运势”的彩蛋，需要找一个稳定的随机文字接口。在 public-apis 的 Test Data 分类里，我一眼看到了一个叫 Quote 的接口：免认证、支持 HTTPS、CORS 为 Yes，直接复制请求 URL 试了一下，返回的是标准 JSON 格式。从打开仓库到接口跑通，总共不到三分钟，这种效率在以前是不可想象的。

3.2 主力接口的选择思路：为何我偏爱免认证类

用 public-apis 选接口的过程中，我发现了一个经验：做项目初期，尽量优先依赖免认证接口，而不是一上来就花时间去注册各种开放平台的 Key。原因很简单，免费接口的认证流程虽然不复杂，但每个平台的规则都不一样。有的要求你用邮箱注册，有的要求你先实名，有的甚至要绑定手机号。这些额外的摩擦成本对于验证阶段完全没必要。

免认证接口虽然可能在稳定性上不如大厂官方 API，但作为 demo 和原型阶段的数据源绰绰有余。等到项目需要上线、需要保证数据可靠性时，再换成有正式 SLA 的商业 API 也不迟。public-apis 的价值就在这：它同时给了你“快速试跑”和“正式选型”两个阶段的参考选项，你不需要在初期就逼自己做出完美的决定。

3.3 实战演练：用随机用户接口写一个调试工具

我平时做前端调试时经常需要一个“看起来真实”的用户列表来渲染表格或卡片。以前的做法是自己在代码里写死几十条假数据，但数据量一大就很假，而且姓名、邮箱、头像之间的关联感很差。用 public-apis 找到了 Random User Generator 这个接口之后，这个问题彻底解决。

这个接口的调用方式很简单，直接在 URL 上带参数即可：

这个请求会返回 20 条包含姓名、邮箱、电话、头像、地址等字段的完整用户数据，格式为标准 JSON。我在本地用一个静态页面加一个 fetch 请求，就调通了。整个过程不需要安装任何依赖，不需要后端参与，浏览器里直接就能预览效果。而且刷新页面数据会变化，用来测试前端空态、加载态都非常合适。

更贴心的是，public-apis 表格里对这个接口的标注是：Auth 为 No、HTTPS 为 Yes、CORS 为 Yes，属于所有条件都满足的“一键可用”接口。这也是我建议新手从这类接口入手的原因——你不需要提前了解任何前置知识，就能在十分钟内感受到“接入一个真实 API”的成就感，这种正向反馈对学习动力的维持非常重要。

3.4 高阶玩法：把 public-apis 变成离线资料库

public-apis 本身是开源项目，这意味着你可以把它从 GitHub 克隆到本地，变成一份随时可查的离线清单。尤其在网络不好的环境下，或者你在写代码时需要快速回忆某个分类下有哪些接口，本地文档比打开浏览器去刷 GitHub 要快得多。做法很简单：

另外，因为仓库内容是纯 Markdown 格式，你还可以自己写脚本解析表格，把数据导成 JSON 或 CSV，集成进自己的内部工具库。甚至可以做一个小型 CLI 工具，输入关键词直接从本地目录里返回匹配的 API 列表。项目社区里已经有人做了类似的事，比如封装成命令行查询工具，但自己动手做一遍更能加深对项目的理解。

4. 常见问题与避坑技巧实录

4.1 看到 API 却不会用？先检查这三点

不少新手拿着 public-apis 里的链接去请求，发现返回的不是想要的数据，就以为是接口失效了。实际上大部分情况是下面三个原因之一。

第一，没有看描述。表格中 Description 一列对接口功能做了简要说明，但很多接口的实际返回格式、请求方式需要点进官方文档才能确认。public-apis 给的是一个“入口”而不是“说明书”，不要指望列表里所有信息都齐全。第二，没有处理跨域。前面强调过 CORS 这一列的重要性，如果你要在浏览器里直接调接口，遇到跨域问题是非常正常的。第三，忽略了请求频率限制。很多免费且开放的接口虽然没有认证，但在单位时间内有访问次数上限，短时间内高频请求会被临时封禁 IP。

我之前用过一个返回随机猫图片的接口，一开始测试没问题，后来放在循环里自动刷新，几分钟后请求就开始报 429 错误。这就是频率限制。遇到这类情况，最简单的解决方式是在代码里加一个延时，降低请求频率，而不是去研究怎么绕过限制。免费接口的带宽和服务器资源本来就有限，合理使用才能让别人也能稳定访问。

4.2 链接打不开或失效？别急着自己造轮子

public-apis 体量太大了，维护者不可能每天都手动检查每一条链接。所以偶尔遇到失效链接是正常的。我的建议是：失效了就换同分类下的备选，而不是自己花大量时间去研究怎么修复、怎么替代。这个分类下通常还有好几个接口等着你试，重点是你自己要学会如何评估哪个可以用。如果某个分类下所有接口都有问题，那大概率是这块数据本身获取门槛较高，可以换个思路用别的风格接口兼容。

另外有一点需要强调，有些 API 打开后页面显示的是英文文档，导致部分读者觉得用不了。实际上，接口返回的数据结构和文档语言关系不大，多数 JSON 数据都能直接解析。只要你能看懂返回的键名，用到项目里是完全没问题的。

4.3 别被“免费”二字迷惑，看清底层的使用边界

public-apis 里的接口绝大多数是免费可用的，但“免费”不等于“无限制”。很多接口的免费额度只够开发和测试用，如果你做的是一个用户量很大的应用，直接拿这些免费接口当生产数据源，很快就会遇到瓶颈。轻则响应变慢，重则被封禁，还有可能面临潜在的版权风险。

我的经验是：免费 API 只用在 demo、学习和内部工具上；如果要上生产环境，优先去找对应的商业版本或官方付费接口。public-apis 的真正定位是一个“探索入口”，它帮你低成本验证创意、快速搭建原型，但它不能替代你为生产环境应做的选型与稳定性评估。这个边界想清楚了，你用这个项目时就会游刃有余。

4.4 如何持续跟进更新：Star 之外再做两步

GitHub 上点 Star 只能算“标记”，并不能保证你第一时间看到项目更新。public-apis 本身更新频率不算特别快，但每隔一段时间都会有新的 API 加入或旧链接被移除。如果你想保持信息新鲜，可以多做两步。

第一步，关注仓库的 Releases 页面，项目维护者在整理完较大改动后会发布新的版本说明，比直接看 commit 记录更直观。第二步，订阅仓库的 Watch 功能，把通知级别设置为“Custom → Releases”，这样每次有版本发布时你都会收到邮件提醒，不会错过重要更新。

还有一个细节我可以补充，就是留意项目的 Contributors 列表。public-apis 的贡献者人数非常多，分布在全球各地，大家提交的接口五花八门，有些冷门分类的更新速度更快。如果你想针对某个垂直领域挖掘更多接口，可以去看看该分类最近的提交记录，往往能找到表格里排在后面但很新的接口。

5. 写在最后：一个用了三年的“懒惰”经验

从第一次打开 public-apis 到现在，我的使用习惯已经逐渐固定下来：做新项目时先花十分钟刷一遍相关分类，把候选接口的请求方式、返回格式、限制条件记到自己的笔记里；写 demo 阶段直接调用，跑通后再决定要不要换成付费稳定的替代方案。这个过程帮我省掉了大量“找数据”的时间，也让我在几种常见接口的使用上越来越熟练。

最后分享一个小技巧，我不建议你把整个仓库 Fork 到自己账号下面然后就不管了，因为这样并不会自动同步上游更新。更好的做法是，在本地克隆一份，然后定期远程拉取最新代码。如果需要保留自己的笔记，可以在本地维护一个单独的分支，把选型记录、调用示例写在里面，这样既拿到了项目的最新内容，又保留了自己的实操经验库。这个组合拳我用了很久，推荐给所有经常和 API 打交道的朋友。