1. 这份清单是怎么来的，以及我为什么要维护它

做后端开发这些年，我养成了一个习惯：把用过的、验证过的免费 API 接口单独存一份笔记，标注好申请入口、鉴权方式、QPS 上限和踩过的坑。起因很简单——不少项目刚开始做原型验证的时候，根本没必要花钱买付费接口，先用免费额度把业务逻辑跑通，等确认方向可行了再评估要不要升级。但如果临时去搜索引擎里翻，找到的往往是过期信息、失效链接，或者早就改了收费策略的老接口，浪费时间不说，还容易在代码里埋雷。

这份清单是我结合自己最近几个实际项目的使用情况整理出来的，同时参考了社区里口碑比较稳定的接口服务。里面每一项都是我在 2025 年期间真实调用过、确认还能正常返回数据的，没有那种只在文档里看过的“听说可用”的接口。适用对象很明确：独立开发者、小团队、学生项目，以及任何想快速验证产品想法的人。如果你做的是对稳定性要求极高、日均请求量很大的生产系统，那部分接口我建议直接走付费通道，清单末尾我也会专门聊这个边界问题。

先交代一下我的筛选标准，这样你在参考的时候心里有数，后面每一项的选择逻辑也都是基于这几个维度：

这个标准不算苛刻，但已经能过滤掉市面上大部分挂着“免费”名头但实际处处设限的接口了。接下来我会按实际业务场景来分类介绍：先讲最常用的基础服务类接口，再讲能显著提升开发效率的数据处理类接口，然后是一些垂直场景的小众接口，最后集中回答接入过程中最容易踩的坑。

2. 基础服务类接口：做任何项目都可能用得上的那一批

这类接口的特点是通用性强，几乎任何类型的应用都可能在某个环节用到。我把它们放在最前面，是因为这部分踩坑经验最值得参考，毕竟用得人多，遇到问题的概率也大。

2.1 地理编码与逆地理编码：别忽视行政区域边界变化的坑

地理位置服务几乎是我做过的每个带地图功能项目的标配。免费方案里，我目前主力用的是某地图开放平台的 Web 服务 API。它的日配额对普通项目完全够用，个人开发者认证之后可以拿到更高的日调用量，这对原型项目来说非常宽裕。

地理编码（把“北京市海淀区中关村大街”转成经纬度）和逆地理编码（把经纬度转成详细地址）是两类最基础的能力。我实际接过的项目里，除了常规的地址定位，还有一类需求容易忽略——行政区域边界变化。比如某些新区、开发区，老地图数据里可能没有对应的行政区划编码，如果你直接用旧的编码做数据关联，就会出现明明地址是对的、但区域统计永远为空的情况。解决方案是在初始化阶段就保留一份最新的行政区划数据，并定时比对接口返回的 adcode 字段，而不是依赖写死的编码字典。

调用逻辑并不复杂，核心点在于：先做经纬度缓存，再做接口请求。同一个地址短时间内被反复请求是常见场景，如果你不做一层缓存，免费配额会消耗得很快。我踩过一次很典型的坑：某个页面每刷新一次就调一次逆地理编码接口，测试时没感觉，等联调阶段用户量一上来，日配额直接打满，接口开始返回错误码。后来加了 15 分钟的本地缓存，配额压力立刻降下来了，这个方案后续所有涉及定位的项目我都在沿用。

2.2 天气数据：免费 API 里少见的“良心配置”

天气类接口是另一个高频刚需。我自己在做的几个小工具里，有两个都依赖实时天气数据，所以这个领域我对比过不少服务商。目前最常用的是一个聚合类数据平台，它把多家气象源的数据做了整合，用一个接口返回统一格式的天气信息。免费版的日调用量对个人项目和中小型应用来说相当充足，而且数据覆盖的城市范围很广，连一些县级城市都有。

聚合平台最大的价值不在于数据本身多精准，而在于你不用同时维护多套接口协议。你想一下，如果选了三个不同来源的天气接口，每家字段命名都不一样，对接逻辑写三遍、排查问题查三遍，这个维护成本早就超过直接买付费接口的价格了。这也是我后面再选 API 时的一个重要准则：能用聚合接口就别用分散接口，除非你确实对某个数据源有特殊要求。

接入时有个细节值得注意：天气接口返回的数据里，除了当前天气，通常还包含未来几天的预报信息。很多开发者习惯只用当前温度和天气状况，把预报字段忽略了。但免费接口的每日配额是按次计算的，一次调用如果能同时拿到当天和未来三天的数据，实际利用率就翻了四倍。我习惯把调用结果整体存入缓存，预报部分单独更新，这样在保持数据新鲜度的同时，能更从容地控制配额消耗。

2.3 DNS 解析与网络检测：不显眼但关键时刻救命

