企业官网建设流程全解析

还记得第一次在 CDS 上下载 ERA5 数据时，我盯着那个队列进度条看了一整晚，第二天早上一看——请求还在排队。这些年用下来，ECMWF 的 ERA5 已经成为气象、水文、新能源评估和气候变化研究里最常用的再分析数据集，十个人做相关方向，有七八个都在用它。但说实话，真正能把这套数据从“知道”用到“顺手”的人不算多，很多坑不实际踩一遍根本想不到。

这篇文章是这几年我用 ERA5 的完整经验整理：从数据本身是什么、变量结构怎么分、官方下载怎么配置，到 Python 批处理怎么做，再到那些高频报错怎么排查，一次讲清楚。文章比较长，建议先收藏。无论你是刚接触再分析数据的研究生，还是需要批量拉数据做风资源、径流模拟的工程人员，这套流程都适用。

1. ERA5 是什么：从 ECMWF 和再分析说起

1.1 再分析到底在做什么

很多人第一次接触“再分析”这个词时容易懵：它和普通的观测数据、模式预报数据到底有什么区别？

简单来说，再分析是用一个固定的、当前最新的资料同化系统，把过去几十年散落在地面站、探空、卫星、浮标、飞机报等渠道的观测数据统一“喂”进数值模式里，通过同化算法不断校正模式状态，最终生成一套覆盖全球、时空连续、物理自洽的网格化数据集。它就像一个“历史天气的重新演绎版”——模式提供背景场和物理约束，观测不断把模拟偏差拉回真实。

再分析数据最大的价值在于：它补全了观测的空白区域。海洋中央、青藏高原、极地、沙漠这些地方，地面观测站点稀疏，但再分析数据在这些区域依然是完整且连续的网格。对研究来说，这意味着你可以拿到全球任何一点过去几十年的温度、风、气压、降水序列，而不需要依赖某个站点是否建站、是否迁站。

ECMWF 全称欧洲中期天气预报中心，是全球公认的数值预报和再分析领域头部机构。ERA5 是它推出的第五代全球大气再分析产品，前身是著名的 ERA-Interim。同类的产品还有日本气象厅的 JRA-55、美国 NASA 的 MERRA-2，但论引用量、使用范围和更新频次，ERA5 目前是当之无愧的主流。

1.2 上手前先记住三组硬参数

用任何数据前，先搞清楚它的骨架。ERA5 的三组核心参数，我建议你直接记下来：

• 水平分辨率：0.25° x 0.25°，全球网格约为 1440 x 721 个格点，水平格距约 31 公里。相比上一代 ERA-Interim 的 0.75°（约 79 公里），精度提升非常明显。
• 垂直分层：模型原始 137 层，从地表一直延伸到 0.01 hPa（约 80 公里高度）。对外提供的压力层产品包含 37 层，覆盖 1000 hPa 到 1 hPa。日常研究用压力层就够了。
• 时间分辨率：1 小时一次输出，覆盖 1940 年至今。ERA5T 是近实时产品，比正式版快约 5 天，后续会逐步更新为正式版。

这三个数字决定了 ERA5 能做什么：小时级分辨率让它能捕捉对流、海风、温度日变化这类此前 6 小时数据完全看不到的过程；31 公里的水平分辨率使得它在区域尺度的气象模拟中具备合理可信度，至少比粗网格的插值结果靠谱得多。

一个容易忽略的点：ERA5 的时间是 UTC 时间，不是北京时间。做中国区域研究时，要手动加 8 小时转换成北京时。比如 UTC 0 时对应的是北京时间早上 8 点。很多人画日变化曲线时发现相位差了几个小时，十有八九是这个原因。

1.3 和上一代 ERA-Interim 比，升级在哪里

ERA-Interim 在 2019 年 8 月正式停止更新，现在 ECMWF 只提供 ERA5 和 ERA5T。如果你还在网上找到 ERA-Interim 的旧教程，建议直接看 ERA5 版本，两者的数据结构和下载方式差异不小。

升级的核心点可以归纳为四个方面：

第一是时空分辨率。ERA-Interim 是 6 小时输出、0.75° 网格，ERA5 做到 1 小时、0.25°。做极端降水、大风过程、城市热岛这些研究，6 小时间隔根本不够看；1 小时数据让逐日极值统计、日内演变分析都成为可能。

第二是垂直层数。ERA-Interim 是 60 层，ERA5 是 137 层，高层大气和边界层内的垂直结构刻画更细。对研究边界层风廓线、逆温层结构的场景，这是个实打实的进步。

