Open-Meteo 一句话：一个不填 API key 就能用的开源天气 API——你给经纬度，它直接返回现在/预报/历史的温度、降水、风、空气质量等结构化数据，JSON 格式、支持 CORS、无广告无追踪。它背后是把 NOAA、DWD、ECMWF、Met 挪威、日本 JMA 这几个国家/全球气象模型的数据收拢、再按位置选合适的模型拼出来的。它既有个免费公共 API 直接调（api.open-meteo.com），也开放源码让你 用 Docker 或 Ubuntu 包自己部署一套——这正是本条 brief 的重点。

一、它到底是啥：开源天气 API + 可自托管的服务

实查坐标：open-meteo/open-meteo，★6291 / AGPL-3.0 / Swift / ~14.7MB / 2026-10-05（我写这篇前一天）还在推 / 144 open issues / desc「Free Weather Forecast API for non-commercial use」。它把 7 套主流模型收进一个入口：NOAA GFS+HRRR、DWD ICON、MeteoFrance Arome/Arpege、ECMWF IFS、日本 JMA、加拿大 GEM HRDPS、MET Norway。API 免 key、支持 CORS、无广告无追踪无 cookie，非商用免费。仓库里既有 API 服务器源码，也提供 Docker 和 Ubuntu 22.04 预编译包让你自己起一套——自托管时能远程访问 Open-Meteo 公共数据库、只缓存要用的数据到本地，不必把整个气象模型都下下来。

二、免 key 实跑：两条 API 真命中（本机证据）

我本机直接 curl 它两条公共 API（免 key），都真拿到了淮安（33.5, 119.03）的结构化数据——这是它「拿来即用」最硬的证明：

# 免 key 实跑（2026-10-06，本机 curl 直接命中公共 API）
# 1) 预报 API（淮安 33.5, 119.03）
curl "https://api.open-meteo.com/v1/forecast?latitude=33.5&longitude=119.03 \
  &current=temperature_2m,apparent_temperature,relative_humidity_2m,wind_speed_10m,weather_code \
  &daily=temperature_2m_max,temperature_2m_min,precipitation_sum&timezone=Asia/Shanghai&forecast_days=3"
# -> HTTP 200, 2.6s, 935B  实况: 13.7°C / 体感 11.4°C / 湿度 60% / 风 8.5km/h
#    3 日最高: 23.8 / 25.0 / 23.3 °C, 降水 0.00mm

# 2) 历史 archive API（同坐标, 9/30-10/2）
curl "https://archive-api.open-meteo.com/v1/archive?latitude=33.5&longitude=119.03 \
  &start_date=2026-09-30&end_date=2026-10-02&daily=temperature_2m_mean,precipitation_sum"
# -> HTTP 200, 472B  3 日均温: 21.5 / 18.8 / 19.2 °C, 降水: 1.40 / 3.90 / 0.00 mm

两个实跑细节值得记：① 返回自带 _units 块（每个变量对应单位），前端/后端不用再猜温度是 °C 还是 °F；② 预报走 api.open-meteo.com、历史走 archive-api.open-meteo.com，两个端点分开，archive 能做数据校验/回测，forecast 做实时展示。

三、机制：多模型选路 + 数据 CC BY、源码 AGPL（双轨授权）

它不是自己跑数值模式，而是「收拢各家现成模型输出，按你查的位置选最合适的模型」——全球大范围用 GFS/ECMWF，欧洲精细用 DWD ICON/MET Norway，亚洲用 JMA，北美高分辨率叠 HRRR。这套「多模型融合选路」是它比单一国家气象 API 强的地方。授权要拎清是双轨的：

  • 数据：CC BY 4.0——可自由传播、改编，但要署名、标明改动，不能暗示官方背书你。
  • 源码：AGPLv3（强 copyleft）——你改了服务再对外提供，得把改动以同协议开源。这条对要商用/闭源集成的团队是实打实的约束。

官方口径：非商用免费、商用要联系他们（走商业授权）。所以「直接搬去做商业天气 App 内嵌数据」这条路要单独谈。

四、自托管怎么落（brief 的重点）

README 明写两条路：Docker 或 Ubuntu 22.04 预编译包。关键是自托管不是要你重跑一遍气象模型——它设计成远程读 Open-Meteo 的公共库、只把请求到的数据缓存到本地，所以起步很轻，适合「想掌控数据流/加自己的处理/离线缓存」的场景。真要吃完整模型才需要更重的部署，那不是「自起一套 API」的默认要求。

五、横向对比 + 坑与边界

  • vs 单家天气 API（OpenWeather / WeatherAPI / 各家气象）：Open-Meteo 免 key、跨 7 模型、数据 CC BY 可商用授权，是「多模型自由拼」的开源路线；单家 API 更省心但通常要 key、要订阅。
  • 坑①：AGPL 是强 copyleft——别把它源码改完直接闭源卖，得开回去；要商用请走商业授权。
  • 坑②：非商用免费 ≠ 商用免费——README 明写商用要联系；把它内嵌进收费产品前先确认授权。
  • 坑③：免 key 但「fair use」——官方说不限制但要求合理使用，高并发刷公共端点会吃公共带宽，大规模/生产建议自托管。
  • 坑④：历史 archive 有更新延迟——历史数据不是实时的，回测/校验用它，别拿它当「当前值」。

六、我的判断

Open-Meteo 的定位很清楚：给「想让代码里能拿到靠谱天气数据、又不想被 key/订阅卡住」的人一条开源自由路。对非商用的开发者、开源项目、个人小工具，它近乎零门槛（免 key、CC BY、多模型）。两条得拎清：① 授权双轨且是 AGPL 强 copyleft，商用/闭源集成要先谈商业授权；② 自托管是「缓存公共库」不是「重跑模型」，比想象中轻。我本机免 key 直接 curl 出淮安实况+3 日预报+3 日历史，这条「拿来即用」是真的。真要做生产，要么走商业授权、要么自起一套把数据流攥在自己手里。