Open-Meteo 介绍与选型指南

目标：讲清开源天气与气候 API 服务 Open-Meteo 的定位、架构、能力边界，以及「非商用免费公共 API」与「自托管实例」两条使用路径的差异，并给出可复现的最小接入示例与同类方案量化对比。本文已在 Ubuntu 22.04 与 Ubuntu 24.04 服务器上对 Open-Meteo 1.7.0（公开 API 与自托管实例）完成实测，全部命令与回显均取自真实环境。

一、环境信息

本章交代溯源对象与实测环境，保证文中版本号、星数、许可等关键事实可复查。溯源以官方一手来源为准：GitHub 仓库、Releases 页、官网文档；星数通过 shields.io 徽章与仓库页面 HTML 双重取证（未直接调用 GitHub API）。全部溯源查询日期为 2026-10-28。

实测环境（下文所有实测命令均在这两台服务器执行）：

💡 说明：仓库创建时间、许可、星数等会随时间变化，本文仅承诺「截至 2026-10-28」的取值；引用时建议重新取证。

二、软件概述

2.1 项目定位

Open-Meteo 是一个开源天气与气候 API 服务：后端聚合各国国家气象中心发布的数值天气预报数据，转换成自研的高压缩时序文件格式，对外提供免密钥的 HTTP JSON API。非商用用途可直接免费调用官方公共 API（api.open-meteo.com），商用或高频场景可以自托管同一套服务端源码。项目 README 对自身的定义是「Free Weather Forecast API for non-commercial use」，仓库创建于 2021 年 6 月，由德国团队维护，Home Assistant、Breezy Weather 等大量开源应用将其作为默认或可选天气数据源。

按官方仓库与官网（open-meteo.com）口径，截至 2026-10-28 的关键量化事实：

• 官方每日从各国气象服务机构下载并处理超过 5 TB 原始模式数据；
• 聚合 30+ 天气模式：全球模式分辨率最高 11 km，区域模式最细 1.5 km（如 DWD ICON D2），欧洲与北美模式逐小时更新；
• 历史天气 API 覆盖 1940 年至今约 80 年；
• 官方公共 API 响应时间低于 10 ms，欧洲与北美多点部署、GeoDNS 就近解析；
• 免密钥、支持 CORS、无广告无跟踪。

2.2 许可与商业模式

Open-Meteo 的代码与数据采取双许可，这是选型时最容易混淆的一点：

官方公共 API 免费限于非商用，README 的公平使用条款约定日请求超过 1 万次需联系官方；商用可采购官方商业 API（专属端点、API Key、更高可用性目标），或按 AGPL-3.0 自托管并履行开源义务。自托管本身官方明确不限制商用（自托管文档 License 一节原文：「Self-hosting is available for non-commercial and commercial use」）。

在数据展示处署名的官方推荐写法（README 原文）：

<a href="https://open-meteo.com/">Weather data by Open-Meteo.com</a>

2.3 社区活跃度与版本节奏

• GitHub stars 6550、forks 462（shields.io 徽章显示 6.5k，2026-10-28 查询）；
• 版本节奏约为每月一个 minor 版本：1.6.0（2026-09-10）到 1.7.0（2026-10-16）间隔约五周；
• bug 通过 GitHub Issues 跟进，官方推荐一般性问题走 GitHub Discussions，商业支持走邮件。

💡 技术拓展：本文反复出现的「数值天气预报模式（NWP Model）」不止一种类型，选型时需要分清——

类型	原理	分辨率与时效	典型代表
全球模式	覆盖全球的偏微分方程数值求解	9–25 km，7–16 天	NOAA GFS、DWD ICON global、ECMWF IFS
区域模式	嵌套全球模式、只算局部区域	1–7 km，1–3 天	DWD ICON D2/EU、NOAA HRRR、Météo-France Arome
集合预报	同一模式扰动初值跑几十个成员	衡量预报不确定性	ECMWF 集合、GFS 集合
再分析	用现代模式同化历史观测回算过去	逐小时、覆盖数十年	ERA5（1940 至今）

Open-Meteo 的做法是全球+区域模式混合选优：请求坐标时按地点与时效自动在多模式间挑选，也可用 models= 参数显式指定单个模式。本文实测即显式指定了 ecmwf_ifs025 与 icon_global 两个模式。

三、核心架构