第三是同化系统。ERA5 使用更先进的 4D-Var 同化方案，且同化了大量历史卫星资料，特别是 1979 年以后的卫星微波探测数据，这让后几十年数据质量显著提升。

第四是不确定性信息。ERA5 提供 10 个集合成员的扰动估计，可以用集合离散度来量化数据的不确定性。虽然日常普通用户用得不多，但做风险分析或业务决策时这是个很好的参考。

还有一个小点：ERA5 把降水、辐射这类变量从“瞬时值”改为“累积量”的表达方式，这一点我在后面变量部分详细讲，非常关键。

2. 搞懂变量体系和数据结构

2.1 先分清 analysis 和 forecast 两类数据

ERA5 的使用者最容易犯的第一个错误，就是没搞清楚自己下载的变量属于 analysis 还是 forecast，然后处理出来的结果莫名其妙。

在 CDS（Climate Data Store）中，ERA5 的数据类型分为两种：

• analysis（分析场）：代表某个时刻大气状态的最优估计，比如温度、风、气压、湿度。这类变量描述的是“当时是什么状态”，适合直接使用。
• forecast（预报场）：代表模式从分析时刻开始向前积分得到的累积量或平均量，典型如降水、辐射通量。这类变量本质上不是“某个时刻的瞬时值”，而是“一段时间内的累积值”。

举个例子：total_precipitation 是累积降水量。CDS 提供的逐小时数据，这个变量表示的是从模式起报时刻开始到当前时刻的累积降水，并非该小时内的降水增量。所以要得到某小时的降水增量，需要用当前小时值减去前一个小时的值。同理，辐射变量（如 surface_solar_radiation_downwards）也是累积量，单位是 J/m²，需要做差分或按时间归一化处理。

这个逻辑很多人一开始反应不过来。我见过有人直接拿着逐小时降水累积序列去做极值分析，结果所有小时的值都在累加，越到后面越大，完全失真。

一个稳妥的解决方案：在 CDS 请求变量时，优先选好对应的数据类型。单层数据集中，2m 温度、10m 风这类状态量默认是 analysis；降水、辐射则应该把 product_type 选成对应的 forecast 字段。不同变量在数据文档页面都会注明所属类型。

2.2 三种空间形态：单层、压力层、模型层

ERA5 的变量按空间结构可以分成三大类：

单层变量（single level）：只在某个特定高度或地表输出，比如 2m 温度、10m 风、地表气压、海表温度、土壤湿度。这类变量在 CDS 的 “reanalysis-era5-single-levels” 数据集中，没有额外的垂直维度，读取和批处理最省心。

压力层变量（pressure level）：在标准气压面上输出，如 500 hPa 位势高度、850 hPa 温度、700 hPa 比湿等。数据集名称是 “reanalysis-era5-pressure-levels”。下载时需要指定 levelist，例如 ['1000', '925', '850', '700', '500']，单位是 hPa。对大多数天气分析和气候研究来说，压力层产品是标准选择。

模型层变量（model level）：对应模式原始 137 层，采用混合 sigma 坐标，数据集名称是 “reanalysis-era5-single-levels” 中并不包含，需要单独走 model levels 接口（reanalysis-era5-complete 或 CDS 内的 model level 入口）。模型层没有直接给出气压值，需要用混合坐标系数 a、b 和地表气压换算。普通应用不建议碰模型层，只有研究边界层结构、极端高层过程时才需要。

我的建议很简单：能用压力层就绝不用模型层，能选单层就不选多层。数据体积差好几倍，处理复杂度更是天壤之别。

2.3 常用变量速查表：名称、单位、类型

ERA5 在 NetCDF 格式下使用标准变量名，在 GRIB 格式下使用短名称，两者经常对不上。这里整理一份我高频使用的变量对照表：

这张表值得存一份。尤其是单位问题：温度是开尔文，不是摄氏度；降水单位是米，需要用毫米的话乘 1000；位势高度单位是 m²/s²，要换算成位势米需要除以重力加速度 9.80665；辐射是每平方米焦耳，要看小时平均功率要除以 3600。

还有一点要提醒：ERA5 的海表温度（sst）在陆地上也有填充值，它把陆地部分用地表温度替代了。做海洋相关分析时，一定要配合 land-sea mask 做掩膜处理，否则陆地格点会污染统计结果。

