1586 个免费 API 的清单，README 顶上压着 42 条广告

大家好，我是若风。

你大概见过这个仓库，public-apis/public-apis，44.9 万 Star，几乎每个搜「free API」的人都会被推荐到它。我也收藏了很多年。

直到最近我把它整个 clone 下来想挑几个 API 用，才发现事情不太对。README 一打开 221KB，2080 行，我数了一下，里面塞了 42 处 utm_source=Github 的跟踪参数，54 处提到同一个名字，APILayer。

一个号称「社区维护的免费 API 清单」，第一屏不是 API 分类索引，而是一家公司的一整条产品线广告。

我花了一个下午把这个仓库翻了个底朝天，想搞清楚它到底还值不值得用。

它本质就是一个 Markdown 文件

先说清楚这个东西到底是什么。public-apis 没有核心代码，没有框架，没有 src 目录。整个仓库的实质内容就是一个 README.md，外加 scripts/ 目录下两个 Python 校验脚本。

这个 README 用一张张表格，把全网的免费 API 按分类列了出来，每个 API 标了认证方式、是否 HTTPS、是否支持 CORS。一共 52 个分类，从 Animals 到 Weather，我数了下实际条目大概 1586 条。

你想想看，一个纯文本清单能做到 44.9 万 Star，靠的不是技术多酷，是「方便」。任何一个开发者，不管是写脚本、做 demo、还是给 Agent 找数据源，总会有那么一刻想「这个事儿有没有现成 API 能调」。public-apis 就是那个你不用翻搜索引擎、打开就能查的索引。

它的价值一直在这里，这一点我不想否认。

但它早就不是社区清单了

问题出在它被「接管」之后。

README 的开头现在是这样，第一段标题是「APILayer Unified Suite is now Live」，然后是一整屏 APILayer 套件的介绍，IPstack、Marketstack、Weatherstack、Aviationstack，九个产品一字排开。紧接着是一张「APILayer APIs」的表格，把这些商业产品又列了一遍，每条都带着 Postman 一键运行按钮。

再往下才轮到那个传说中的 API 索引。

这不是社区顺手推荐的，这是有意的置顶。我在 README 里 grep 了一遍，utm_campaign=Public-apis-repo 这个跟踪参数出现了 42 次，几乎每一处指向 APILayer 产品的链接都在追踪「这个流量是从 GitHub 仓库来的」。

APILayer 是一家卖 API 的商业公司，IPstack 查 IP 归属、Marketstack 查股价、Weatherstack 查天气，这些产品都有免费层，但更核心的是付费层。把它们的入口塞到 44.9 万 Star 的仓库最顶部，等于白嫖了一个顶级广告位。

说真的，这招很聪明。但也确实把「社区清单」这个词搞变味了。

社区用脚投了票

社区不是没反应。

GitHub 上有一个置顶 issue，编号 #3104，标题就叫「Public APIs Situation」，95 条评论，是整个仓库讨论最热的 issue。里面社区成员在讨论这个仓库到底还算不算社区资产。

更直接的是 issue #3484，标题就一句话，「USE THIS REPO INSTEAD」，指向了一个 fork，public-apis-dev/public-apis。这个 fork 现在有 9218 Star，口号很直白，「A collaborative list of public APIs for developers」，没有任何商业产品置顶。

当一个清单项目的社区宁可自己 fork 一份也要把广告去掉，你就知道原本那份已经被推到了什么程度。

那些 README 不会告诉你的事

下面这些是我自己翻仓库翻出来的，README 里一个字都没提。

超过一半的 API，CORS 状态根本没人验证过。 public-apis 的表格有一列是 CORS，标 Yes/No/Unknown。我把 1586 条 API 过了一遍，914 条标的是 Unknown。也就是说 57.7% 的 API，你根本不知道能不能直接从浏览器前端调，大概率得自己起个后端转发。很多人冲着「免费 API 直接前端 fetch」来的，结果踩一鼻子灰。

「Public API」这个说法本身就靠不住。 仓库里那个 scripts/validate/links.py 脚本干的是链接存活检测，我读了它的源码，里面有个 fake_user_agent() 函数，专门伪造四个浏览器 User-Agent 去请求 API 文档页，因为「some hosting services block not-whitelisted UA」。还有一个 has_cloudflare_protection() 函数，专门处理 403 和 503，因为太多「public API」其实套了 Cloudflare 的反爬。

你想想这意味着什么。连校验脚本都得靠伪装才能访问这些 API 的文档，你作为开发者真正去调的时候，能有多「public」？

这个仓库十年没发过一个 release。 我查了 releases，空的。它就是一坨不断被 PR 修改的 Markdown，没有版本，没有里程碑，没有维护承诺。今天某条 API 还在，明天可能就被作者关了，清单里那条记录就成了死链，只能等每日跑一次的 CI 把它标出来。

到底怎么用才不亏

坦白讲，尽管上面吐槽了一堆，我还是要说，这个仓库依然值得收藏。关键是怎么用。

第一，把它当索引，不当推荐。 清单上的 API 不等于好用，它只代表「曾经有人提交过」。挑到候选 API 之后，自己去看文档、看更新频率、看有没有限额。别信 CORS 那一列，Unknown 就当 No 处理，先测再说。

第二，别被 README 顶部的 APILayer 产品带节奏。 那些产品确实是这个仓库里维护得最勤的条目，因为它们就是仓库运营方自己的。但它们不一定是你要找的最优解。查天气的 Open-Meteo、查汇率的 Frankfurter，都是完全免费、无 key、社区口碑更好的选择，它们就安安静静躺在分类列表里，没有 Postman 按钮，也没有 utm 参数。

第三，如果要长期依赖，优先看有没有自托管选项。 清单里不少 API 是个人项目，作者一关服务就没了。真正要在生产环境用，找那些开源、能自部署的，或者有大厂背书的官方接口。

第四，如果你介意那 42 条广告，直接用 public-apis-dev 那个 fork。 内容基本一致，没有商业置顶，更新也还算活跃。

一个值得记住的模式

我写这篇不是要劝退谁，是想提炼一个我自己用了很多年才看明白的判断。

可以叫它 List-as-Leadgen，清单即引流。

当一份社区维护的免费资源（清单、聚合页、awesome-list）积累到足够大的流量，它就会成为商业实体眼里的优质广告位。收购、接管、赞助、置顶，套路都是一样的，用社区攒下的信任，给自己的付费产品导流。public-apis 不是第一个，free-for-dev、awesome 系列的很多仓库都走过这条路，也不会是最后一个。

这个模式本身不违法，APILayer 也确实养着这个仓库的维护。但它把一个判断摆到了我们面前，一份资源到底是「社区资产」还是「商业入口」，不能看它 README 怎么写，得看它的链接指向谁、谁在更新、流量往哪导。

下次你看到一个超高质量的免费清单，先用这个眼光扫一遍，顶部和首屏那些最显眼的条目，到底是社区投票选出来的，还是有人花钱买的位置。

这个判断，比清单本身值钱。