这一项相对小众，但对于做网络工具类应用、或者需要监控自己服务可用性的开发者来说非常实用。现在有不少平台提供免费的真实 DNS 解析查询接口，以及基于全球节点的心跳检测服务。免费额度通常是每月一定次数的探测，我实测下来对个人站长的日常监控足够用了。

我对这类接口的建议是：把它当成基础设施，不要频繁调用。DNS 记录本身有 TTL 缓存机制，你每次查询都实时请求远端接口是没必要的。正确做法是写一个定时任务，根据记录的 TTL 间隔去同步，本地再维护一份解析结果的快照。我自己的一个域名健康检查脚本就是这么干的，五分钟同步一次，跑了小半年，免费配额还剩一大半。这类接口选型的核心是响应速度，优先选那些提供多地域探测节点的服务商，这样能更真实地反映你的服务在不同地区的可达性。

3. 开发者效率类接口：图片处理、身份证识别、数据解析这些能省大量人力的事

第二类接口的价值在于把原本需要自己写算法、调参、优化的工作交给专业服务，开发周期直接从周降到天。这一类接口我按实际项目的使用频率排了序。

3.1 图片压缩与格式转换：控制台操作几分钟，省下整个周末

如果你做过带有用户上传功能的 Web 应用，一定遇过这种情况：用户传上来一张 5MB 的照片，页面加载要半天，服务器带宽被吃满，数据库存储成本也蹭蹭涨。我之前做某图像处理 Demo 时，前期让用户直接传原图，结果测试当天就发现图片接口的响应时间暴涨，查了半天才发现是宽 4000 像素的大图在拖后腿。

当时对比了三四个方案的接入成本和压缩效果，最终留下的是一个提供智能压缩能力的接口。它的免费版对个人开发者很友好，支持 PNG、JPG、WebP 等主流格式互转，还能按比例缩放。关键亮点是它的压缩算法对图片质量的保留比一般在线工具好不少，肉眼几乎看不出差别，但文件体积能降到原来的五分之一以下。

使用逻辑很直接：上传原图时把文件流转发给图片处理接口，拿到返回的压缩图 URL 再入库。另外它的异步处理模式值得注意，大图压缩可能需要几秒到十几秒不等。我强烈建议你在架构上把压缩做成异步任务：用户上传后先给一个“处理中”的状态，轮询或回调通知前端最终结果。如果同步调用，一旦图片特别大，接口响应就会超时，前端体验非常糟糕。同样一个接口，同步对接和异步对接，用户的感受天差地别。

3.2 身份证与营业执照识别：免费额度和隐私边界要心里有数

这个场景是很多实名制项目绕不开的环节。市面上提供 OCR 识别的平台不少，大都提供每月 50 到 100 次的免费额度。对验证类项目是够用的，但如果你做的是电商、社区这类高频实名场景，免费额度撑不了几天。

以身份证识别为例，接口核心能力是：上传身份证正反面图片，返回姓名、身份证号、地址、签发机关等信息。它靠的是训练好的深度学习模型，识别准确率在清晰照片上能到 98% 以上。但这里必须强调一个容易被忽略的问题：免费版接口的识别结果字段往往是不完整的。比如某些平台免费版不返回身份证头像裁剪图，或者证件照片的“有效期”字段需要单独购买权限。接入之前一定要把文档的“免费字段”部分逐字读一遍，等代码写完了才发现缺字段，返工成本很高。

另外还有一个比技术更重要的点：证件图片属于高度敏感的数据。用第三方接口时，你等于把用户的隐私信息委托给了外部服务。我在项目里会加一层数据脱敏策略：识别完成后，原始图片立即从本地服务器删除，只在数据库保留最终的文字信息；同时在前端页面展示时，证件号码也要做掩码处理。识别接口的调用日志不要记录完整的图片数据。这类项目做多了你就会明白，合规不是嘴上说说，是要写进代码流程里的。

3.3 通用文字识别与表格还原：PDF 转文字的正确姿势

通用 OCR 的实用场景就更多了，比如识别发票、截图、文档扫描件。有一类接口专做“图片扫描件转可搜索文字”，对 PDF 文件的支持特别好——直接传 PDF 链接，返回每页的文字内容识别结果。免费版额度通常按页数计算，每月几百到一千页不等。

我在一个内部工具里用它来处理用户上传的纸质合同扫描件，识别出来之后全文检索，找关键条款的效率提升非常明显。接入时有一点必须注意：这类接口对印刷体的识别效果通常很好，但对手写体的识别率就明显下降。你如果业务场景里手写内容占比高，要么接受部分人工复核，要么就要考虑额外训练模型了。免费方案没有自定义模型的空间，这是收费版的核心差异之一。