3. 数据获取：官方通道与 CDS API 下载实战

3.1 官方获取渠道只有一个主流选择

ERA5 的官方数据平台是 Copernicus Climate Data Store，简称 CDS，地址是 cds.climate.copernicus.eu。注册账号后，你可以通过网页交互式选择变量并提交下载请求，也可以用 API 脚本化批量下载。厄尔尼诺和行业用户的绝大多数下载都走这条路。

除了 CDS，还有一个可选的渠道是 AWS 的公开数据集。ERA5 的部分数据被镜像到亚马逊 S3 上，适合已经熟悉 AWS 生态、需要大规模拉取数据的团队。不过 AWS 版本是原始 GRIB 格式为主，且需要配置 Requester Pays，对个人用户门槛偏高，不推荐新手从这里起步。

另外要注意，国内访问 CDS 的稳定性在不同网络环境下差异较大，部分地区可能经常连接超时。这不是数据源的问题，更多是网络链路问题。遇到这种情况，通常的做法是重试、错峰（比如凌晨提交请求）、或者使用代理——但我不展开讨论网络层面的特殊手段，只强调 CDS 官方接口本身是稳定可靠的。

3.2 配置你的 CDS API 环境

用 Python 下载 ERA5 前，先做好三件事：

第一，在 CDS 官网注册账号并登录。

第二，进入用户面板，找到 API key 页面，里面会显示你的个人 UID 和 API Key。这两个值类似你的账号名和密码，不要泄露给别人。

第三，在你本机的用户目录下新建文件 ~/.cdsapirc，写入以下内容：

url: https://cds.climate.copernicus.eu/api key: <你的UID>:<你的API Key>

然后安装 cdsapi：

pip install cdsapi

安装完成后，可以用一行简单的代码测试连通性：

import cdsapi c = cdsapi.Client()

如果没报错，说明本地配置已经生效。如果提示 key 相关错误，多半是 ~/.cdsapirc 路径不对，或者 UID 和 Key 中间用了中文冒号。

3.3 写一个标准的下载请求

下面是一个非常典型的 ERA5 单层数据下载脚本，请求 2020 年 12 月北京时间 0 时、6 时、12 时、18 时（对应 UTC 前一日 16 时、22 时、4 时、10 时，这里我们直接用 UTC 时间）的 2m 温度，区域裁剪在中国境内：

