做气象、气候、环境研究的朋友，大概率都绕不开ERA-5这套再分析数据。我最早接触ERA-5，是要整理一段连续多年的降水序列去做趋势分析，当时第一个想法就是“这种官方数据肯定有个统一下载入口”，结果一查，发现ECMWF提供的是CDS（Climate Data Store）平台，配套有一个叫cdsapi的Python库。研究半天把流程跑通之后，最大的感受是：下载ERA-5这件事本身不难，难的是把那些隐藏的规则搞清楚——比如API Key怎么配、区域范围怎么写、变量代码去哪查、批量下载怎么做到断点续传。这篇就把我实际操作中验证过的方法完整写出来，目标读者是刚接触ERA-5、需要用Python批量取数的科研人员和工程师，你能从零配好环境，再到写脚本批量下载，最后避开那些坑。
1. 需求分析与项目思路
1.1 先说清楚ERA-5到底是个什么东西
ERA-5是ECMWF（欧洲中期天气预报中心）发布的第五代全球再分析资料，时间覆盖从1940年至今，空间分辨率约0.25度（大约31公里），输出频率可以到小时级。你可以把它理解成一份用数值模式和数据同化技术“重新回放”出来的全球大气历史档案——它把过去几十年分散的观测数据（气象站、探空、卫星、浮标等）统一融合进一个物理一致的网格场里，使得任意地点、任意时刻的大气状态都能被“复盘”。对科研和工程来说，这意味着你没有自己的观测站，也能拿到一份连续、均一、覆盖全球的气象数据，用来驱动水文模型、分析极端天气、验证气候模式，都是常规操作。
再分析数据不是实测，但比单纯的卫星反演或插值产品更可靠，因为它有完整的动力学约束。这也是它被广泛用作“基准数据”的原因。你在论文里写“本研究使用ERA-5数据”，审稿人基本不会质疑数据的权威性，但他们会关心你是怎么下载、怎么处理、怎么保证时间一致性的——这就回到了我们这篇文章的主题。
1.2 为什么选官方CDS接口，而不是第三方下载服务
早期下载ERA-5很多人会去第三方网站找打包好的数据，比如某些高校的镜像站、百度网盘分享的大文件包，甚至有人会去爬一些抓好的GRIB文件。我不建议你这么干，理由有三个：
第一，数据时效性没法保证。ERA-5是滚动更新的，今天下载的数据和三个月前下载的数据可能在同一时间戳上存在细微差异（新版本会用更优的输入数据和同化方案回溯更新），第三方打包的往往是旧版本，而且你不知道它哪一天断了更新。
第二，可定制性差。你通常只需要某个区域、某些变量、某几个气压层，第三方包往往是全球全变量全层的，一个文件几十GB，光存储就是负担。通过官方接口按需切取，你只需要下载自己关心的那一小块，磁盘占用小几个数量级。
第三，毕竟是学术数据，来源可追溯、方法可复现很重要。用官方API配合脚本，你能完整记录下载了哪个数据集、哪个时间层、哪个区域，写方法学的时候清清楚楚。有的期刊审稿人会要求你提供数据获取方式，用官方接口就好交代得多。
所以我的结论很明确：官方CDS API + cdsapi库，是下载ERA-5的正确打开方式。虽然偶尔会遇到请求排队、连接中断等问题，但整体可靠性是第三方渠道完全没法比的。
1.3 核心需求拆解：一次完整的下载，你需要做哪些决策
在动笔写代码之前，最好先把需求拆清楚。我一般会按照下面这个清单快速过一遍，避免后期反复修改请求参数浪费时间。
- 选数据集：ERA-5按“产品类型”分很多种，最常见的是单层数据（reanalysis-era5-single-levels）和气压层数据（reanalysis-era5-pressure-levels）。单层数据适用于地表变量（2米气温、降水量、10米风速、海平面气压等），气压层数据才有不同高度上的温压湿风（比如500hPa位势高度）。这个选择直接决定数据集的名称和可用的变量代码，千万别搞混。
- 选变量：去ECMWF官方的变量列表页面查代码，比如2米气温的代码是2m_temperature，总降水量是total_precipitation。变量代码看起来像变量名，但又不完全等同于常见的缩写，复制粘贴最稳妥，不要手打。
- 选时空范围：时间上要明确年份、月份、日、小时（ERA-5完整数据是逐小时的）；空间上要明确是全球还是某个经纬度矩形区域。区域范围直接决定返回文件的大小，建议能裁剪就裁剪。
- 选网格和格式：ERA-5本身是0.25度规则网格，但API允许你重采样到更粗的网格（比如0.5度或1度）。输出格式一般建议选netCDF，因为Python生态里xarray对netCDF支持最好；如果你要直接用气象可视化工具，GRIB也行，但处理起来麻烦一点。
这些决策看似琐碎，但每一个都关系到后续数据能不能直接用、文件会不会大到爆盘。接下来我会把每个环节的实操细节都过一遍。
2. 环境准备与依赖安装
2.1 Python环境的首选方案
做数据下载和处理，我建议直接用Anaconda/Miniconda建一个独立环境，别往base环境里乱装东西。一个干净的conda环境能让你在出问题时快速重建，不至于把整个系统搞乱。
如果你还没装Python，Miniconda是最省事的：去官网下载对应系统的安装包，一路默认安装即可。装好后打开终端（Windows下是Anaconda Prompt），新建一个专门的环境，我用的是：
conda create -n era5 python=3.11 -y conda activate era5Python版本选3.9到3.12都行，cdsapi对版本要求不严格，但太老的版本（比如3.7以下）可能依赖装不上，太新的版本（3.13刚出的时候）某些科学计算库还没适配。3.11是我目前实测最稳的。
2.2 安装cdsapi与数据处理配套库
下载ERA-5的核心库就是cdsapi，它是ECMWF官方为CDS接口写的Python客户端。安装方式很简单：
pip install cdsapi后面处理数据大概率要用到xarray、netCDF4、pandas这些，一并装上：
pip install xarray netCDF4 pandas这里有个小技巧：如果你所在网络环境访问官方Python源速度一般，可以临时更换成国内镜像源，比如清华源。命令是：
pip install cdsapi xarray netCDF4 pandas -i https://pypi.tuna.tsinghua.edu.cn/simple镜像源解决的是下载速度问题，和后面CDS接口的访问速度无关，两码事，别混在一起想。
2.3 配置CDS API凭据：.cdsapirc文件的正确姿势
这一步是新手最容易卡住的地方。cdsapi调用接口时需要一个密钥，这个密钥不是写在代码里，而是放在用户目录下的一个叫.cdsapirc的配置文件里。
具体操作：先去CDS官网（cds.climate.copernicus.eu）注册账号、登录。登录后点击页面右上角的头像，进入个人主页，找到“API key”这一栏，你会看到两行信息，一行是url，一行是key，url形如https://cds.climate.copernicus.eu/api，key形如你的uid:一串很长的字符串。把这两行原样写进配置文件：
url: https://cds.climate.copernicus.eu/api key: 你的uid:你的API KeyWindows上的路径是C:\Users\你的用户名.cdsapirc，Linux/macOS是~/.cdsapirc。
注意：key字符串以uid开头，冒号后面是一长串十六进制字符，这串东西相当于你的账号密码，别贴到代码仓库里，也别发给别人。我有一次不小心把key写进了一个公开的GitHub仓库，意识到后赶紧上CDS重新生成了一组，这种事能免则免。
写完配置文件后，可以用一行代码验证是否成功：
import cdsapi client = cdsapi.Client()如果这一步没报错，说明凭据配置成功；如果报HTTP 403，大概率是key复制错了或者配置文件路径不对。
3. 核心实操：从写脚本到拿到数据
3.1 最简版本：下载单年单月单变量的全球数据
先从一个最简单但能完整跑通的例子开始。假设我要下载2023年1月1日0点时刻的全球2米气温，单层数据，要netCDF格式，脚本如下：
import cdsapi client = cdsapi.Client() client.retrieve( 'reanalysis-era5-single-levels', { 'product_type': 'reanalysis', 'variable': '2m_temperature', 'year': '2023', 'month': '01', 'day': '01', 'time': '00:00', 'grid': '0.25/0.25', 'format': 'netcdf' }, 'download_2t_20230101.nc' )这个脚本里，retrieve方法的第一个参数是数据集名称，第二个参数是一个字典，描述了数据请求的完整条件，第三个参数是保存到本地的文件名。运行之后，控制台会输出你的请求已经提交，并给你一个请求ID，然后进入排队状态，等待CDS服务器处理完成后自动开始下载。
这个最简版本虽然能跑，但实际应用场景很少——因为大多数人不可能只需要某一个小时的全球数据。但它是理解整套流程的最小单元，后面的复杂请求都是在这个字典上做加法。
3.2 批量下载：时间循环的正确打开方式
假设你要下载2015年到2023年每年1月、2月的日均2米气温，区域限定在中国大陆东部（纬度20到45，经度95到125），那就要在请求里加区域裁剪，并循环提交。
关于区域参数，CDS API里的写法是area: [北, 西, 南, 东]，注意是“北纬、西经、东经、南纬”的顺序，写成[45, 95, 20, 125]。这个顺序我每次都要确认一遍，因为很多人的习惯是先列四个角，容易搞反。北、西、南、东，想象成一个矩形，先写上边界，再写左边界，再写下边界，再写右边界，就不会错了。
批量下载的脚本框架：
import cdsapi import os client = cdsapi.Client() years = ['2015', '2016', '2017', '2018', '2019', '2020', '2021', '2022', '2023'] months = ['01', '02'] area = [45, 95, 20, 125] # 北, 西, 南, 东 for year in years: for month in months: filename = f'era5_t2m_{year}_{month}.nc' if os.path.exists(filename): print(f'{filename} already exists, skip') continue client.retrieve( 'reanalysis-era5-single-levels', { 'product_type': 'reanalysis', 'variable': '2m_temperature', 'year': year, 'month': month, 'day': [f'{d:02d}' for d in range(1, 32)], 'time': ['00:00', '06:00', '12:00', '18:00'], 'area': area, 'grid': [0.25, 0.25], 'format': 'netcdf' }, filename )这里有两个细节值得说明。
第一，day和time的值用列表时，表示“所有这些日期的所有这些时刻都下载”，比如day给全部31天，time给4个时刻，一个月的文件里就包含了31×4=124个时间切片。如果你给的day是1号到10号，那只有10天。这种写法比逐日循环提交要高效得多——请求次数少，服务器排队也少，最终文件是合并好的。
第二，我在循环开头加了一个文件是否已存在的判断。这个看似简单的小技巧，在下载大量月份时能救命——CDS请求偶尔会超时或失败，重跑脚本时已经下好的文件可以自动跳过，不用从头再来。后续我会在断点续传部分详细展开。
3.3 多变量与气压层数据：一次请求里放多个参数
很多场景要的不止一个变量。比如做蒸发估算需要2米气温、2米露点温度、地表气压、10米风速；做天气分析要500hPa位势高度、850hPa气温、海平面气压。CDS的API允许你在一次请求里申请多个变量，多个气压层也是一样。
单层多变量的写法，把variable从字符串改成列表：
'variable': ['2m_temperature', '2m_dewpoint_temperature', 'surface_pressure', '10m_u_component_of_wind', '10m_v_component_of_wind']气压层数据的请求则不同，数据集名称变成reanalysis-era5-pressure-levels，变量的值通常填的是比如geopotential（位势）、temperature（气温）、u_component_of_wind（纬向风）这种“没有高度属性”的变量名，高度信息用pressure_level单独指定：
client.retrieve( 'reanalysis-era5-pressure-levels', { 'product_type': 'reanalysis', 'variable': ['geopotential', 'temperature'], 'pressure_level': ['500', '850', '925'], 'year': '2023', 'month': '01', 'day': '01', 'time': '00:00', 'area': area, 'grid': [0.25, 0.25], 'format': 'netcdf' }, 'download_pl_20230101.nc' )注意：单层数据里可能也有一个叫temperature的变量，但那是2米气温；气压层数据的temperature才是各个高度层的温度。两者不要搞混。气压层数据的变量代码里，geopotential对应的是位势，不是位势高度，如果你需要位势高度，要么自己除以重力加速度，要么用geopotential再转一次。
多变量请求的好处是变量之间天然对齐在同一个时间和网格上，后续做计算（比如比湿、假相当位温这些需要多个变量组合的量）时特别方便，不用自己去对齐时间轴。
4. 常见问题与排查技巧实录
4.1 HTTP 400/403错误：请求被拒绝
实际使用中遇到的第一类报错就是HTTP 4xx。403通常是API Key不对，400则复杂一些，常见的原因是参数名写错了、数据集名称不匹配、变量代码不存在。
排查思路我总结成一句话：逐项核对请求字典里的每个键值对。最典型的几个坑：
- 把单层数据集去请求气压层变量（比如把geopotential塞进reanalysis-era5-single-levels里），接口直接拒绝。
- 变量代码多了个空格或下划线，比如2m_temperature写成了2m_temperature_，报错。
- pressure_level的值写成了字符串"500hPa"而不是"500"，报错。
- 日期格式错误，比如月份写"1"而不是"01"，有的接口能忍，有的不能忍，统一写成两位数最省心。
CDS的错误信息其实写得比较清楚，会告诉你具体是哪个键出了问题，但新手常犯的一个错误是一看到报错就直接看最后一行的提示，忽略了前面的错误详情。我的习惯是先把完整报错复制到一个文本里，再把请求字典逐行对一遍，90%的问题都能自己找出来。
4.2 请求一直在队列里，怎么回事
这是使用CDS下载ERA-5最常见的等待问题。CDS是共享服务平台，请求提交后会进入队列，高峰期（比如每年秋季开学前后、重大天气事件后）等待时间可能从几分钟延长到几十分钟甚至更久，这是正常现象，不是因为你的请求卡死了。
我对付排队问题有三个办法：
第一，把大请求拆小。比如你一次请求十年的逐小时数据，服务器需要处理的数据量非常庞大，排队的优先级也不会高。拆成按月请求，每个文件就几十MB到几百MB，处理快，优先级也高。实测下来，小请求的等待时间通常只需几秒到几十秒。
第二，避开整点提交。别问我为什么，我观测到的现象是每个整点附近的提交量明显增加，可能是很多人设了定时任务。避开整点，排队体验会好一些。
第三，如果你经常要做大量请求，可以了解一下CDS的“脚本方式批量提交”机制，用cdsapi的扩展功能把请求拆成多个子请求并行提交。注意：不是让你开几百个线程去同时提交，那样容易被平台限流甚至封禁账号。合理的方式是每次提交几个请求，等一个完成后再提交下一批。
4.3 下载大文件时连接中断，怎么断点续传
这是我在长期批量下载中遇到最多的另一个实际问题。一个包含多年逐小时数据的请求，返回文件可能有十几个GB，下载过程中一旦网络连接中断，cdsapi默认是直接报错退出，不会断点续传，之前下载的部分全部作废，非常恼人。
我这里提供一个实际可用的断点续传思路，核心是两步：
第一步，让cdsapi的请求结果先保存到CDS服务器端，获取一个资源链接，再自己用分段下载的方式把文件拉下来。方法是在retrieve调用里传入一个download=False参数，这样不会直接下载，而是返回一个Result对象，里面包含下载链接：
import cdsapi client = cdsapi.Client() result = client.retrieve( 'reanalysis-era5-single-levels', { 'product_type': 'reanalysis', 'variable': '2m_temperature', 'year': '2023', 'month': '01', 'day': ['01', '02', '03'], 'time': '00:00', 'grid': [0.25, 0.25], 'format': 'netcdf' } ) print(result.download_url)第二步，拿到下载链接后，用支持断点续传的下载工具，比如Linux的wget配合-c参数，或者写一个带分块请求的Python脚本，从上次断开的位置继续下载。wget的用法很简单：
wget -c "下载链接" -O mydata.nc这里要特别说明：下载链接是有时效性的，通常是几十分钟到几小时，过期后需要重新提交请求。所以拿到链接后尽快开始下载。如果文件特别大，拆成小请求再分段下载是更稳的策略。
另外，cdsapi本身在新版本中也对下载稳定性做了优化（比如增加了重试机制），如果你只是偶尔下几个小文件，直接用默认方式问题也不大。
4.4 文件太大，内存吃不消怎么办
有时候好不容易把数据下载好了，打开时发现一个19GB的netCDF文件，xarray.open_dataset直接把内存吃了20多个GB，机器当场卡死。我踩过这个坑之后总结了三条经验：
第一，真正常用的数据量没有你想象的那么大。绝大多数分析根本不需要全部变量、全部小时、全球范围。在请求阶段就把范围裁剪好，比事后处理省几百倍内存。下载前先估算一下：一个变量、一天、全球、一个时刻按标准做法计算，文件大约几十MB；如果限定到中国区域，就只有几MB到十几MB。先按小请求试一下文件大小，再决定是否扩大范围。
第二，用xarray的chunk参数做延迟读取。如果你的数据已经下载好了，又不想重新下，可以用dask分块读取：
import xarray as xr ds = xr.open_dataset('big_file.nc', chunks={'time': 100})这样数据不会一次性全进内存，需要计算哪部分就读取哪部分。
第三，netCDF和GRIB的底层数据结构都是自描述的，你可以先用工具检查数据集的维度、变量和属性。比如用xarray打开的Dataset对象，打印出来看看有哪些坐标和变量，再决定是否需要进一步提取子集。很多时候你以为需要整个文件，实际只需要其中某几个时次的某几个变量，这时用ds.sel或者ds.isel截取后重新保存成小文件，再释放大文件。
4.5 变量单位容易忽略，计算结果对不上
ERA-5里有些变量的单位和我们日常习惯不太一样，稍不注意就会在后续计算中出错。最典型的是降水量，ERA-5的total_precipitation单位是米（m），表示的是单位面积上的等效水深，不是毫米。你要是直接按毫米去解读，数值会小1000倍，得出完全错误的结果。正确做法是在读取后乘以1000转成毫米。
另一个高频坑是温度，2m_temperature单位是开尔文（K），下载下来是280多这样的数值，很多做应用的人下意识以为是摄氏度，不去减273.15，后面的统计分析全偏了。
再比如，风速的u/v分量，单位虽然是m/s，但u代表纬向风，正值为西风，v代表经向风，正值为南风。如果你要做风速大小，记得要算sqrt(u^2+v^2)，而不是直接用某个分量。
我在脚本里处理单位的习惯是，每次下载完数据后先打印出变量的units属性，用xarray可以这样查：
import xarray as xr ds = xr.open_dataset('era5_t2m_2023_01.nc') for var in ds.data_vars: print(var, ds[var].attrs.get('units', 'no unit'))这个习惯帮我避免了很多因为单位对不上导致的返工，建议大家都养成。
5. 数据质量与后续处理的经验之谈
5.1 拿到文件后的第一步：先做数据体检，别急着分析
数据下载成功只是一个开始。我在拿到任何一批新下载的ERA-5数据后，不会直接开始分析，而是先做一次“数据体检”，整个流程大概十分钟，但能省下后面几十个小时的debug时间。
体检项目包括：文件能否正常打开、维度大小是否符合预期、时间轴是否有缺失、空间范围是否正确、变量值域是否在合理区间。检查时间轴和空间范围用xarray非常方便：
import xarray as xr ds = xr.open_dataset('era5_t2m_2015_01.nc') print(ds['time'].min(), ds['time'].max(), len(ds['time'])) print(ds['latitude'].min(), ds['latitude'].max()) print(ds['longitude'].min(), ds['longitude'].max())如果请求的是一个月的逐6小时数据，那么时间轴应该包含124个时次（31天×4），前后边界应该正好是月初和月末。如果时间点少了，说明请求参数或者下载过程中出了问题，趁早发现，不要等到分析完才发现数据有明显缺口。
值域检查也很直观：2米气温在地球上不会低于-100摄氏度（173K），不会高于60摄氏度（333K）；总降水量不可能是负值。如果数值超出物理合理范围，那大概率是变量代码选错了，或者混合了不同的产品类型。
5.2 把netCDF转成更趁手的数据结构
netCDF是科研数据标准格式，但不是所有下游工具都能直接读。如果你需要把ERA-5数据转成CSV表格或者TXT文本（比如要输入到某个地方水文模型里），可以用pandas打平数据：
import xarray as xr import pandas as pd ds = xr.open_dataset('era5_t2m_2015_01.nc') # 选择某一个经纬度点的时间序列 ts = ds['t2m'].sel(latitude=30, longitude=120, method='nearest') df = ts.to_dataframe().reset_index() df.to_csv('t2m_point_30120.csv', index=False)这里需要说明两点：一是所有变量名在netCDF里保存的通常是短名称（如例子里的t2m，有些数据集里叫2m_temperature），以你下载文件里实际打印出来的为准；二是如果选了method='nearest'，实际取到的是距离你指定经纬度最近的网格点，不是精确插值，如果你对精度要求高，需要用插值算法处理。
5.3 多个文件合并和长时间序列处理
批量下载按年月拆分的好处是请求稳定，但后续分析往往需要一个连续的长序列。用xarray合并多个文件有两种方式，取决于你的数据结构。
如果是同一次请求拆成的多个文件，它们的时间变量不重叠，直接用concat合并：
import xarray as xr files = [f'era5_t2m_{year}_{month}.nc' for year in years for month in months] ds_list = [xr.open_dataset(f) for f in files] ds = xr.concat(ds_list, dim='time')如果你下载的是同一时间段的多个变量，变量结构可能不同，合并用merge：
ds = xr.merge([ds_t2m, ds_precip, ds_pressure])这里有一个容易踩的细节：ERA-5的经纬度网格是全球规则格点，不同文件的时间和坐标通常是完全对齐的，但如果请求参数里网格设置不一致（比如一个文件是0.25度，另一个是0.5度），合并时会有坐标不匹配的冲突。解决办法是统一在请求阶段就使用完全相同的area、grid参数，这是最省心的做法。
5.4 关于数据版本的一点提醒
ERA-5不是静态数据集，ECMWF会根据新的再分析输入或同化版本对历史数据进行更新，所以同一天提交的同一个“2023年1月”的请求，在不同时期下载到的底层数据版本可能略有差异。对大多数研究和工程应用来说，这种差异可以忽略；但如果你要发表学术论文，建议在方法部分写清楚下载日期和所使用的数据集版本号，审稿人一般会认可。CDS平台在数据集的详情页会提供当前版本号信息，下载时留意一下，写进方法学里就没问题。
6. 自动化与批量下载的进阶技巧
6.1 用脚本文件管理请求参数，而不是写一堆重复代码
批量下载最容易失控的就是脚本变得越来越长，这个变量改一下，那个年份加一下。我的建议是把所有请求参数集中定义在一个地方，甚至直接用配置文件来管理，脚本只负责读取并提交。
比如用yaml文件存请求参数：
dataset: reanalysis-era5-single-levels product_type: reanalysis variable: - 2m_temperature - total_precipitation years: [2015, 2016, 2017] months: [1, 2] area: [45, 95, 20, 125] grid: [0.25, 0.25] format: netcdfPython脚本读这个配置，再生成具体的请求，改参数时只动yaml文件，不用改代码。这个方法在数据需求经常变化的场景下特别有用，比如导师今天让你下华东区域的降水，明天又让你改成西北区域的温度，改配置文件会比改代码快得多。
6.2 日志记录：让下载过程可复盘
下载大量数据时，难免遇到中途报错、需要重跑的情况。如果没有日志，你根本不知道哪些文件已经成功下载了。我的做法是在脚本里加一个简单的日志记录模块：
import logging logging.basicConfig( filename='download.log', level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s' ) # 每次成功或失败都写一行日志 logging.info(f'{filename} downloaded successfully') logging.error(f'{filename} failed: {str(e)}')配合前面提到的文件存在性检查，即使脚本跑挂了，重跑时也能自动跳过已完成的部分，只处理失败的，下载效率提升很明显。
6.3 定时任务与监控：长周期下载的省心方案
如果下载任务非常大（比如几十年的逐小时数据），可能得跑几天甚至几周。这种情况下，不建议人守着终端干等。可以把脚本放到服务器上，用cron（Linux）或计划任务（Windows）定时跑，配合日志记录和文件存在性检查，实现无人值守断点续跑。
我的经验是分三层：第一层，每个文件下载时记录状态；第二层，每次脚本运行时先扫描已有文件，跳过已完成的；第三层，每天定时运行一次脚本，只补当天未完成的部分。这样即使某天请求排队特别久或者网络中断，第二天脚本会自动重试，整个下载流程很省心。
6.4 注意请求配额，别把自己号搞封了
CDS虽然免费，但不是无限量的。它有一套请求队列和配额管理机制，单账号短时间内提交大量请求可能会被限制甚至临时封禁。我的建议是：控制单次请求的数据量，不要一次性把十年的逐小时数据塞进一个请求；控制提交频率，批次之间加一点间隔（比如sleep 1到2秒），避免短时间内密集调用；如果遇到HTTP 403或者请求被拒绝，不要立刻重试，先停下来查一下是不是触发了配额限制。
从我自己长时间下载的经验看，把请求拆成“每月一个文件”的粒度是最稳妥的：单文件不大，排队快，失败了重跑代价低，配额消耗也比较均匀。全局一次性请求也不是不行，但文件大到一定量级后，从排队到下载完成的整个周期可能长达数小时，期间任何一次网络抖动都可能导致全部白费。
写在最后的一点体会
把ERA-5下载这条路彻底走通之后，回头看最花时间的其实不是写代码，而是搞清楚那些藏在文档角落里的“约定俗成”——比如area参数的顺序、变量单位的坑、请求队列的脾气。我可以负责任地说，只要你把上面这些环节都处理明白了，从零开始到拿到第一份可用数据，不会超过一个小时。之后不管是做气候分析、水文模拟还是天气诊断，这套下载流程都会成为你工具箱里一个稳定、可复用的起点。
