温度数据是很多分析和建模工作的底层输入，不管是做农业估产、城市热岛研究、疾病传播相关性分析，还是给某个区域的作物生长期做积温统计，日尺度的最高温和最低温都是绕不开的基础变量。这次要聊的，是在GEE（Google Earth Engine）里把2000年到2023年逐日的最高温、最低温数据批量拉下来这件事。标题看着简单，但真动手做过的人都知道，从数据集选型、时间范围切分、导出任务管理到最后的文件整理，中间有一堆细节能把人卡住。我前后折腾过好几轮，踩过的坑不算少，这里把完整思路和实操细节摊开讲，适合刚接触GEE、需要批量导出长时序气象栅格的朋友参考，也适合已经会写几行代码但总在导出环节翻车的人对照排查。

1. 先想清楚：日最高最低温到底该用哪个数据集

很多人一上来就搜"temperature dataset GEE"，然后随便挑一个看起来顺眼的开干，结果导到一半发现时间分辨率不对，或者变量根本不是日最高最低温。这一步选错了，后面全白费，所以先把这个前提讲透。

1.1 日最高最低温的典型数据来源对比

GEE里跟温度相关的数据集不少，但真正提供**逐日最高温（Tmax）和最低温（Tmin）**的，主流选择集中在几个产品上。我按实际使用体验列个对照，方便你按需求取舍。

这里有个特别容易混淆的点：MODIS的LST是地表温度（Land Surface Temperature），不是气象站意义上的气温。很多人图1km分辨率高就用了MODIS，结果发现数值跟气象站差一大截，因为地表温度和2米气温是两回事。如果你要的是"气温"，就得选DAYMET、PRISM、GRIDMET这类基于气象站插值的产品；如果你要的是地表热状况，MODIS才合适。这个区别我在早期项目里吃过亏，导出来的数据跟实测对不上，排查半天才发现是变量语义搞错了。

1.2 全球覆盖与区域精度的取舍逻辑

选数据集本质是在覆盖范围和空间精度之间做权衡。DAYMET、PRISM、GRIDMET都是区域产品，主要覆盖北美，精度高（1-4km），但出了这个范围就没数据。ERA5-Land是全球覆盖，但分辨率粗（约11km），做小区域分析时像元太少，代表性有限。

我的经验是：如果研究区在北美，优先DAYMET或GRIDMET，1km/4km的精度对日尺度温度分析足够用；如果研究区在全球其他区域，ERA5-Land Daily是稳妥选择，虽然粗但覆盖完整、时间连续性好。标题里说2000到2023年，这个时间跨度对上述数据集都在覆盖范围内，所以时间不是筛选的主要矛盾，空间范围和精度才是。

还有一点值得提醒：不同数据集的时间标注习惯不一样。有的用日期直接标注，有的用"day of year"或者带时区偏移的时间戳。导出前一定要确认时间字段的含义，否则后面做时间序列对齐时会错位。我见过有人把ERA5的小时数据当成日数据直接用，结果一天24条记录混在一起，统计全乱。

1.3 为什么日尺度导出比月尺度麻烦得多

月数据一年12景，24年也就288景，导出压力小。日数据一年365或366景，24年接近8800景，这个量级对导出任务管理是个考验。GEE的导出任务有并发限制，一次性提交几千个任务会排队排到天荒地老，而且中途失败重试很麻烦。所以日尺度导出的核心难点不在"能不能导"，而在"怎么高效、稳定地导完"。这也是后面要重点展开的部分。

2. 时间范围切分的策略：别一次性硬刚24年

直接写一个2000-01-01到2023-12-31的filter然后export，理论上可行，但实际操作中会遇到几个现实问题：单次导出的影像集合太大导致任务超时、失败后不知道从哪重来、文件体积过大不好管理。我的做法是按年切分，逐年导出，这个策略看起来笨，但稳定性高得多。

2.1 按年循环的代码骨架与参数设计

核心思路是用一个年份列表循环，每年构造独立的ImageCollection、做合成、导出。骨架大概是这样：

var startYear = 2000; var endYear = 2023; var roi = geometry; // 你的研究区 for (var y = startYear; y <= endYear; y++) { var start = ee.Date.fromYMD(y, 1, 1); var end = ee.Date.fromYMD(y, 12, 31).advance(1, 'day'); var daily = ee.ImageCollection('NASA/ORNL/DAYMET_V4') .filterDate(start, end) .filterBounds(roi) .select(['tmax', 'tmin']); // 后续合成与导出 }

这里几个参数的设计意图值得说清楚。end用12月31日再advance一天，是为了让filterDate的右开区间把12月31日包含进来——GEE的filterDate是左闭右开，如果直接写12月31日，当天数据会被漏掉。这个细节不注意，每年都会少一天，24年下来少24天，做长时序统计时会有系统性偏差。

