GitHub 趋势 · 第 73 期
479,056 星的免费 API 清单，校验脚本停在 2022 年 2 月
#GitHub趋势#开放数据#清单运维
先说判断。public-apis/public-apis 是本轮月榜上唯一一个既没写过、又同时踩中「动量最高」和「开源 + 商业推广」两个信号的候选：单月新增 24,522 star，在这份月榜里排第二。而它 README 的第一个一级标题不是介绍自己，是 APILayer 的产品广告。
但它真正的看点不在广告，在运维节奏：一份建仓近十年的公共 API 清单，条目校验脚本和它的工作流，最后一次改动都是 2022-02-07。条目一直在加，校验逻辑四年多没动过。
一、痛点：清单类项目的失败模式，是「过期」不是「写错」
「免费 API 清单」是每个做副业的人都会收藏的东西。你按它找接口，接上去，两周后返回 502，或者突然开始要 key，或者条款从「免费」变成「每月 1000 次」。清单类仓库不会告诉你哪一条失效了，它只会继续涨 star。
更麻烦的是这件事的反馈链是断的：star 数衡量的是「多少人觉得这清单有用」，不是「这清单现在还有用」。当涨 star 的速度远快于更新的速度，star 本身就变成一个误导性信号。这期拆的这个仓库，正好是这个现象最极端的样本。
二、项目是什么
官方描述只有一句：A collective list of free APIs。建仓 2016-03-20，主语言 Python，最新一次 push 是 2026-09-10，未归档，许可 MIT，默认分支 master。
README 里的自述原话是这样的：The Public APIs repository is manually curated by community members like you and folks working at APILayer. It includes an extensive list of public APIs from many domains that you can use for your own products. Consider it a treasure trove of APIs well-managed by the community over the years. 直译过来——由社区成员和 APILayer 的人共同手工维护，是一座被社区良好管理多年的 API 宝库。
一个很容易被忽略的细节：这个仓库的 homepage 字段填的不是文档站、不是 Demo 页，而是一个带 UTM 追踪参数的 APILayer 产品页——https://APILayer.com/?utm_source=Github&utm_medium=Referral&utm_campaign=Public-apis-repo
四个数字先摆出来，全部来自 API 实测：
- ▪star 479,056（月榜页面快照为 479,388）、fork 52,858，但真正点「订阅」的 subscribers 只有 4,741——约 101:1。收藏的人多，跟着它更新的人少。
- ▪open issue 1,941 个。清单类仓库的 issue 区通常是「哪条失效了」的报障队列。
- ▪仓库体积 8,026 KB，约 8MB。它的「产品」几乎全在一个 README 文件里，而这份 README 全文一个代码块都没有——所有条目都是 Markdown 表格行。
- ▪按建仓日 2016-03-20 到 2026-09 算，这份清单已经九年半。
三、结构：一个 README、50 个分类、3 条工作流
顶层只有 2 个目录 + 5 个文件，把「最近改动时间」并排放在一起看，信息量比条目本身更大：
| 路径 | 是什么 | 最近改动 |
|---|---|---|
| README.md | 全部条目都在这个文件里 | 2026-09-10（合并 PR #7302） |
| CONTRIBUTING.md | 条目格式与 PR 规则 | 2024-04-17 |
| LICENSE | MIT 全文 | 2022-01-01（Update year to 2022） |
| scripts/ | 校验包 validate/ + 单测 tests/ | 2022-02-07（Fix false negative http code 404 in verification） |
| .github/workflows/ | 3 条工作流 | —— |
| .github/ | 另含 APILayer logo 图与 issue/PR 模板 | 目录最近改动 2026-07-13（Add APILayer Banner） |
三条工作流分别是 validate_links.yml（604 B）、test_of_validate_package.yml（592 B）、test_of_push_and_pull.yml（1,006 B）。其中 validate_links.yml 这条，最后一次提交是 2022-02-07，提交信息是 Add workflow_dispatch event——给校验加了一个可以手动点的手动触发按钮。之后再没动过。
README 的三个一级标题，按顺序是：
| 一级标题 | 装的是什么 |
|---|---|
| # APILayer Unified Suite in now Live! | APILayer 的推广位 |
| # Try Public APIs for free | 仓库自述 + Discord / Postman 入口 |
| # Index | 50 个分类的目录（Animals、Anime、…、Vehicle、Video） |
Index 之下是 50 个分类小节，每条 API 的格式由 CONTRIBUTING.md 定义，字段固定为六个：
| API | Description | Auth | HTTPS | CORS | Call this API |
|---|---|---|---|---|---|
| 文档链接 | 不超过 100 字符 | 认证方式 | 是否支持 | 跨域情况 | Postman 集合 |
其中 Auth 字段只接受白名单里的值：OAuth、apiKey、X-Mashape-Key、No、User-Agent；CORS 只接受 Yes、No、Unknown。CONTRIBUTING.md 里还有一句提醒：没有配好 CORS 的 API，只能在服务端调用。
四、上手：校验脚本原命令，以及被锁死的依赖
这个仓库的「上手」不是调用它的接口，而是跑它自己的校验包。命令全部逐字取自 scripts/README.md：
$ python -m pip install -r scripts/requirements.txt $ python scripts/validate/format.py README.md $ python scripts/validate/links.py README.md $ python scripts/validate/links.py README.md -odlc $ cd scripts $ python -m unittest discover tests/ --verbose
三条校验的分工是：format.py 查格式，links.py 查链接是否活着，加 -odlc 就只查重复链接（"--only_duplicate_links_checker" 的缩写）。scripts/README.md 原文还提醒了一句：As there are many links to check, this process can take some time.
依赖被锁在下面这几个版本（scripts/requirements.txt 原文，一字未改）：
certifi==2021.10.8 charset-normalizer==2.0.10 idna==3.3 requests==2.27.1 urllib3==1.26.8
要注意：这些命令解释的是「这个仓库自己怎么校验它的清单」，不是「你的项目怎么调用清单里的 API」。后者清单里没有提供任何命令——README 全文一个代码块都没有。
五、我的判断
适合谁：需要一个「按分类找免费数据源」的起点、并且愿意自己再验一遍可用性的人；想照着它的条目格式（API / Description / Auth / HTTPS / CORS 六列）给自己的团队建一份内部清单的人。
不适合谁：把这份清单当成「可直接上线的依赖表」的人；想在生产环境里按它做自动探测、并期望它长期维护的人。清单会告诉你「2016 年有人用过这个接口」，不会告诉你「今天还能用」。
坑有三个：
① 时效性由最后一次校验决定，不由 star 数决定。这个仓库的校验脚本 scripts/validate/links.py 和它的工作流 .github/workflows/validate_links.yml，最后一次改动都停在 2022-02-07。同期 README 一直在合 PR（最近一次 2026-09-10），.github 目录最近一次改动是 2026-07-13、提交信息是 Add APILayer Banner。校验逻辑四年多没动，条目一直在加，两件事是同时发生的。
② 商业面要看清。README 的第一个一级标题就是 APILayer 推广，另有一个 APILayer APIs 表格，链接统一带 utm_campaign=Public-apis-repo 或 -Best-sellers 参数；仓库的 homepage 字段填的也是带 UTM 的 APILayer 页面。维护关系在 README 里写得很清楚——社区成员与 APILayer 的人共同手工维护。这不是偷偷夹带，但「免费清单」不等于「没有商业意图」。
③ 规则和现状之间有张力。CONTRIBUTING.md 开篇写的是：有些 PR 明显是为了推销付费 API，这份清单不是营销工具，这类 PR 不会被接受；PR 规则里还要求「一个 PR 只加一条链接」「描述不超过 100 字符」「按字母序插入」。规则定得很细，但条目基数大，落到具体某一条上，没有任何自动化机制在替你复验。
六、数据来源
仓库：public-apis/public-apis（https://github.com/public-apis/public-apis）
star 479,056 · 月度新增 +24,522 · fork 52,858 · subscribers 4,741 · open issue 1,941
许可 MIT · 主语言 Python · size 8,026 KB · 建仓 2016-03-20 · 最近 push 2026-09-10 · 默认分支 master
README 结构、50 个分类、六列条目格式、Auth / CORS 白名单、依赖版本与校验命令，均逐字取自仓库原文（README.md / CONTRIBUTING.md / scripts/README.md / scripts/requirements.txt）
scripts/ 与 .github/workflows/validate_links.yml 的最近改动时间取自 GitHub Commits API
榜单来源：GitHub Trending 官方页面（月榜）· 抓取时间：2026-09-13 07:55（GMT+8）· 数据为快照
你收藏夹里那份 API 清单，上一次真正跑通其中一条是什么时候？评论区说说你踩过的最坑的一条「免费 API」——下期可以挑一条专门验。
下期预告：三榜若继续只剩写过的项目，就兑现欠着的那期「把模型塞进小设备和边缘」合集；若冒出更高动量的干净新面孔，就继续单项目精读。
#GitHub趋势#下期预告