public-apis：社区维护的免费 API 总目录——40+ 分类 …

一、public-apis 是什么：一份被收藏 47 万次的「API 黄页」

在动手写代码之前，绝大多数人都会先问一句：「这个需求有没有现成的免费接口？」public-apis 就是为这个问题而生的。它不自建任何 API，而是把散落在网上的公开接口汇成一张可检索的清单，被社区称为「开发者必备书签」毫不为过。仓库描述原文极简：A collective list of free APIs，即「一份免费的 API 合集」。它不炫技、不封装 SDK，只做一件事——让你少走弯路。

（一）它的来历与定位

仓库创建于 2016-03-20（meta.json 的 created_at），主分支为 master，迄今仍在更新（updated_at 为 2026-09）。它采用 MIT 协议，语言标记为 Python——这主要因为仓库里附带了 CI 与校验脚本，而非清单本身是代码。定位上，README 把自己形容为「a treasure trove of APIs well-managed by the community over the years」，强调「由社区多年精心维护的 API 宝库」。这种「人工策展」而非爬虫抓取的特性，正是它可信度的来源。

（二）不止是清单：APILayer 的商业化身影

打开仓库首页，最先看到的其实是 APILayer 的推广：它把自家的 IPstack、Marketstack、Weatherstack、Fixer 等十几款产品做成一张表格，每行都带「Run In Postman」按钮。README 还嵌入了 APILayer 的横幅与 logo 图。这说明这份「免费清单」背后有商业 API 平台的赞助——它既是社区资源，也是 APILayer 的获客入口。理解这一点很重要：免费条目是真的免费，但首页的「黄金位」是有商业考量的。

二、目录怎么组织：分类 + 四列元信息

public-apis 的结构非常克制，没有花哨的数据库或搜索后端，就是一个带锚点的 Markdown 长文。

（一）Index 与 40+ 分类

文首的 Index 把全部 API 归到 Animals、Anime、Anti-Malware、Art & Design、Authentication、Blockchain、Books、Business、Calendar、Cryptocurrency、Currency Exchange、Development、Games & Comics、Geocoding、Machine Learning、Music、News、Open Data、Security、Sports & Fitness、Weather 等 40 多个分类（材料在约 600 行处被截断，但分类目录本身完整可见）。每个分类下是一张表，点分类名即可跳转到对应小节，小节末尾再放一个「⬆ Back to Index」回到顶部。这种纯静态、零依赖的组织方式，让它十年间都能在任意环境里读、能直接 git clone 离线看。

（二）每一行的四列：API / 描述 / Auth / HTTPS / CORS

每个分类的表头都是固定的五列：API | Description | Auth | HTTPS | CORS。其中三列是选型关键：

• Auth：标明鉴权方式，常见取值为 No（免密钥）、apiKey（需要申请 key）、OAuth（走授权流）；
• HTTPS：是否支持加密传输，Yes 或 No；
• CORS：能否被浏览器前端直接调用，取值 Yes / No / Unknown。

这三列加起来，几乎替你完成了「这个接口我能不能直接用」的初步判断。比如想在前端直接 fetch 一个公开数据，你就该优先筛 CORS 为 Yes 且 Auth 为 No 的条目。

三、从材料里挑几个真实条目

材料虽被截断，但已包含的几十个分类足够说明问题。随手举几个例子，全部出自 README 原文。

（一）免费免密钥的「真·开放」API

• Cat Facts（catfact.ninja）：随机猫知识，Auth=No、HTTPS=Yes、CORS=Yes；
• Dogs（dog.ceo）：基于 Stanford Dogs Dataset，Auth=No、HTTPS=Yes、CORS=Yes；
• HTTP Cat / HTTP Dog：每种 HTTP 状态码配一张猫 / 狗图，均免密钥、支持 CORS；
• Open Library：书籍与封面数据，Auth=No、HTTPS=Yes、CORS=No（注意不能直接前端跨域调）。

这些条目之所以好用，正因它们把 Auth 标成 No、把 CORS 标成 Yes，开发者拿去就能嵌进原型，不用注册、不用后端代理。