我建议所有 OCR 类的调用都做结果缓存。同一张图片第一次识别成功后就存进数据库，后续再上传相同的文件直接返回历史结果，连接口都不用调。这个逻辑对收费接口能省钱，对免费接口能续命。

4. 垂直场景与创意类接口：小成本做出差异化功能的来源

这一部分是容易让人惊喜的区域。很多看起来“花哨”的功能，其实背后都有免费接口在支撑。在原型阶段用这些接口给产品增加亮点，是一个非常划算的手段。

4.1 人工智能对话接口：免费额度是“用一次少一次”的珍惜资源

要说目前关注度最高的接口，非 AI 对话类莫属。多家平台都开放了免费试用额度，有的按 token 计算，有的按请求次数计算。个人开发者申请的话，一般能拿到几十万 token 的初始额度，看起来很多，但如果接入的是长上下文对话场景，消耗速度快得惊人。

我做调研时算过一笔账：一次包含 2000 字带上下文的对话请求，大约消耗 3000 到 4000 token。如果一天跑 100 次交互，每天就是 35 万左右的 token 消耗。几分钟就能把免费额度聊完。所以我在接入时通常会做几层限制：单用户每日请求次数上限、每次请求的最大 token 数、以及全局的预算告警。这些都是纯前端的阈值判断就能做掉的，不需要后端额外开任务。

这类接口我现在的用法是：当作功能验证的“试用装”，帮助确定产品方向，而不把它作为生产环境的主依赖。哪天免费额度用完，产品的付费转化逻辑还验证不出来，说明 AI 功能本身就不是核心抓手，这是帮我做决策的信号，而不是坏消息。

4.2 随机图片与表情包生成：给交互界面增加一点温度

这个类别听着“轻量”，但实际在产品里还挺能出效果的。我之前做的一个演示站点，想给空状态页面配点趣味插画，搜了一圈发现不少免费的随机图片接口，能按关键词返回对应分类的图片 URL。这些接口免费额度给的很大方，有的完全不限量（只对图片质量和链接带宽做了限制）。

表情包生成接口也是类似逻辑：传入一张底图和文字，返回合成好的表情包图片。这种能力用在社区类产品的评论回复功能里会让互动的趣味性提升不少。接入这类接口，我建议把它作为纯前端资源来用，走 CDN 加载图片 URL，不经过自己的后端转发，这样能减少服务器带宽的压力。

4.3 二维码生成与解析：小工具的大用途

二维码相关的接口属于那种“平时想不到，想到了离不了”的类型。生成二维码的接口一般免费额度都很充足，传一个文本或 URL，返回二维码图片。解析接口则支持从图片里反向提取内容。

这里分享一个小经验：如果只是静态生成二维码，完全不用调用远程接口，本地就能用现成的开源库解决，性能更好也不受配额限制。真正需要用到解析接口的场景是：用户上传一张二维码截图，你需要在服务端读取其中的信息，比如从二维码里提取登录凭证、识别活动编码。这种场景自己实现解码相对复杂，交给免费接口是合理的做法。选型时可以优先考虑支持批量解析的接口，有些一次能传多张图片，效率提升明显。

5. 免费 API 的隐藏成本：配额之外的坑，我都替你踩过

这一章是全文里我最想让你仔细看的部分。免费 API 表面上省钱，实际使用中的“隐藏成本”往往不在账单里，而在架构设计和运维细节里。我按踩坑的频率从高到低列一遍。

5.1 CORS 限制：本地开发好好的，部署到线上就“跨域”了

这是免费接口最容易让人抓狂的问题。你在本地调试时，浏览器直接发请求，接口返回正常；等部署到线上域名，控制台突然报跨域错误——大概率是接口方的 CORS 白名单配置问题。

免费接口对来源域名的限制通常比较严格，有的只允许本地开发环境（localhost）访问，有的需要在控制台里手动添加你的线上域名。处理方式无非两种：一是到控制台正确配置白名单；二是让后端服务器转发请求。我个人推荐后者，还有一个额外的好处是可以把 API 密钥藏在后端，不暴露在浏览器端。这算是一个通用的接口调用安全准则。

5.2 密钥管理：把密钥写进前端代码等于把钥匙放在门口

这个问题我见过太多次了。很多开发者为了图省事，把接口密钥直接写在 JavaScript 文件里或者 Git 仓库里，一旦代码公开（比如开源项目、演示站点），密钥就等于泄露了。别人拿着你的密钥调用接口，消耗的是你的免费配额，如果接口支持付费升级，甚至可能产生费用。

正确的做法有几个层次：最低要求是把密钥放在后端环境变量里，前端只通过自己的接口去请求；进阶做法是定期更换密钥，至少每月一次；更稳妥的是一套「主密钥 + 子应用」的隔离机制，不同的项目用不同的子密钥，方便追踪用量和单独封禁异常密钥。这个习惯越早建立越好，等出了问题再改流程，牵涉面就大了。

