免费天气api接口对比测评

做小工具、看板或者带天气的 Agent，第一反应都是找免费天气接口。真接进去才发现问题不在能不能调通，而在限流多少、超时多久、数据多久更新一次、挂了怎么兜底。这篇不给具体数字，给一套可复用的判断维度和排查顺序，帮你把选型从「看着能用」变成「上线不翻车」。

做小工具、看板或者带天气的 Agent，第一反应都是找免费天气接口。真接进去才发现问题不在能不能调通，而在限流多少、超时多久、数据多久更新一次、挂了怎么兜底。这篇不给具体数字，给一套可复用的判断维度和排查顺序，帮你把选型从「看着能用」变成「上线不翻车」。

下面四步是顺序关系：先定比什么，再拿真实条件自测，然后把工程护栏搭起来，最后填对照表和上线清单。跳步最容易踩的坑是直接拿文档参数做决定，结果上线第一天就被限流打回原形。

先定维度：免费天气接口该拿什么比

别只比「免费」两个字。免费接口的差异集中在六个维度上，每个维度都对应一个你上线后可能踩的坑。先把这六个维度的定义对齐，再去填表，比一上来就注册一堆 Key 有效率得多。

调用额度

按天或按月给的总次数上限，用完是直接拒绝还是降级返回旧数据

限流粒度

按秒、按分钟还是按天限，粒度越细，短时突发越容易被拦

数据更新频率

源站多久刷一次，决定你缓存该设多长，设短了白费额度

覆盖区域

目标城市在不在覆盖内，境外城市和乡镇级地点最容易缺

字段完整度

只要温度，还是要湿度、风、空气质量、预报，字段缺失决定要不要拼第二家

鉴权方式

Key 放查询串、请求头还是签名，关系到 Key 会不会被日志和前端泄露

第二步是分清免费额度的性质。按天给次数、按 QPS 限流、仅限非商用，这三种性质对应的适用场景完全不同。做内部看板通常能接受低频调用，做面向公众的小程序就得先确认商用条款，不适用条件写清楚才不会上线后被要求下线。

• 先写场景下限：只要当前温度，和要未来几天预报、空气质量、历史回查，对接口的要求差一个量级
• 只做单机演示脚本的话，限流和数据延迟基本可以忽略，不必上复杂方案
• 要对外提供服务，把商用条款和署名要求单独列一行确认，别默认免费就是随便用
• 候选接口超过三个时，先按场景下限砍掉一批，再进自测环节，省时间

接入前先自测：把接口拉到真实条件下跑一遍

文档写的限流值只能当参考，真实边界要用连续调用探。做法是短时间密集请求同一个接口，记录从第几次开始返回限流状态码、返回体长什么样、多久后恢复。这一轮跑完，你对这个接口的脾气就有底了。

1. 探限流边界用脚本匀速加压，逐次记录状态码和响应体，找到第一个限流返回的位置，再测恢复时间
2. 测延迟分布空闲时段和高峰时段各跑一轮，看响应时间的波动范围，到 /tools/speed-test 建一条自己的延迟基线做对照
3. 测数据时效同一地点隔一段时间重复取，看数值多久变一次，据此定缓存时长，别比源站刷新还频繁
4. 测异常返回故意传错城市、错参数、错 Key，记录返回结构，决定错误处理分支怎么写、要不要给用户看原始提示

自测阶段最值得花时间的是异常返回。很多接口正常时结构统一，一遇错就返回一段 HTML 或者完全不同的字段名，前端解析直接崩。把这些情况提前摸清，后面写降级逻辑会顺手很多。

工程落地：超时、并发、降级、日志四件事

护栏这四件事是配套的，缺一件都会在出问题时放大影响。超时和并发决定你打请求的方式，降级决定失败后用户看到什么，日志决定事后能不能复盘。顺序建议按超时、并发、降级、日志来搭。

不适用条件也要写清：如果只是本地脚本、调用量很小，超时分档和并发控制可以简化，把精力放在数据口径对不对上更划算。反过来，一旦对外提供服务，降级和日志基本不能省。

• 所有天气调用收敛到一个内部函数，换源只改一处，不翻业务代码
• Key 不放前端和查询串明文，避免日志和浏览器里泄露
• 额度消耗加一条监控，接近上限时提前告警而不是等被拒
• 备用源至少准备一个，并定期验证它自己还活着
• 字段变更时做兼容解析，缺失字段给默认值而不是抛异常

选型对照与上线前检查清单

做完前面三步，最后落到一张自有对照表上。把候选接口按六个维度逐格填，空格比想象中多，填不满的格子就是风险点。这张表不用好看，能看出谁在哪个维度掉链子就行。

数据口径拿不准时，去站内资料库核对同类服务商的官方说明，别只依赖第三方二手描述。涉及价格和额度这类会变的信息，一律以站内页面当时的记录为准，不要凭记忆写进代码注释。