（二）需要 apiKey / OAuth 的

• GitHub：仓库、代码、用户信息，Auth=OAuth、CORS=Yes；
• VirusTotal：文件 / URL 分析，Auth=apiKey、CORS=Unknown；
• IPstack / Fixer / Weatherstack：属于 APILayer 系，多为 apiKey，需注册后领取。

这类条目功能更强，但要先走申请流程，README 也会在链接里带上 APILayer 的 utm 追踪参数——再次印证「免费清单」与商业平台之间的共生关系。

四、怎么用这份清单：从挑选到落地

（一）按场景挑 API

别从首页往下 blindly 翻。正确姿势是先用 Index 锁定分类（比如做天气就直奔 Weather，做汇率就找 Currency Exchange），再看表里 CORS 与 Auth 两列，圈出「能直接调」的几个，最后点链接进官方文档比对自己的字段需求。清单只负责「找到候选」，真正的契约仍以各 API 官网为准。

（二）注意 CORS 与 Auth

两条实战经验：第一，前端项目务必确认 CORS=Yes，否则浏览器会拦截；若只有 No 或 Unknown，就只能在自己的后端做代理转发。第二，凡标 apiKey 的接口，密钥要放服务端、别进前端代码，更别提交到公开仓库。public-apis 把这两列摆得清清楚楚，本身就是一种安全提醒。

五、它为什么能火十年

（一）社区策展的信任

和自动抓取的站点不同，public-apis 的增长靠的是「人肉维护 + 社区 PR」。任何人发现失效链接或好用的新接口，都能提 Pull Request。这种机制让清单的准确率长期高于纯爬虫榜单。十年里它积累了约 47.8 万 stars（meta 的 stargazers_count 为 477805），说明「被信任的聚合」本身就是稀缺资产。

（二）与 Awesome 清单的差异

GitHub 上以 awesome-xxx 命名的清单多如牛毛，但 public-apis 的独到之处在「结构化」：别人往往只给一串链接，它额外给了 Auth / HTTPS / CORS 三列判断维度，让你在目录页就能做初步筛选。这一层信息密度，是它从众多清单里胜出的关键。

六、局限与注意事项

（一）链接会失效

免费 API 的生命周期普遍不长，今天标着 No Auth 的接口，明天可能就要求注册或关服。public-apis 虽有人维护，但条目体量太大，难免有滞后。把它当「起点目录」而非「实时可用性保证」，落地前务必点进官网复核。

（二）CORS 的 Unknown 陷阱

很多条目的 CORS 标成 Unknown，意思是「维护者没验证过」。这类接口在浏览器里能不能直接调，靠猜是危险的——要么自己实测，要么统一走后端代理。另外，标 apiKey 的商业接口常有调用配额与费用，README 里的推广位尤其要读懂条款再接入。

七、如果你要建自己的清单

public-apis 的成功给了一个朴素启示：把「别人踩过的坑」结构化沉淀，比写一个新工具更有长期价值。若你想为团队建一份内网版 API 黄页，直接 fork 它的 Markdown 结构即可——分类表头、Auth/HTTPS/CORS 三列、Index 锚点这套范式，几乎可以原样复用，再补上你们内部接口的保密分级。轻量、可 git 跟踪、离线可读，正是它十年的长青密码。

八、总结

public-apis 不是什么技术黑魔法，它只是一份被认真维护了十年的「免费 API 目录」。但正是这种克制——纯 Markdown、人工策展、Auth/HTTPS/CORS 三列标注——让它成为无数开发者找接口时的第一站。把它当作一张地图而非终点：用 Index 锁定方向，用三列元信息初筛，最后去官网确认契约。理解它背后的社区逻辑与商业赞助，你就能既借力这份清单，又不掉进「链接失效 / CORS 未知 / 配额收费」的坑里。

在撰写本文的过程中，我主要参考了以下来源：GitHub 仓库 public-apis/public-apis 的 README（含 Index、分类表与 APILayer 推广内容，材料在约 600 行处截断），以及仓库 meta.json（stars / license / language / created_at / updated_at）。文中数据以仓库公开信息为准，可能随版本更新而变化。