3.1 三大组件

官方 getting-started.md 把 Open-Meteo 拆成三个关键组件，实测与源码结构一致：

技术栈以源码 Package.swift（1.7.0 标签）为准：Swift 6.2 工具链（swift-tools-version:6.2）、Vapor 4.89+、SwiftNIO 网络栈、自研 om-file-format C 库、SwiftNetCDF/SwiftEccodes 负责 GRIB 与 NetCDF 解码，可选启用 Apache Arrow Parquet 支持（ENABLE_PARQUET=TRUE）。构建还依赖系统级 C 库 netCDF 与 ecCodes。

3.2 数据流水线

Open-Meteo 不生产预报，它做的是「原始模式数据的工程化重分发」：各国气象中心发布 GRIB/NetCDF 原始文件 → 下载器解码、重网格插值（首次运行会生成坐标与权重文件，如 ICON 的 cdo_weights.nc）→ 写入 om 格式分块文件 → API 按坐标与时间范围从块中读取并二次插值返回 JSON。官方将处理完成的数据库通过 AWS Open Data 赞助计划公开发布（openmeteo.s3.amazonaws.com），因此自托管有一条免下载全量数据的捷径，见 3.3。

3.3 远程缓存运行模式（自托管最轻形态）

自托管实例可以不下载任何模式数据：设置环境变量 REMOTE_DATA_DIRECTORY=https://openmeteo.s3.amazonaws.com/data/ 后，API 收到请求时直接从官方 S3 按需拉取小块数据，落进本地 LRU 缓存文件（cache.bin，大小由 CACHE_SIZE 控制，默认 10 GB）。服务器 A（官方包）实测该模式的成本特征：

官方文档同时说明：这种云原生访问模式每约 2 分钟检查一次 S3 上的模式更新并预热缓存，自托管实例整体慢于官方公共 API 属预期行为（一次预报要读数百个文件的小片段），适合「重复请求多、能吃到缓存」的工作负载，而非单用户低频调用。

3.4 API 端点全景

API 服务支持的路由可用内置 routes 命令直接导出（服务器 A 实测，GET 路由共 22 条）：

/robots.txt  /v1/era5  /v1/archive  /v1/forecast  /v1/dwd-icon  /v1/gfs
/v1/meteofrance  /v1/jma  /v1/metno  /v1/gem  /v1/ecmwf  /v1/cma  /v1/bom
/v1/arpae  /v1/elevation  /v1/air-quality  /v1/seasonal  /v1/flood
/v1/climate  /v1/marine  /v1/ensemble  /metrics

💡 说明：/v1/forecast 是多模式自动选优的统一入口，/v1/dwd-icon、/v1/gfs、/v1/ecmwf 等是单模式专用端点；/metrics 输出 Prometheus 格式指标。除 GET 外，/v1/forecast 等端点同时注册了 POST 路由，可用请求体批量提交大量坐标。

四、功能特性

4.1 API 域一览

结合官网文档与 3.4 的 routes 实测，Open-Meteo 对外提供以下 API 域：

4.2 天气模式覆盖

官网文档侧栏与仓库下载器子命令（实测 openmeteo-api --help）共同印证的模式来源，覆盖 17 个国家/机构：

4.3 API 通用能力

• 免密钥：公共 API 不注册、不签发 Key；自托管实例默认同样无鉴权（可用反向代理或 API_APIKEYS_PATH 控制）。
• 批量点位：一次请求最多 1000 个坐标（源码默认 LOCATIONS_LIMIT=1000，可配置）。
• 单位与时区：温度/风速/降水单位与 IANA 时区均为请求参数，实测见 5.1。
• 响应格式：默认 JSON，另支持 Open-Meteo FlatBuffers 二进制格式（官方 SDK 配套，体积更小解析更快）。
• CORS 全开放：源码 configure.swift 对所有来源开放 GET/POST/OPTIONS，浏览器前端可直连。

4.4 数据署名要求

CC BY 4.0 的署名义务是最容易被忽略的合规点：凡在产品或页面中展示 Open-Meteo 数据，都应附 2.2 中给出的署名链接；再分发数据（如落库存档后对外提供）同样需要注明来源与许可。

五、快速开始（最小可用示例）

5.1 调用公开 API

无需注册即可从任意联网环境调用公共 API。第一条命令查询北京（39.9N, 116.4E）逐小时气温，实测回显（2026-10-28，节选）：

