最好的 6 个免费天气 api 接口对比测评

做侧边栏天气、物流路线提醒或者 IoT 面板时，你打开搜索翻到一堆「免费天气接口」，标题都差不多，真接进去才发现有的 Key 要等审核、有的字段今天叫这个名明天又变、有的免费档一到高峰就开始超时。这篇不讲概念，只给一套横向比法：先看哪几项指标，再按什么顺序试；哪些情况下免费档根本不该用在生产，也一并说清。

做侧边栏天气、物流路线提醒或者 IoT 面板时，你搜「免费天气接口」会翻到一堆标题差不多的页面，真接进去才发现：有的 Key 要等审核，有的字段今天叫这个名明天又变，有的免费档一到高峰就开始超时。这篇不讲概念，只给一套横向比法——先看哪几项，再按什么顺序试，最后哪些场景下免费档根本不该上生产。

下面按节拆开讲，每节都落到能当天下班前跑完的动作。想先摸清各家公开口径，可以边看边开着站内的官方 API 资料库对照，避免拿别人的旧截图当准数。

挑之前先定 5 个判断维度

别一上来就比谁返回好看。先把这五项过一遍，能砍掉大半候选：鉴权、额度口径、字段与单位、粒度与更新频率、地域覆盖与坐标系。任何一项和你的业务对不上，接口再顺手也别继续试。

额度这块最容易踩坑，因为「免费」两个字背后口径差很多。具体到某家当时给多少、怎么算，别抄二手文章，直接到 /official-api 核对当时的公开说明。

半天把候选接口全跑一遍的清单

筛选完就动手，别只看文档。目标是半天内把所有候选各跑一遍，留下的不是最漂亮的，是最不容易让你半夜起床的。顺序按下面来，每一步都要留记录。

1. 跑最小请求只请求一个城市、只要当前温度，确认 Key、URL 拼法和返回结构三件事都对，跑通再往下。
2. 放大参数换成英文城市名、传空参数、传不存在的城市名，看它返回空数组还是直接报错，这决定你代码里怎么写判空。
3. 量响应时间用 /tools/speed-test 从你自己的服务器量一遍延迟基线，跨机房的真实值往往比文档写的慢。
4. 压一下并发脚本并发几十次，观察是否出现限流、是否开始返回旧数据，免费档的真实上限通常在这一步暴露。
5. 记录失败样本把每次非 200 的返回体和时间点存下来，后面写重试和降级全靠这份记录，不靠回忆。

这一步常见的误判是：本地 curl 很快，就以为生产也快。真正要看的，是从你部署机房出发、并发状态下的表现，那才是用户会遇到的数字。

免费档怎么用才不容易翻车

免费档不是不能用，是不能裸用。核心就四件事：缓存、主备、失败分级、别放强实时链路。天气数据天然可缓存，这是免费档最该利用的一点。

• 缓存放第一位：按业务容忍度设一段缓存窗口，命中就不再打接口，能挡掉大部分额度压力
• 主备双源：同时接两家，主源超时或报错就切备源，切换逻辑写在服务端，别把 Key 暴露在浏览器里
• 失败分级：超时、限流、参数错、数据缺失四种情况分开处理，前两种重试，后两种直接回退缓存值或占位文案
• 别放强实时链路：航班调度、冷链报警这类业务，免费档只能做展示层补充，核心链路要走付费或自有数据源
• 给降级留退路：缓存也过期时，展示上一次的合理值加一句说明，比空白区块或报错弹窗体面得多

# 主备切换的伪代码思路，不是可直接跑的成品
resp = try_primary(city)
if resp is timeout or resp is limit:  resp = try_backup(city)
if resp is param_error or resp is empty:  resp = read_cache(city)  # 别重试，直接回退

什么叫「别放强实时链路」，举个通用场景：一家 5 人小团队做一个工地安全提醒面板，天气只作为参考信息展示，免费档加缓存完全够；但如果这个面板要触发停工指令，那天气数据的延迟和缺失就是安全问题了，性质完全不同。

上线前留一份能复盘的记录

免费接口最大的风险不是贵，是悄悄变差而你不知道。所以上线前就把日志和对比机制埋好，别等出问题再补。

• 每次调用记四个字段：接口名、请求时间、耗时、返回状态，出问题时不用靠回忆猜是哪家挂了
• 每周抽一天做对比：把两家同一城市同一时刻的结果拉出来对一遍，差得离谱的那家就该降权
• 给自己定一条撤换线：连续一段时间错误率超过某个比例就换源，比例按你的展示要求定，不照搬别人的数字
• 额度消耗写进监控：接近上限时提前告警，比月初突然全部返回错误好处理得多
• 保留字段变更记录：截图或存返回样例，字段改名时你能第一时间发现，而不是等页面显示错乱

如果你想把选型和成本一起看，可以去 /price-watch 看当时的追踪记录，再回到 /official-api 核对字段与额度口径，两边对上再落进代码。