40 万 Star 的 public-apis，为什么它至今还是找 API 的第一站

很多人以为，找 API 这件事现在早就被搜索引擎、文档站、AI 问答替代了。

但真开始做东西你会发现，最浪费时间的一步，往往不是“不会调”，而是不知道先去哪里找一个像样的 API：免费还是收费、要不要鉴权、能不能前端直连、文档靠不靠谱，光这几件事就能筛掉一大半。

这也是 public-apis 这个老仓库到今天还一直有人收藏的原因。它不是一个新工具，也不是一个 API 平台，更像是开发者世界里那种很朴素、但一直有用的基础设施：一个社区维护的公共 API 索引入口。

项目卡片

一句话说完：一个按主题分类、人工整理、长期维护的免费公共 API 清单。

我本地把仓库同步下来读了一遍，README 里现在大约有 51 个分类、1400+ 条 API 条目。从天气、金融、地图，到开发工具、开放数据、机器学习，基本都能先在这里摸一遍底。

更重要的是，它不是只丢一个链接完事。每条记录至少会告诉你：这个 API 做什么、要不要认证、支不支持 HTTPS、CORS 怎么样。

别小看这几个字段。

你想做浏览器端 demo，先看 CORS；你想临时拼个 side project，先找 No Auth；你想少踩坑，就优先挑 HTTPS 和文档齐的。很多时候，这比“搜到 20 篇 SEO 文章”更快。

因为它解决的不是某一个 API 的调用问题，而是开发者在选 API 之前的那一步信息定位问题。

搜索引擎当然也能找，但结果通常很散：你不知道是不是官方文档，不知道有没有免费层，也很难在同一维度下横向比较。

public-apis 做的事，是先把这些入口按统一格式摆平，再把“第一轮筛选”交给你。

它有点像互联网接口世界的一本黄页，只不过这本黄页不是静态页面，而是社区在不断补、不断纠错、不断清洗的开放索引。

我觉得这才是它能活这么久的关键。

仓库的 CONTRIBUTING.md 写得很细：不是随便来个链接就能加。它明确强调，这里不是营销位，优先收真正能免费使用、或者至少有明确免费层的 API；还要求分类内按字母排序、描述尽量短、一次 PR 只加一个链接。

更像样的是，仓库里还带了专门的校验脚本，会检查条目格式、Index、字母排序、重复链接和链接可用性。

也就是说，public-apis 不是“大家往 README 里堆东西”，而是用一套很轻但很实用的规则，把一个大清单维持成可读、可搜、可继续协作的公共目录。

这就是它跟很多“某某资源大全”最大的区别：它不是只靠热度活着，而是靠维护机制活着。

如果你以前没认真用过这个仓库，我建议直接按这个顺序来：先明确需求，再跳到对应分类，第一轮只看描述、Auth、HTTPS、CORS，筛出 2 到 3 个候选后再进官方文档看请求格式和限额。

这样用，它很像一个“候选池生成器”。

不是帮你做最后决策，但能把前面最烦的搜索时间砍掉很多。

适合：

不太适合：

说白了，public-apis 给你的是入口，不是最终采购建议。

它帮你把“从 0 到找到候选”这件事变简单，但不会替你做最后的技术选型。

如果你平时会做脚本、原型、自动化或者小产品，public-apis 这种仓库真的值得常驻收藏夹。

不是因为它新，而是因为互联网每天都在长出新的接口，开发者就一直需要一个靠谱的入口层。public-apis 恰好把这件事做成了一个足够朴素、但非常耐用的公共目录。

如果这篇对你有用，建议点个关注。我会持续把 GitHub 上值得用的 AI 工具拆成「最短上手闭环 + 坑点清单 + 可复用配置」，让你少走弯路。

想第一时间看到后续的工具拆解与实战更新，欢迎扫码关注公众号。