filterBounds(roi)的作用是空间裁剪，能显著减少导出数据量。但要注意，filterBounds只是筛选与roi相交的影像，并不会真正裁剪像元，真正的裁剪要在导出时用region参数或者clip()。很多人以为加了filterBounds就裁好了，结果导出来还是整幅影像，文件巨大。

2.2 逐年导出的任务命名与去重

导出任务多了以后，命名混乱是灾难。我的习惯是文件名带上数据集标识、变量、年份，比如daymet_tmax_tmin_2000。这样后期在Drive或者本地整理时一眼能认出来。如果用Export.image.toDrive，fileNamePrefix就按这个规则拼。

去重方面，GEE的Tasks面板里如果重复提交同名任务，不会自动覆盖，而是生成多个任务。所以循环提交前最好先确认没有历史残留任务，或者用脚本记录已提交的年份。我一般会在本地维护一个简单的清单，跑完一年勾一年，避免重复劳动。

2.3 单年数据量估算与导出格式选择

单年日数据，假设研究区不大，DAYMET 1km分辨率，一年365景，每景tmax+tmin两个波段。导出格式上，GeoTIFF是首选，兼容性好，后续用Python的rasterio、GDAL都能读。如果研究区很大，单年数据可能上GB，这时候要考虑分块导出或者降低分辨率。

有个估算方法：单景影像的像元数乘以波段数乘以数据类型字节数。比如1000×1000像元、2波段、Float32（4字节），单景约8MB，365景约2.9GB。这个量级单文件导出可能吃力，可以考虑按季度或按月再切分。我一般先跑一年试试水，看实际文件大小再决定要不要细化切分粒度。

提示：导出前先用print(daily.size())确认每年实际影像数量，正常应该是365或366。如果数量明显偏少，说明数据集在该年份有缺失或者filter条件有问题，先排查再导。

3. 合成与波段处理：把日影像整理成可用的结构

原始ImageCollection是每天一景，每景含tmax、tmin两个波段。导出时有两种组织方式：一是保持Collection结构逐景导出，二是合成一个多波段影像一次性导出。两种方式各有适用场景，得看后续怎么用。

3.1 逐景导出与多波段合成的取舍

逐景导出适合后续要做时间序列逐日分析的情况，每天一个文件，时间戳清晰。但24年近8800个文件，管理成本高。多波段合成是把一年的365景堆成一个365波段的大影像，一个文件搞定一年，文件管理简单，但单文件体积大，且部分软件对超多波段的支持不好。

我的折中方案是：如果后续用Python做批量处理，逐景导出更灵活，用文件名带日期就能排序；如果只是做简单的年度统计或者可视化，多波段合成更省事。标题场景是"下载每天的数据"，从字面看是要保留日粒度，所以逐景导出更贴合需求。合成的话可以用daily.toBands()，但波段名会变成类似tmax_2000_01_01的形式，后期解析要写点正则。

3.2 缺失值与无效像元的处理

DAYMET等数据集在某些区域或时段可能有缺失值，通常用特定填充值表示（比如-9999）。导出前如果不处理，后续统计会把填充值当成真实温度，结果离谱。处理方式是在导出前用updateMask或者where把无效值mask掉。

var cleaned = daily.map(function(img) { var tmax = img.select('tmax').updateMask(img.select('tmax').gt(-9000)); var tmin = img.select('tmin').updateMask(img.select('tmin').gt(-9000)); return tmax.addBands(tmin).copyProperties(img, ['system:time_start']); });

这里gt(-9000)是个经验阈值，因为正常气温不会低于这个值，填充值通常远小于它。用copyProperties保留时间属性很重要，否则后续按时间排序或筛选会丢失时间信息。这个细节我在早期经常忘，导致导出的文件没有时间戳，后期只能靠文件名猜日期。

3.3 单位与数据类型的确认

不同数据集的温度单位可能不同，有的用摄氏度，有的用开尔文。DAYMET是摄氏度，ERA5默认是开尔文，用之前要减273.15转换。导出前确认单位，避免后期发现数值差273而返工。数据类型上，Float32足够表示温度精度，用Float32能减小文件体积，没必要用Float64。

4. 导出环节的实操细节与常见翻车点

导出是整个流程最容易出问题的地方，任务排队、超时、权限、路径，每个环节都可能卡住。这部分我把踩过的坑和对应解法整理出来。

4.1 Export参数逐项拆解

以Export.image.toDrive为例，关键参数逐个说：

Export.image.toDrive({ image: imageToExport, description: 'daymet_2000', fileNamePrefix: 'daymet_tmax_tmin_2000', region: roi, scale: 1000, crs: 'EPSG:4326', maxPixels: 1e13, fileFormat: 'GeoTIFF' });