import cdsapi c = cdsapi.Client() c.retrieve( 'reanalysis-era5-single-levels', { 'product_type': 'reanalysis', 'variable': '2m_temperature', 'year': '2020', 'month': '12', 'day': ['01', '02', '03'], 'time': ['00:00', '06:00', '12:00', '18:00'], 'area': [60, 70, 20, 140], # [北纬, 西经, 南纬, 东经] 'format': 'netcdf', }, 't2m_202012.nc' )

这个请求里的每个参数我都拆开讲一下：

• product_type：固定为 reanalysis。如果选择 reanalysis-era5-single-levels 里的近实时版本，则填 era5t。
• variable：就是上节表格里的 NetCDF 标准变量名。
• year、month、day、time：支持列表传入，CDS 会做笛卡尔积展开为多个子请求。但我建议 day 和 time 不要写太多，否则底层请求数量会爆炸，排队时间急剧上升。
• area：以 [北, 西, 南, 东] 为顺序，注意是北纬最大值在前，西经用负值，东经用正值。中国区域可以写成 [60, 70, 20, 140]。
• format：建议直接用 netcdf。GRIB 文件体积小但读取麻烦，新手阶段不要选 GRIB。

请求提交后，CDS 会返回一个 request ID 并进入队列。等待时间取决于服务器负载和你的数据量，短则几分钟，长则数小时，大请求过夜都有可能。

3.4 让下载又快又稳的五个实操习惯

经过这么多年的下载实战，我总结出五个直接影响成功率和速度的习惯：

第一，拆小请求。把一个大范围、多变量、长时间跨度的请求拆成多个小请求，比如按年拆、按变量拆。大请求排队时间长且容易超时，一旦断掉又要重新开始，反而更慢。

第二，同一时间只提交少量请求。CDS 对单用户有并发请求数限制，提交太多反而会被限流。我个人的经验是同时保持 2-3 个活动请求比较合适，既不会把配额撑爆也能高效利用等待时间。

第三，脚本里加重试机制。网络抖动是常态，在循环下载时遇到 HTTPError 或连接超时，等待几秒后重试通常能解决。下面是一个带重试的简化模板：

import time import cdsapi c = cdsapi.Client() def download_with_retry(request_params, target_file, retries=5): for i in range(retries): try: c.retrieve('reanalysis-era5-single-levels', request_params, target_file) print(f"下载完成: {target_file}") return True except Exception as e: print(f"第{i+1}次尝试失败: {e}, 等待重试...") time.sleep(30) return False

第四，关注配额。CDS 用户面板会显示你的下载配额和已用比例，主要是每月总字节数和每日请求数。配额用尽后请求会被挂起或拒绝。

第五，优先下载裁剪后的区域。如果不做全球研究，永远在请求里带上 area 参数，把数据量控制到最低。全球逐小时单变量一年的 NetCDF 文件大约几十 GB，裁剪到中国区域后只有一两 GB，差别显著。

4. 数据读取与批处理：从下载到可用的完整链路

4.1 搭建 Python 处理环境

ERA5 数据处理的标配是 xarray。它像是一个带坐标的 DataFrame，对多维网格数据的切片、筛选、聚合、画图支持非常完善。

我建议用 conda 创建独立环境，避免依赖冲突：

conda create -n era5 python=3.10 conda activate era5 conda install -c conda-forge xarray netcdf4 cfgrib eccodes dask

这里几个包的用途分清楚：

• xarray：核心数据处理库。
• netcdf4：读写 NetCDF 格式的底层库。
• cfgrib + eccodes：读取 GRIB 格式的引擎和 ECMWF 编码解码库。
• dask：可选，用于处理超大文件时的并行和分块计算。

环境装好后，建议先跑一个最小的读取脚本，确认链路没问题再往下做。

4.2 NetCDF 读取与坐标细节

NetCDF 是最省心的格式。用 xarray 读取：

import xarray as xr ds = xr.open_dataset('t2m_202012.nc') print(ds)

看到输出后，先检查三个维度：time、latitude、longitude。

一个关键细节：CDS 裁剪后的 NetCDF，经度坐标通常按 -180 到 180 排列。也就是说，中国的经度约 70-140 之间是正值，而美洲的经度为负值。如果你直接按照常见的地图习惯用 0-360 经度去索引，可能会什么都选不到。

另一个细节是维度顺序。裁剪后的数据 latitude 是从北到南排列的，也就是北纬 60 在前，南纬 20 在后。用 .sel() 做区域切片时，注意范围写法的方向：

# 选取中国区域 subset = ds.sel(latitude=slice(60, 20), longitude=slice(70, 140))

这里 latitude 的 slice 是 60 到 20，因为数组的纬度是从大到小排列的。如果写反了，你得到的是一个空数据集，或者倒序的纬度轴。

时间维度的处理上，xarray 会自动把 CDS 返回的时间坐标解码成 pandas 的 datetime 类型，所以你可以直接：

t2m_jan1 = ds['t2m'].sel(time='2020-12-01')

或者切片某个时间段：

month_slice = ds['t2m'].sel(time=slice('2020-12-01', '2020-12-31'))

每年各个月份的数据如果分散在多个文件里，用 open_mfdataset 合并：

ds_all = xr.open_mfdataset('t2m_2020_*.nc', combine='by_coords')

这个操作会自动按时间轴拼接，前提是每个文件的变量和格点坐标一致。

4.3 GRIB 读取与 cfgrib 的坑

GRIB 格式在气象里是标准交换格式，文件体积比 NetCDF 小很多，ECMWF 的原始数据主要也是 GRIB 分发。但 GRIB 在 xarray 里的读取体验不如 NetCDF 顺畅，至少要面对三个坑。

第一个坑：必须安装正确的底层库组合。cfgrib 需要依赖 eccodes，如果 eccodes 版本过旧，某些新变量会解析失败，报错信息通常类似 KeyError 或 shortName not found。解决办法是升级 eccodes：conda update -c conda-forge eccodes。

第二个坑：cfgrib 在读取包含多个维度的 GRIB 文件时需要指定过滤条件。比如一个文件里同时有多个气压层的温度，直接 open_dataset 可能报错：

ds = xr.open_dataset('era5_levels.grib', engine='cfgrib', backend_kwargs={'filter_by_keys': {'typeOfLevel': 'isobaricInhPa'}})

这个 filter_by_keys 参数是在告诉 cfgrib 只读取指定类型层的数据。类似地，如果要读取单层变量，需要把 typeOfLevel 设为 surface 或 heightAboveGround。

第三个坑：GRIB 读出来的坐标名往往和 NetCDF 不一样。压力层的坐标名可能是 isobaricInhPa 而不是 pressure_level，且单位是 hPa。每次读取后先打印一遍维度名，是最稳妥的检查手段。

基于这些坑，我的建议是：日常研究和分析直接用 NetCDF 格式，GRIB 保留给那些追求最小文件体积、且已经熟悉 ecCodes 工具链的场景。如果你下载的是 AWS 镜像的原始 GRIB 数据，可以用 ECMWF 官方命令工具 grib_to_netcdf 先把格式转换掉：

grib_to_netcdf -o output.nc input.grib

这个工具比自己在 Python 里折腾 cfgrib 稳定得多。

4.4 单位换算、统计聚合与质量校验

数据读取成功后，第一件要做的事是单位换算。ERA5 的原始单位偏向国际单位制，直接分析通常不直观。我的习惯是一开始就把单位统一成常用单位，后面就不用反复做转换：

# 温度：K -> ℃ ds['t2m_c'] = ds['t2m'] - 273.15 # 降水：m -> mm ds['tp_mm'] = ds['tp'] * 1000 # 位势高度：m²/s² -> 位势米 ds['z_gpm'] = ds['z'] / 9.80665 # 太阳辐射：J/m² -> W/m²（先差分得到累积增量，再除以时间秒数） ssrd_diff = ds['ssrd'].diff(dim='time') ssrd_wm2 = ssrd_diff / (3600.0)

需要注意，diff 操作会使得第一个时次变 NaN，这是正常的。如果你的数据是逐小时且已经是差分后的增量，可以直接除以 3600。

接下来是常用的统计聚合操作。日均值、月均值、气候态、区域平均是出现频率最高的四件事：

# 日平均 daily = ds['t2m_c'].resample(time='1D').mean() # 月平均 monthly = ds['t2m_c'].resample(time='1M').mean() # 气候态（多年同月的平均） climatology = ds['t2m_c'].groupby('time.month').mean() # 区域平均 region_mean = ds['t2m_c'].sel(latitude=slice(40, 30), longitude=slice(105, 122)).mean(dim=['latitude', 'longitude'])

用 groupby('time.month') 做气候态时，xarray 会自动生成一个 month 坐标，结果维度和原始不同，画图时要注意。

质量校验是很多人忽略的一步。再分析数据不是真值，它和观测存在系统性偏差。拿到数据后，至少做两件事：

第一，和站点观测做同期对比。选几个你研究区域内的气象站，提取对应格点的 ERA5 序列，和观测序列计算平均偏差和均方根误差。偏差超过阈值，说明该区域模式地形平滑影响明显，要谨慎使用。

第二，检查变量的物理范围。比如 2m 温度如果在 -100℃ 以下或 60℃ 以上，风向风速的值出现明显不合理跳跃，就要检查是否发生了数据损坏或读取错误。

再分析的山地偏差是常态。ERA5 虽然水平分辨率到 31 公里，但山区地形依然是平滑后的结果，实际山谷与山峰的海拔与真实地形存在差异。做高海拔区域研究时，如果结果和观测偏差过大，可以考虑更高分辨率的区域再分析数据，但这是后话。

4.5 一个完整的批处理示例

把上面的内容串起来，下面是一个实用的批处理流程：读取 2020 年 12 个月的 2m 温度文件，计算区域日均值并导出 CSV。

import xarray as xr # 1. 合并 12 个月文件 files = [f't2m_2020_{month:02d}.nc' for month in range(1, 13)] ds = xr.open_mfdataset(files, combine='by_coords') # 2. 单位换算 ds['t2m_c'] = ds['t2m'] - 273.15 # 3. 裁剪华北区域 hua_bei = ds.sel(latitude=slice(45, 30), longitude=slice(110, 125)) # 4. 区域平均 + 日平均 daily_mean = hua_bei['t2m_c'].mean(dim=['latitude', 'longitude']).resample(time='1D').mean() # 5. 转成 pandas DataFrame 并导出 df = daily_mean.to_dataframe(name='t2m_region_mean') df.to_csv('t2m_hua_bei_daily_2020.csv')

这个流程基本能覆盖八成的日常需求。如果数据量巨大，可以在 open_mfdataset 里加上 chunks 参数启用 dask 分块计算，避免一次性把全部数据读进内存。

5. 常见问题与排查技巧实录

5.1 CDS 下载阶段的典型问题

请求一直 queued 怎么办。

排队时间过长是最常见的问题。首先确认你的请求是否过大：全球范围 + 多变量 + 长时间跨度的大请求，排队数小时是正常的。解决方案是拆小请求，或者错峰下载，比如在欧美夜间时段提交，通常排队会明显缩短。

登录后 API 报 403 Forbidden。

检查 ~/.cdsapirc 文件里的 key 是否正确。注意新版 CDS 的 key 是一串包含冒号的字符串，复制时不要遗漏。如果文件确实没问题，重新生成一次 API key 再试。

提示 variable 不存在。

每个数据集支持的变量不同。单层数据集的变量在 “reanalysis-era5-single-levels” 文档页有完整列表，压力层变量在 “reanalysis-era5-pressure-levels” 文档里。变量名写错是最常见的下载报错原因。

下载到一半中断。

大文件下载中断后，CDS 不会自动断点续传。稳妥的做法是只请求裁剪后的小区域数据，并在脚本里加入重试逻辑。对特别大的数据，可以按日或按月拆成小文件分别下载，比一次性搞一个大文件安全得多。

5.2 数据读取阶段的典型问题

cfgrib 读 GRIB 文件报错，提示 typeOfLevel 冲突。

这几乎都是因为文件里混合了多种层类型。解决方法是加 filter_by_keys 参数，明确只读取某一种层。比如：

ds = xr.open_dataset('file.grib', engine='cfgrib', backend_kwargs={'filter_by_keys': {'typeOfLevel': 'surface'}})

读出来的 lat/lon 范围是反的或者全是 NaN。

先打印 ds.coords，检查 latitude 是升序还是降序。CDS 裁剪后的数据通常是北到南，也就是降序。如果你用 slice(20, 60) 这种升序写法，结果会是空数组。统一点的做法是：先打印坐标确定顺序，再写切片。

时间坐标为数值而不是时间。

如果你用 netCDF4 直接读取而非 xarray，time 变量会显示为 hours since 1900-01-01 这样的数值。解决办法是用 xarray 打开，它会自动解码。如果确实需要用 netCDF4，就用 num2date 转换。

降水序列出现累计不回落的现象。

这是典型的把累计量当增量用时出现的问题。total_precipitation 在逐小时数据里是累计值，处理时先 diff，再乘 1000 转毫米。如果不做差分直接做统计，结果根本没有意义。

5.3 数据质量层面的排查

ERA5 和站点观测偏差过大。

先看是否是地形引起的。在高原、山地、海岸线附近，网格平均和单点观测的差异天然较大。如果只是整体偏差，可以尝试用双线性插值提取站点所在格点，而不是直接取最近格点。另外确认观测和再分析的时间是否对齐，ERA5 是 UTC 时间，站点记录通常是北京时，别把时差当地形偏差。

同一研究里混用了 ERA5 和 ERA-Interim。

这两代数据之间存在系统性的气候态差异。做长期趋势研究或变化检测时，不要混用两代再分析数据。要么全用 ERA5，要么明确对比两套数据时单独标出差异范围。

文件损坏后重新下载，CRC 或解压报错。

NetCDF 文件损坏通常发生在网络中断时，文件虽然存在但不完整。xarray 打开时如果报错 "unexpected end of file"，删掉重新下载即可。这类问题在合并多个文件时尤其常见，建议合并前用一个小脚本逐个测试文件能否正常打开。

写在最后：一套从零开始的上手建议

如果你是一个刚接触 ERA5 的新手，我的建议是不要一上来就下载全球几百 GB 的数据。先选一个小区域、一个变量、一个月的 NetCDF 文件，把读取、单位换算、区域裁剪、日平均、画图这些流程完整跑通。在此基础上，再逐步扩大时间跨度和变量数量，过程中自然会遇到各种报错，那时再回头翻这篇文章的排查部分，会顺畅很多。

ERA5 数据本身是 ECMWF 提供的高质量产品，但数据质量高不代表使用门槛低，很多细节习惯需要在实际操作中建立起来。我个人这几年最大的体会是：再分析数据处理从来不是下载完就结束，单位、时次、坐标方向、累积量差分，每一个环节都可能埋着意想不到的问题。把基础流程敲实，后面再做大规模批处理，就真的只是体力活了。

如果你在实际使用中遇到了这篇文章没写到的坑，欢迎在评论区分享，我会把高频出现的新问题持续补充进来。