读万卷书，行万里路。——刘彝

public-apis/public-apis：一座会自己长大的“API 宝藏库”，每天都在等你来挖

我第一次点开 public-apis/public-apis 的 README 时，脑子里出现的画面不是“一个仓库”，而是一座很热闹的港口。

码头边站着一位老练的引路人，手里拿着一本不断增厚的名录，边翻边跟我说：

“想要免费 API？来，我这里有。动物、金融、天气、新闻、机器学习、政府数据……你说得出名字的领域，基本都能在这条街上找到摊位。” (github.com)

它就是 GitHub 上极其知名的仓库：

  • public-apis/public-apis
  • A collective list of free APIs（免费 API 的合集清单） (github.com)

它不跟你讲大道理，它直接把路给你铺到脚下：
一份巨大的索引 + 一个个分类清单 + 每条 API 的关键信息，像城市地图一样清清楚楚。

它是谁：一个“手工策展”的公共 API 清单

如果你把互联网当成一片海，API 就是海里的航线。
而 public-apis 不是某个公司做出来的“产品目录”，它更像一个由社区共同维护的手工策展清单：

“The Public APIs repository is manually curated by community members…”
由像你这样的社区成员（以及 APILayer 的伙伴）共同维护。 (github.com)

它把自己描述成一座“宝藏库”：

“Consider it a treasure trove of APIs well-managed by the community over the years.” (github.com)

这句话很有画面感：
它不是把链接粗暴堆在一起，而是像一个认真做馆藏的管理员——
把“免费 API”按领域收纳、整理、标注，让你可以快速挑到趁手的工具。

它的开场白很直白：Try Public APIs for free

README 的第一句话就像一个招牌，挂在大门口：

Try Public APIs for free (github.com)

这句话有点像一位热心的店老板对你招手：

  • 你是来做产品原型的？进来挑。
  • 你是来做小工具的？进来挑。
  • 你是来练手写爬虫/练接口调用的？进来挑。
  • 你是来做数据可视化/脚本自动化的？进来挑。

它不问你“你是谁”，它只问你“你要什么领域的 API”。

它怎么组织这座城市：Index（索引）就是地图

public-apis 的“城市规划”非常讲究：
先给你一张巨大的索引地图（Index），然后每个区域都有自己的街区清单。

你会在 Index 里看到大量分类（这里只举 README 展示的部分感受一下规模）：

  • Animals、Anime、Anti-Malware、Art & Design
  • Authentication & Authorization
  • Blockchain、Books、Business、Calendar
  • Cloud Storage & File Sharing、Continuous Integration、Cryptocurrency
  • Currency Exchange、Data Validation、Development、Dictionaries
  • Documents & Productivity、Email、Entertainment、Environment、Events
  • Finance、Food & Drink、Games & Comics、Geocoding、Government、Health、Jobs
  • Machine Learning、Music、News、Open Data、Open Source Projects
  • Patent、Personality、Phone、Photography、Programming、Science & Math、Security
  • Shopping、Social、Sports & Fitness、Test Data、Text Analysis、Tracking
  • Transportation、URL Shorteners、Vehicle、Video、Weather
    …… (github.com)

它像在说：
“别急，我知道你要找接口，但先把地图拿好——你要去哪条街，自己选。”

每条 API 都像一个“摊位”，而它把关键信息都写在摊位招牌上

在每个分类下面，它用表格给你列出每个 API 的核心属性：

  • API 名称
  • Description（它能干嘛）
  • Auth（需要什么认证，比如 apiKey / OAuth / No）
  • HTTPS（是否支持 HTTPS）
  • CORS（跨域策略）

以 Animals 分类为例，你能看到类似这样的条目（这里只是 README 中可见的一部分条目，用来感受结构）：

  • AdoptAPet（apiKey）
  • Axolotl（No）
  • Cat Facts（No）
  • Cataas（No）
  • Dogs（No）
  • eBird（apiKey）
  • FishWatch（No）
  • HTTP Cat（No）
  • HTTP Dog（No）
    …… (github.com)

这个设计非常“工程化”：
你不需要先点进去每个官网找“到底要不要 key”，也不需要先猜“能不能跨域”——
它在清单层就帮你做了一次信息预处理。

它像一个很会带新人的同事，一边递给你资源，一边顺手把坑标出来：

  • “这个要 apiKey。”
  • “这个不用认证。”
  • “这个支持 HTTPS。”
  • “这个 CORS 不确定/不支持，你如果前端直连要小心。”

你会在门口遇到 APILayer：一位“合作方导游”

README 里也出现了 APILayer 的介绍和 API 列表：

  • IPstack、Marketstack、Weatherstack、Numverify、Fixer、Aviationstack、Zenserp、Screenshotlayer、Exchangerate Host、Mailboxlayer 等等 (github.com)
  • 同时也写明：APILayer is the fastest way to integrate APIs into any product（用于集成 API 的方式之一） (github.com)

如果你愿意把这段拟人化一下：
public-apis 像一位“社区图书管理员”，而 APILayer 像是图书馆门口的“城市导游”——
他会告诉你：除了这本名录，你也可以用他们的方式更快把 API 接入产品。

这个仓库给你的不只是清单，还有“参与入口”

public-apis 不装高冷，它在 README 里直接给出参与方式：

  • Contributing Guide
  • API for this project
  • Issues / Pull Requests
  • LICENSE
    (github.com)

这意味着：
它不是“你只能看”的列表，它更像一块公共白板——你可以补充、纠错、维护，让这座“API 城市”继续扩建。

怎么把它用起来：把它当成你项目的“API 选型起点”

public-apis 本身不是一个 SDK，也不是一个 CLI 工具；它更像一个“选型入口”。
它最适合出现在你的工作流里这样的位置：

  1. 你准备做一个需求：比如“天气 + 地图 + 新闻”
  2. 你不想一上来就 Google 半天、踩一堆坑
  3. 你先打开 public-apis 的 Index，锁定分类
  4. 在分类表格里快速筛选：认证方式、HTTPS、CORS
  5. 再点进 API 的官网文档，决定用哪一个

如果你想来点“命令行味道”的使用方式（本质是把 README 拉到本地，方便 grep/全文搜索），可以这么做：

1
2
3
4
5
6
7
git clone https://github.com/public-apis/public-apis.git
cd public-apis

# 直接本地全文检索某个关键词，比如 "Weather"、"OAuth"、"CORS"
grep -n "Weather" README.md | head
grep -n "OAuth" README.md | head
grep -n "CORS" README.md | head

它不会替你写业务代码，但会像一位靠谱的搭档帮你节省最贵的东西：找资料与试错的时间。

一句话总结：它像一位不知疲倦的“资源管理员”，把免费 API 排好队递到你手里

public-apis/public-apis 的魅力不在于花哨，而在于“长期主义的整理”。

它每天都在做一件很朴素但很难的事：

  • 把散落在互联网各处的免费 API
  • 用统一结构整理好
  • 让你在需要的时候，像翻一本目录一样找到它们

它不承诺“你用它就能成功”，它只保证：
你想找免费 API 的时候，它会站在那儿，像一位老朋友一样把名单递给你：

“来，挑吧。要哪一类？” (github.com)