5.3 配额耗尽时没有预警：不是所有接口都会在返回体里明确提示

大部分接口在配额耗尽时会返回一个明确的错误码，但有些接口表现得更“温和”——它依然返回 200 状态码和正常数据结构，只是在某个字段里暗示额度不足，或者干脆返回降级之后的数据质量。这种情况最阴险：你的代码不会报错，用户也看不出异常，但实际拿到的数据已经不对了。

应对方案是在代码里加监控：对关键接口的返回数据做校验，一旦发现有异常特征就触发告警。比如天气接口返回的数据明显不符合季节规律，OCR 接口识别结果字数异常偏少，这些都有可能意味着接口降级了。我在有一次排查用户反馈数据不准的问题时，查了两天才发现是免费配额在月初就用完了，而代码完全没感知到这个状态。从那以后，凡是接入第三方接口，我都会先写一个响应校验函数。

5.4 接口版本升级：免费接口的说断就断

第三方接口升级这事儿，付费用户还可能收到提前通知，免费用户往往是在某一天发现接口突然返回 404 或者字段名变了。尤其是大型平台调整整体战略时，免费接口可能是最先被下线的。

应对方法有三条：第一，在所有第三方接口前面加一层适配层，代码里只调用自己的封装函数，不要直接散落调用第三方库；第二，定期（我建议每月一次）手动调用一次核心接口，确认返回结构没变；第三，在项目文档里专门记录“所依赖的第三方接口清单”和“它们的版本号”，一旦出错能快速定位到是哪一层的问题。这套防御性编程的思路在依赖免费 API 时尤其重要，因为你永远拿不到服务商的可用性承诺。

6. 有没有必要升级付费，以及在什么时间点升级

说实话，玩了几年免费 API 之后，我的心态变化挺大的。不是所有项目都需要升级付费方案，但如果出现下面这些信号，说明免费方案的瓶颈真的到了：

• 免费配额在业务正常运转的情况下频繁耗尽，比如每个月 20 号之前就没了。
• 接口响应速度对业务体验有明显影响，而付费版提供独享实例或更高的优先级。
• 你需要更完整的字段，免费版刚好缺了最关键的那几个。
• 业务开始涉及敏感数据，你希望获得更明确的数据处理协议和更高等级的合规支持。
• 免费接口的稳定性已经影响了线上系统的可用性，而你连客服都联系不上。

判断是否升级，我建议用这个公式：升级成本 <（节省的服务器资源 + 减少的人工排查时间 + 降低的业务风险）时才值得买。有些场景免费的其实是够用的，比如个人工具类产品、低配版内容管理系统、演示项目，花钱反而不划算。我之前就犯过过度采购的毛病，给一个每天只有几十次请求的内部工具配了企业版接口，完全是浪费。接口选型不该看“别人都在用”，而该看“我的场景真的需要吗”。

升级之前还有一件事值得做：先把免费版的数据缓存机制做到位、把消耗模型摸透。很多系统的“配额不够”其实是缓存策略不合理导致的重复调用，先把这层优化掉，你可能会发现免费额度比想象中耐用得多。我自己的经验是，做过这层整改之后，好几个项目的付费升级计划都直接被省掉了。

7. 我维护这份清单的日常习惯

文章最后，分享一些让这份清单保持长期有效的方法。免费 API 的变化速度比很多人以为的快得多，一份清单如果没有持续维护，三个月后可能就有一半链接失效，反而误导后人。

我的维护节奏是这样：每个季度末抽一个下午，集中检查一遍清单里的接口。检查方式很简单——写一个十分钟能跑完的脚本，对每个接口发一个最低成本的测试请求，确认返回结果符合预期、字段位置没变、错误码语义没变。一有异常就顺手更新备注，能找替代方案的提前找好，保证清单里不出现“临时不可用”的接口。

发现新接口的渠道我一般是这几条线：开发者社区的新帖和技术周刊，关注各大平台度文档的动态公告页面，还有像 GitHub 上有人专门维护的 API 资源集合。这些信息源不是每次都去翻，但会保持至少每周扫一眼的频率。某个新接口如果连续被多个渠道提及，我就会申请账号实际测一下，顺手把它记入候选清单。通过了上面的筛选标准才录入正式清单，测试不过的直接剔除在备注里写上原因。

这应该是我过去很长时间里一直坚持维护的少数资料之一。它帮我解决过不少燃眉之急，也为好几个项目的选型省下了宝贵的调研时间。借助这份实践经验，我希望你也能搭起一套属于自己的接口资源库——它不仅仅是链接清单，更重要的是，其中沉淀下来的判断标准和避坑经验，每一次翻阅都会带来新的价值。