做技术这些年我收藏夹里吃灰最多的就是各种“API 合集”链接真要找某个免费接口时照样翻半天。但有一个开源项目我从收藏改成 Star 之后就再也没取关过——GitHub 上的 public-apis474k Star长期霸占热门仓库前排。如果你正在为“想要一个免费 API 但不知道去哪找”而发愁这份清单基本能解决掉 90% 的需求。这个项目本质上就是一个超大号的免费 API 索引从动物、天气、股票行情到机器学习、新闻、游戏几十个类别排得明明白白。更重要的是它不只是列个名字每个 API 都标注了是否需要鉴权、是否支持 HTTPS、是否支持跨域调用选型时能省掉大量试错时间。无论你是要练手做毕设、搭个人项目、参加黑客松还是给公司产品找数据源都适合先从这份清单里翻一翻。今天就把我对这个项目的完整使用经验整理出来从项目结构、挑选思路到真实接入案例一次性讲透。1. 这个项目到底是个什么来头1.1 从 474k Star 说起它为什么能长期霸榜public-apis 不是代码框架也不是工具库它只有一个 README 文件里面按类别堆满了免费公开 API 的链接和说明。这个仓库的 Star 数超过 47 万意味着你认识的开发者里大概率有人 Star 过它。为什么一个“列表页”能火成这样核心原因有两个。第一它精准击中了开发者最普遍的需求——找数据源。无论你做什么项目基本都逃不开“需要数据”这一步而公开 API 是最快拿到真实数据的途径。第二它的参与门槛极低任何人发现一个好用的免费 API都可以提交 PR 补充进去项目因此保持着非常高的活跃度。我查过它的提交记录维护者几乎每天都会合并新条目这种持续更新的状态让它的参考价值一直在线。当然也要说句实话Star 高不等于每个条目都靠谱。这个项目胜在覆盖面广、筛选成本低但具体到某个 API 是否还能用、免费额度还剩多少需要你按自己需求二次验证。把它理解成一个“候选池”而不是“保证书”使用心态就对了。1.2 目录结构一份清单能拆成几十个细分方向打开 README你首先看到的就是一个按字母排序的目录导航。这个设计非常朴素但极其好用。我数了数现在大概有 50 多个类别覆盖了日常开发能想到的大部分场景。挑几个有代表性的类别感受一下Animals猫狗、鸟类、宠物相关的图片和资料接口Anime动漫信息、角色、语录查询Cryptocurrency加密货币实时行情、历史数据Currency Exchange各国货币汇率换算Finance股票、基金、债券等金融数据Food Drink食谱、酒水、营养成分查询Games Comics游戏资料、漫画信息Geocoding地址解析、经纬度转换Machine Learning模型推理、文本分析、AI 能力接口News全球新闻聚合、RSS 解析Weather实时天气、天气预报、空气质量Test Data假数据生成、mock 接口每个类别下又会列出好几条到几十条不等的 API。每条记录包含四列核心信息API 名称、简单描述、是否需要 Auth鉴权、是否支持 HTTPS 和 CORS。这种标准化字段让你不用点进每个链接光扫一眼表格就能排除掉一大批不合适的选项。2. 拿到清单后怎么挑出真正能用的 API2.1 先看三个字段Auth、HTTPS、CORS很多人打开这份清单第一反应是“这么多我该从哪看起”。我的经验是先盯住每条记录后面的三个字段Auth、HTTPS、CORS。Auth 字段决定你接入的复杂度。它是分级的No Auth 代表完全不需要密钥拿来就能请求apiKey 表示需要先注册获取 API Key在请求时带上OAuth 则要走完整的授权流程适合需要操作用户数据的场景。如果你只是想快速验证一个想法优先选 No Auth 的接口可以省掉注册和配置的功夫。HTTPS 字段不用多说现代项目基本都要求加密传输这个字段为 No 的接口浏览器里也会被拦直接跳过就行。CORS 字段是我特别留意的。它代表这个接口允不允许浏览器跨域调用。如果你是小程序或者纯前端项目CORS 为 Yes 的接口可以前端直连开发效率高很多CORS 为 No 的接口就必须走后端代理转发否则浏览器控制台会给你刷一屏跨域报错。2.2 高频实用的几个类别和代表 API清单里类别虽多但实际开发中真正高频使用的我体感就这么几类天气类我首推 Open-Meteo。它无需 API Key支持全球范围实时天气和 7 天预报每分钟免费请求次数 600 次个人项目完全够用。接入一个天气接口只需要拼一个 URL返回 JSON 里直接拿温度、风速、降水概率非常丝滑。金融股票类Finnhub 和 Alpha Vantage 是清单里比较能打的。Finnhub 免费版每天 60 次请求支持全球股票实时报价、公司基本面、新闻舆情注册后拿一个 API Key 就能用。Alpha Vantage 免费版每分钟 5 次请求、每天 500 次做个人量化分析或者学习项目足够。这类接口天生适合做“股票数据接口 api 免费”的场景不需要自己在各大交易网站上爬数据。机器学习和 AI 类清单里收录了不少大厂和社区的免费推理接口比如 Hugging Face Inference API注册后可以调用大量开源模型做文本分类、图像识别、翻译等任务。如果你在寻找“免费大模型 api”相关的现成实现这类入口比你自己部署模型要快得多。需要注意这类接口通常有严格的频率限制不适合生产环境高并发。测试数据类JSONPlaceholder 是经典中的经典。它提供一整套模拟的用户、帖子、评论、相册数据Rest API 风格和真实接口完全一致前端练手、做原型演示时它就是我默认的数据源。新闻类Hacker News 官方 API 和 NewsAPI 都在这份清单里。前者无需鉴权边做边学效率高后者免费版有每日 100 次请求的额度适合做新闻聚合小程序。2.3 如何快速判断一个 API 值不值得接入字段看完了还要做一步判断这个 API 到底稳不稳、能不用在项目里。我的判断方法很简单三步走。第一步点进链接看文档。如果一个 API 的官方文档有清晰的接入示例、错误码说明和频率限制说明说明这个项目正经在维护如果文档只有一句简单介绍没有示例数据格式全靠猜那大概率是个人临时作品不建议投入精力。第二步看清单里标注的更新时间再去对应官网或者 GitHub 仓库看最近一次 commit。一年以上没更新的服务再免费也尽量不要选——你永远不知道服务器哪天就悄悄关掉了。第三步也是最重要的别光看文档直接拿 curl 请求一下真实接口看返回结果是否和文档一致。这一步能过滤掉 80% 的“文档写得很美实际请求全是坑”的接口。3. 实操演示把清单里的 API 真正跑起来3.1 零成本热身一个不需要 API Key 的天气接口理论说再多不如上手过一遍。我先用一个完全不需要 Key 的接口演示整个流程Open-Meteo。打开它的文档页可以看到请求 URL 是https://api.open-meteo.com/v1/forecast?latitude39.9042longitude116.4074current_weathertrue这个接口通过 latitude 和 longitude 参数指定经纬度current_weathertrue 表示只返回当前天气。我在终端里直接 curl 一下curl https://api.open-meteo.com/v1/forecast?latitude39.9042longitude116.4074current_weathertrue返回的 JSON 长这样{ latitude: 39.88, longitude: 116.41, generationtime_ms: 0.3810615539550781, utc_offset_seconds: 0, timezone: GMT, timezone_abbreviation: GMT, elevation: 144.0, current_weather: { temperature: 12.6, windspeed: 11.2, winddirection: 229.0, weathercode: 2, is_day: 0, time: 2025-06-10T08:00 } }拿到这个 JSON我自己动手写个 Python 脚本把温度、风速、天气编码解析出来import requests def get_current_weather(lat: float, lon: float): url https://api.open-meteo.com/v1/forecast params { latitude: lat, longitude: lon, current_weather: true, } resp requests.get(url, paramsparams, timeout10) resp.raise_for_status() data resp.json() current data[current_weather] return { temperature_celsius: current[temperature], windspeed_kmh: current[windspeed], weathercode: current[weathercode], } print(get_current_weather(39.9042, 116.4074))整个接入过程不到 5 分钟没有注册、没有密钥直接返回可用数据。这就是我推荐从 No Auth 接口入手的原因——你可以先把整套请求、解析、容错的代码框架跑通再换更复杂的带 Key 接口心理负担小很多。3.2 带上 Key 的完整链路以股票行情接口为例接下来演示一个带 API Key 的完整链路选 Finnhub 的股票实时报价接口。先去 finnhub.io 注册账号免费版就能拿到一个 API Key。拿到 Key 之后我第一件事不是写代码而是先把 Key 放到环境变量里避免硬编码进脚本。Linux/macOS 下这样设置export FINNHUB_API_KEY你的keyWindows 的 PowerShell 用$env:FINNHUB_API_KEY你的key然后在 Python 里通过 os.environ 读取import os import requests API_KEY os.environ[FINNHUB_API_KEY] url https://finnhub.io/api/v1/quote params { symbol: AAPL, token: API_KEY, } resp requests.get(url, paramsparams, timeout10) print(resp.status_code) print(resp.json())请求成功的话会返回类似这样的数据{ c: 207.35, h: 211.5, l: 206.33, o: 210.77, pc: 210.56, t: 1718000000 }这里的 c 是当前价格h 是当日最高l 是当日最低o 是开盘价pc 是前收盘价。把这几个字段接进自己的看板页面一个实时股票监控小组件就完成了。接入过程中有两点提醒。第一请求参数里的 token 就是你的 API Key务必通过环境变量注入不要写死在代码里更不要提交到 GitHub 仓库。第二加上超时参数 timeout我习惯设 10 秒。免费接口偶尔会出现响应慢如果没有超时控制程序可能卡死在那里体验很差。3.3 把 API 接进自己项目的两个建议跑通一个接口只是第一步真正把 API 稳定地接入项目我建议做到两点。第一对返回数据做校验。免费 API 的返回结构不会像付费产品那么稳定偶尔会多字段、少字段或者类型不一致。在解析层做好防御比如用 dict.get() 代替直接下标访问给字段加默认值防止一个接口异常把整个应用带崩。第二加好重试和降级逻辑。免费接口出现 5xx 或 429请求过多是常态重试一两次是合理的。如果重试后还是失败最好返回缓存数据或者一处降级说明而不是让用户看到整页报错。我在个人项目里通常用 tenacity 库做重试设置最大重试次数 3 次退避策略用指数退避。4. 免费 API 的坑我替你们踩过一遍4.1 最典型的五种翻车现场用这份清单里的免費 API 用了两年多我自己遇到过不少翻车时刻总结成五类最典型的问题问题类型表现原因应对建议接口下线请求返回 404 或 DNS 解析失败服务方停止运营选有稳定背书的 API避免个人服务器接口限流 429频率稍高就被拒绝免费额度极低读文档了解频率限制加请求间隔和重试数据滞后行情、新闻延迟严重免费版数据源更新慢根据业务场景判断是否需要付费数据跨域被拦浏览器控制台 CORS 报错接口未开放跨域后端代理转发或选 CORS 为 Yes 的接口文档过期照着文档调用却报参数错误接口升级后文档没更新先用 curl 实测以实际返回为准这里重点说一下 429。很多免费的 API 不会明确告诉你限额是多少你只有把请求发出去、收到 429 才知道踩线了。应对思路是读响应头里的 Retry-After 字段它通常会告诉你需要等多少秒才能继续请求。再不行就在代码里做全局的请求节流确保同一时刻只有一个请求在发出。4.2 项目不维护了怎么办这是免费 API 最大的隐患清单还挂着它但背后的服务可能早就不维护了。判断一个 API 还在不在维护我有两个土办法。第一个是看清单里它的链接和描述有没有被近期更新过。public-apis 维护者比较勤快发现失效的条目一般会标注或移除。第二个是去项目官网看新闻、博客、更新日志如果一个 API 近一年没有任何产品更新基本可以判定已经进入“僵尸状态”。一旦确认一个 API 已经不可用或者频繁出错我建议立即启动替代方案。我的常用做法是承认“没有永远免费的 API”这个现实在项目设计阶段就抽象出一层数据源接口把具体的 API 实现隔离在独立模块里。这样换数据源时只需要改一个工厂函数业务代码完全不用动。如果只是做 demo 或者教学项目还有一条更轻的路用 JSONPlaceholder 这类专门提供 mock 数据的接口或者干脆本地起一个 json-server把 API 返回的样例数据保存成 json 文件模拟返回。做法虽然“土”但胜在完全可控永不出故障。4.3 版权、付费边界和发布注意免费的 API 不代表可以毫无限制地商用这个边界值得花一分钟弄清楚。我在接入任何免费 API 之前都会顺手看一眼它的 Terms of Service。有些 API 虽然免费但明确禁止商业用途有些则要求你在产品中标注数据来源还有一部分 API 的免费版数据可能来自第三方再分发有限制。特别是在金融、新闻领域数据版权问题尤其容易被忽視。我见过有个人开发者接了一个免费股票接口做成了小程序结果因为数据源不允许二次分发收到侵权投诉后只能下架。另一个边界是付费升级的触发点。大多数免费 API 的额度限制都是“够学习、不够生产”的水平。如果一个 API 在你的项目里变得不可或缺而且请求量已经稳定超过免费额度的 80%这时候不要死撑免费方案该升级付费就升级。省下来的时间成本远比那点订阅费值钱。5. 常见问题速查与独门经验5.1 拿到 API 后常见的报错与处理接入过程中总会有各种报错。我把高频问题整理成一张速查表供大家直接对照状态码错误信息示例含义处理方案401UnauthorizedAPI Key 缺失或错误检查 Key 是否拼写正确是否通过环境变量传入403Forbidden无权限访问该资源确认账号是否完成邮箱验证免费版是否有该接口权限404Not Found接口路径或资源不存在核对请求 URL 是否与文档一致确认资源 ID 是否有效429Too Many Requests请求频率超限按 Retry-After 等待或降低请求频率500Internal Server Error服务端异常稍后重试连续出现则更换备用 APICORSNo Access-Control-Allow-Origin跨域被拦改用后端代理请求或换成支持 CORS 的接口遇到 401、403先检查 API Key 的配置和权限这两个问题 90% 都是配置层面的粗心。遇到 429别急着加并发先看一下文档里的免费版频率限制合理设置请求间隔。5.2 我的几条选择经验文章最后分享几条我用 public-apis 的真实体会供大家参考。第一条永远不要在生产环境对一个免费 API 做单点依赖。无论它现在多稳都要做好随时被断供的准备。我习惯在主数据源之外至少准备一个备用数据源并在代码里实现热切换。第二条对“免费额度”的认知要理性。免费额度不是给你薅羊毛的你的项目一旦跑起来请求量增长是很快的。建议在项目初期就在日志里记录每个 API 的请求量和失败率提前预判额度消耗速度。第三条定期扫描你的 API 清单。我会每隔一段时间用一个脚本批量请求自己项目里依赖的接口检查状态码和响应时长一旦发现异常马上处理。这个方法帮我避免过至少三次线上事故。第四条善用 public-apis 的搜索功能。GitHub 仓库页面右上角的搜索框可以快速过滤类别直接在仓库内搜 “weather”“stock”“news” 等关键词比在 README 里手动滚动高效得多。根据我个人的实际操作经验public-apis 最正确的打开方式不是收藏之后吃灰而是把它当作一个活索引今天要找天气接口翻一下 Weather 分类挑两个顺眼的试一遍明天要做新闻聚合再去 News 分类里逛一圈。配合自己沉淀的选型方法和容错机制这份清单才能从“看起来很厉害”变成“真的很好用”。最后再分享一个小技巧如果你看中了清单里的某个接口但担心它哪天失效可以 fork 一份 public-apis 到自己仓库按自己的使用频率把常用接口整理到一个小清单里做一个私人定制的 API 导航。这样即使上游仓库变动你的清单仍然稳定可复现。