curl "https://api.open-meteo.com/v1/forecast?latitude=39.9&longitude=116.4&hourly=temperature_2m&forecast_days=1"

{"latitude":39.89455,"longitude":116.35983,"generationtime_ms":0.025391578674316406,"utc_offset_seconds":0,"timezone":"GMT","timezone_abbreviation":"GMT","elevation":49.0,"hourly_units":{"time":"iso8601","temperature_2m":"°C"},"hourly":{"time":["2026-10-28T00:00","2026-10-28T01:00","2026-10-28T02:00","2026-10-28T03:00","2026-10-28T04:00","2026-10-28T05:00","2026-10-28T06:00","2026-10-28T07:00","2026-10-28T08:00","2026-10-28T09:00","2026-10-28T10:00","2026-10-28T11:00","2026-10-28T12:00","2026-1

说明：输出节选（实测首部）。返回值结构分三层——请求元信息（latitude/longitude/elevation/timezone）、单位说明（hourly_units）、数据体（hourly.time 与 hourly.temperature_2m 两个等长数组）；坐标被自动对齐到模式格点（39.89455 而非请求的 39.9）。

常用查询参数（公开 API 与自托管实例一致）：

单位与时区参数生效的实测回显（temperature_unit=fahrenheit、timezone=Asia/Shanghai，2026-10-28 节选）：

{"latitude":39.89455,"longitude":116.35983,"generationtime_ms":0.19228458404541016,"utc_offset_seconds":28800,"timezone":"Asia/Shanghai","timezone_abbreviation":"GMT+8","elevation":49.0,"daily_units":{"time":"iso8601","temperature_2m_max":"°F","temperature_2m_min":"°F","weather_code":"wmo code"},"daily":{"time":["2026-10-28","2026-10-29"],"temperature_2m_max":[57.8,61.7],"temperature_2m_min":[36.9,43.3],"weather_code":[3,0]}}

变量名写错时服务返回结构化错误而非 500，实测：

curl "https://api.open-meteo.com/v1/forecast?latitude=39.9&longitude=116.4&hourly=not_a_variable"

{"error":true,"reason":"Invalid value: Cannot initialize SurfacePressureAndHeightVariable<VariableAndPreviousDay, VariableOrSpread<ForecastPressureVariable>, ForecastHeightVariable> from invalid String value not_a_variable"}

5.2 自托管最小运行概览

自托管有两条官方路径：Ubuntu 22.04 直接安装官方 APT 预编译包（含 systemd 服务与同步服务），或其他发行版用 Swift 工具链源码构建；两者都支持 3.3 的远程缓存模式，装好后一条 curl 即可验证。完整分步过程（依赖安装、GPG 密钥、env 配置、systemd 托管与全部实测回显）见本栏《Open-Meteo 1.7.0 安装部署指南》，配置项逐条语义见《Open-Meteo 1.7.0 配置参数详解》，服务管理命令见《Open-Meteo 1.7.0 常用 CLI 命令与工具详解》。其中服务器 A 的安装后首查（远程缓存模式，冷缓存 42.6 秒）回显如下，供预期管理：

{"latitude":47.0,"longitude":8.5,"generationtime_ms":3763.21804523468,"utc_offset_seconds":0,"timezone":"GMT","timezone_abbreviation":"GMT","elevation":789.0,"hourly_units":{"time":"iso8601","temperature_2m":"°C"},"hourly":{"time":["2026-10-28T00:00","2026-10-28T01:00","2026-10-28T02:00","2026-10-28T03:00","2026-10-28T04:00","2026-10-28T05:00","2026-10-28T06:00","2026-10-28T07:00","2026-10-28T08:00","2026-10-28T09:00","2026-10-28T10:00","2026-10-28T11:00","2026-10-28T12:00","2026-10-28T13:00","2026-10-28T14:00","2026-10-28T15:00","2026-10-28T16:00","2026-10-28T17:00","2026-10-28T18:00","2026-10-28T19:00","2026-10-28T20:00","2026-10-28T21:00","2026-10-28T22:00","2026-10-28T23:00"],"temperature_2m":[10.0,10.2,10.5,10.6,10.3,9.7,9.3,9.2,9.3,9.3,9.3,9.2,9.1,9.0,8.8,8.7,8.7,8.7,8.6,8.5,8.4,8.2,7.9,7.6]}}

验证自托管服务是否存活的最小命令（任意一台已部署机器）：

curl "http://127.0.0.1:8080/v1/elevation?latitude=47.1&longitude=8.4"

{"elevation":[789.0]}

六、适用场景与限制

6.1 适用场景

6.2 限制与注意事项

• 冷缓存慢：远程缓存模式首次请求某区域需从 S3 拉取多个块，实测 42.6 秒；低频单点调用反而不如直接打公共 API。
• 磁盘与内存门槛：官方要求现代 SIMD CPU（AVX2，支持 x86-64 与 Arm）、最低 8 GB 内存（推荐 16 GB）、中小规模部署至少 100 GB 存储（NVMe 优先，缓存与数据库共用磁盘 I/O）。
• 公平使用：公共 API 非商用免费，日请求超 1 万次需联系官方；滥用会被封禁。
• AGPL 义务：修改服务端源码后对外提供网络服务，必须开放修改后的源码。
• 官方支持口径：官方文档明确「不为小规模部署提供支持」，小部署依赖社区 Discussions。
• 预报非观测：数据来源是数值模式输出，个别时段与实况有偏差；对精度敏感的场景应结合多模式对比（models= 参数）。

七、同类选型对比

7.1 量化对比表

选取四类代表性方案对比（星数与版本均为 2026-10-28 查询值；「—」表示不适用）：

7.2 选型建议

• 需要全球范围、多模式、免密钥，且未来可能上量或要离线：选 Open-Meteo，公共 API 与自托管同一套代码，切换成本近乎为零。
• 业务只覆盖德国且需要 DWD 原始要素的 Python 生态：Bright Sky 更轻，但非全球方案。
• 追求零运维且预算允许、接受闭源与再分发限制：OpenWeatherMap / Meteum 等商业 API。
• 欧洲项目想直接用国家气象局官方出口：MET Norway Locationforecast 免费无 Key，但只能调在线服务、不可自托管。

💡 技术拓展：接入天气数据的四条常见途径对比——

途径	成本	自主可控	典型取舍
商业聚合 API（OWM/Meteum 等）	按量付费	低	稳定省事，受限于商业条款
无 Key 开放 API（Open-Meteo 公共 API、met.no）	免费	低（依赖他方可用性）	上手最快，有公平使用约束
自托管聚合服务（Open-Meteo 自托管）	一台服务器起	高	数据不出网、无调用上限，承担运维与 AGPL 义务
直连国家气象中心原始数据（DWD Open Data 等）	免费 + 高工程量	最高	需自行处理 GRIB 解码、格点插值、更新调度

Open-Meteo 的价值正是把最后一条途径工程化后同时开放前三种形态；本文实测采用其公共 API 与官方包自托管双路径验证。

八、参考链接

官方与一手来源：

1. GitHub 仓库：https://github.com/open-meteo/open-meteo
2. Releases（1.7.0，2026-10-16）：https://github.com/open-meteo/open-meteo/releases
3. 官网与 API 文档：https://open-meteo.com/en/docs
4. 自托管指南（仓库 docs/getting-started.md）：https://github.com/open-meteo/open-meteo/blob/main/docs/getting-started.md
5. 模式数据下载文档（docs/downloading-datasets.md）：https://github.com/open-meteo/open-meteo/blob/main/docs/downloading-datasets.md
6. 多节点同步文档（docs/sync-command.md）：https://github.com/open-meteo/open-meteo/blob/main/docs/sync-command.md
7. OM 文件格式：https://github.com/open-meteo/om-file-format
8. 官方开放数据分发（AWS Open Data）：https://github.com/open-meteo/open-data
9. 许可文本：AGPL-3.0（https://www.gnu.org/licenses/agpl-3.0.html）、CC BY 4.0（https://creativecommons.org/licenses/by/4.0/）
10. 对比项仓库：Bright Sky（https://github.com/jdemaeyer/brightsky）、MET Norway Locationforecast 文档（https://api.met.no/weatherapi/locationforecast/2.0/documentation）

本栏系列文档：

• 《Open-Meteo 1.7.0 安装部署指南》
• 《Open-Meteo 1.7.0 配置参数详解》
• 《Open-Meteo 1.7.0 常用 CLI 命令与工具详解》