scale要和数据集原生分辨率匹配，DAYMET是1000米，写1000；如果写小了会重采样放大文件，写大了会丢失细节。crs选EPSG:4326是通用经纬度，如果研究需要投影坐标可以换，但要和后续分析保持一致。maxPixels默认值较小，大区域导出容易报"Too many pixels"，设成1e13基本能覆盖大多数场景。region一定要传，否则导出整幅全球影像，文件大到无法处理。

4.2 任务并发与批量提交的节奏控制

GEE对同时运行的任务数有限制，一次性提交几百个任务，大部分会处于READY状态排队。我的做法是分批提交，比如一次提交20-30个，等这批跑得差不多了再提交下一批。虽然手动分批麻烦，但比一次性堆几千个任务然后干等要可控。如果会用Python的ee API，可以写脚本监控任务状态，自动补提交失败的，这个进阶玩法后面可以单独展开。

还有个现实问题：免费账户的导出配额有限，日数据量大时可能触发限制。这时候要么分多天导，要么考虑用Export.table导出采样点数据而不是全栅格，取决于你的分析是否需要完整栅格。

4.3 导出后文件的校验方法

文件下下来不能直接用，先做几项校验：像元数量是否和研究区匹配、数值范围是否合理（温度大致在-50到50摄氏度之间）、时间戳是否正确、有没有大面积NoData。我一般用Python快速读一景看看：

import rasterio with rasterio.open('daymet_tmax_tmin_2000_001.tif') as src: data = src.read() print(data.shape, data.min(), data.max())

如果min出现-9999之类的值，说明缺失值没处理干净；如果max异常大，可能是单位没转换。这几步校验花不了几分钟，但能避免后面用错数据做分析。

5. 从GEE到本地的完整链路：文件组织与后续衔接

导出的文件最终要落到本地或者云盘，怎么组织直接影响后续使用效率。这部分讲讲文件命名、目录结构和常见后续处理。

5.1 目录结构与命名规范

我习惯按数据集/变量/年份三级目录组织，比如daymet/tmax_tmin/2000/下面放该年所有日文件。文件名统一为daymet_tmax_tmin_YYYYMMDD.tif，这样按文件名排序就是时间顺序，用glob或者os.listdir读进来天然有序。如果GEE导出的文件名不带日期（逐景导出时默认带序号），后期要重命名，可以用Python批量改。

5.2 长时序文件的合并思路

8800个日文件逐个读效率低，实际分析时通常要合并。两种思路：一是用xarray的open_mfdataset按时间维度合并，适合做时间序列分析；二是用GDAL的VRT或者gdal_merge做空间拼接，适合做区域统计。合并前注意检查各文件的CRS、分辨率、范围是否一致，不一致要先统一，否则合并会出错。

5.3 常见后续分析场景的衔接

拿到日最高最低温后，常见用途包括：算日均温（(tmax+tmin)/2）、算积温（逐日累加超过某阈值的部分）、算极端高温天数（tmax超过阈值的日数）、做生长季分析等。这些都可以在合并后的数据集上直接算。如果数据量大，建议用分块处理或者Dask并行，避免内存爆掉。

6. 几个容易忽略但影响很大的细节

最后集中说几个我在实操中反复遇到、但文档里很少提的点。

6.1 时区与日期边界

GEE的日期筛选基于UTC，而气象数据的"日"定义可能基于当地时区。跨时区研究时，日期边界可能差一天。DAYMET等产品一般有明确的日期定义，用之前查一下产品说明。如果做精细的日尺度分析，这个差异不能忽略。

6.2 闰年与天数校验

2000到2023年里有6个闰年（2000、2004、2008、2012、2016、2020），闰年366天，平年365天。导出后按年统计文件数，闰年应该是366，平年365，对不上就说明有缺失。这个校验很简单但很有效，我每次导完都会跑一遍。

6.3 研究区边界与像元对齐

如果研究区是不规则多边形，导出时region传多边形，GEE会导出覆盖该多边形的矩形范围，多边形外的像元是NoData。后续分析时要用多边形mask掉外部像元，否则统计会把NoData算进去。这个坑我在做行政区统计时踩过，面积算出来偏大，排查才发现是边界外像元没排除。

6.4 数据版本与更新

GEE上的数据集会更新版本，比如DAYMET有V4等不同版本，变量名和覆盖范围可能有差异。用之前确认当前版本，代码里写死数据集ID时注意版本号。如果长期项目，建议记录使用的数据集版本，方便复现。

整体走下来，这套流程的核心不是代码多复杂，而是每个环节的细节把控：数据集选对、时间切分合理、缺失值处理干净、导出参数配好、文件校验到位。日尺度长时序导出是个体力活加细心活，代码骨架搭好后，剩下的就是耐心跑任务和逐项校验。我自己的习惯是先小范围试跑一年，确认全链路通了再批量铺开，这样即使有问题也能早发现，不至于几千个任务跑完才发现参数错了要重来。