最好的免费天气 api 接口对比

做个小工具、跑个副业项目，想接天气数据，一搜全是「免费」俩字，真接上才发现有的只有当前温度没有逐小时，有的按天卡次数，有的返回字段单位跟文档对不上。这篇不给你排名，给一套能自己跑一遍的判断流程：先看数据覆盖，再看限制口径，最后按超时、并发、降级、日志的顺序接进项目。

做个小工具、跑个副业项目，想接天气数据，一搜全是「免费」俩字，真接上才发现有的只有当前温度没有逐小时，有的按天卡次数，有的返回字段单位跟文档对不上。这篇不给你排名，给一套能自己跑一遍的判断流程：先看数据覆盖，再看限制口径，最后按超时、并发、降级、日志的顺序接进项目。

选型的核心不是「哪家最好」，而是「哪家在你这个用法下不坑」。同一家接口，你用在后端每天拉几次，和你用在前端让用户每次刷新都请求，结论完全相反。所以下面所有判断标准都要套回你自己的调用形态，形态不同就别照搬。

先看数据覆盖，别只看「有天气」

很多对比文章只列「有没有天气接口」，这没意义。你要按自己产品实际要展示的东西去拆字段，拆成一张能力清单，然后挨家问有没有。缺一项，除非你能接受不显示，否则直接划掉，别用「大概够用」糊过去。

• 当前实况：温度、体感、湿度、风速风向、气压、能见度，逐项确认而不是笼统「有实况」
• 逐小时预报：能取多少小时、间隔是多久、是否含降水概率
• 逐日预报：能取几天、白天夜间是否分开
• 历史数据：有没有、能回溯多久、是不是免费额度内
• 空气质量与预警：AQI、主要污染物、天气预警接口是否单独提供
• 地理覆盖：全球站点还是仅国内城市，支持经纬度还是只认城市编码，中文城市名能不能直接传

单位和时间口径要当场确认，这是最容易返工的地方：温度是摄氏还是华氏、风速是米每秒还是公里每小时、时间是本地时区还是 UTC、预报里的「今天」按哪个时区切。文档没写清楚就发一次测试请求，把原始返回贴出来看，别猜。

再抠限制口径：次数、频率、缓存三件事分开问

同样叫「免费」，限制方式分三种：按天总量、按分钟频率、按并发数。这三种对代码结构的要求完全不同。按天总量的可以白天随便打，但要留余量；按分钟频率的必须做节流和缓存；按并发的则要控制同时在飞的请求数。先搞清楚你面对的是哪一种，再决定怎么写。

• 问商用限制：免费额度能不能用于有收入的产品，要不要署名
• 问 Key 的位置：能不能放前端，放前端等于公开，只能走自己后端转发
• 问超限后果：是直接拒绝、降级返回旧数据，还是静默给空结果，这决定你日志要监控什么
• 问额度恢复节奏：是自然日重置还是滚动窗口，影响你批量任务安排在哪时段跑
• 问有没有备用域名或备用 Key 机制，主 Key 被打满时有没有退路

限制相关的具体数字，各家都在变，别抄别人文章里的。去站内 官方 API 价格 与 大模型平台目录 这类资料库核对当时的说明，再结合自己产品实测一遍请求量。写死的数字会过期，判断口径不会。

接入顺序：超时、缓存、并发、降级

顺序别乱。先定超时，再加缓存，然后控并发，最后才做降级。顺序反了会出现「降级逻辑写了一堆，结果主链路本身超时设置不合理」这种白干活的情况。

1. 第一步：定超时连接超时和读取超时分档设置，天气类接口通常不适合拖太久。具体基线去站内 接口测速 量一次，取实测耗时再加一点余量当作上限。
2. 第二步：加缓存按城市加时间粒度做本地缓存，预报类数据没必要每次请求都穿透到远端。缓存能顺带把频率限制摊平，也让你在对方抖动时仍有东西可返回。
3. 第三步：控并发与重试批量拉多城市时用有限并发排队，失败重试要加退避，别一失败就立刻重发把额度瞬间打满。
4. 第四步：做降级主接口挂了或超额，切备用源或返回上一次缓存值，接口层对外永远给一个可用结果，调用方不用处理「今天没有天气」这种状态。

日志与监控：让「数据不对」能复盘

天气接口最烦的问题不是报错，是「没报错但数据不对」——温度单位错了、时区错了一天、某城市返回空。这类问题靠错误码看不出来，只能靠日志结构设计提前埋好抓取点。

• 每次请求记：目标城市、请求时间、耗时、状态码、走了主源还是降级源
• 把「返回成功但关键字段为空」单独计数，比只看错误码更容易发现数据覆盖的坑
• 定期跑一次固定城市的抽查，跟另一家源交叉比对，偏差扩大就说明该换源或改口径
• 额度用量单独留一列，盯住消耗节奏，避免月中就被打满
• 把单位转换和时区转换写成可测函数，出问题时能单独验证这一层

这套日志不需要多复杂，一张表加几个计数器就够起步。关键是它能让你在用户投诉「天气不对」时，五分钟内定位是数据源问题还是你自己的转换问题。