企业官网建设流程全解析

如果你经常用 GEE（Google Earth Engine）做时间序列或者大范围的数据导出，一定经历过这种时刻：好不容易把代码跑通，结果右侧 Tasks 列表里一下多出几十个待运行任务，然后你像点菜一样一个一个点 Run。我最早批量导一个 20 年的逐月数据时，足足点了两百多下，点完感觉手腕都不是自己的了。后来我想通了一件事——这些点击完全可以交给代码自动完成，而且 GEE 本来就把这个口子留给了你。

这篇博文就专门讲“GEE 自动下载多个任务”这件事：怎么做、为什么这样做、有哪些坑。适合被批量导出折磨过的人，也适合刚接触 GEE、还没被 Tasks 列表吓到的新手。读完你应该能直接复制脚本，解决“导出上百个任务却不想手动点 Run”的问题。

1. 先说清楚：这个自动下载脚本到底解决什么问题

1.1 手动点 Run 的日常痛点

GEE 里最常见的批量导出场景有这么几类：按年份导出影像集合、按季节或月份导出时间序列、把一块大区域切成多个块分别导出、或者同一批影像用不同坡度、不同合成方式导出多份结果。这类需求一旦进入“批量”二字，任务数量很容易就冲到几十上百个。

问题在于，很多人写完代码运行之后，发现导出任务确实创建了，但全都处在待命状态。你要让它们真正跑起来，就得在浏览器里一个一个点 Run。如果任务是逐行滚动的还好，要是任务列表有一百行，这种重复劳动就很消磨耐心了。更麻烦的是，导出任务执行期间你还不能随便关页面、不能反复刷新，因为很多时候你是在靠浏览器那个页面在维持任务列表的可见状态。

还有一个隐性成本：人总会漏点。任务一多，点着点着就不知道哪些是已经启动的，哪些还没有。漏掉一两个还问题不大，漏掉十几个，等你发现时可能已经过了好几个小时，时间成本就这样白白浪费了。

1.2 自动化能处理到什么程度

这类自动下载脚本能做的事情，概括起来是三件：

• 批量启动：把创建好的多个 READY 状态任务一次性全部启动，替代人工逐条点击。
• 分批控制：避免一次性把几十个任务全部推上去，控制并发节奏，降低失败率。
• 状态管理：帮你检查当前任务列表里哪些还在排队、哪些已经失败，方便快速定位问题。

但它不能做的，你也别指望：它不能突破 GEE 账号本身的并发限制，不能修复数据源里缺失影像的问题，也不能让你在完全不懂遥感数据的情况下凭空导出正确结果。说白了，自动化解决的是“重复操作”和“流程管理”，解决不了“数据本身有问题”。

如果你平时只是偶尔导几个影像，那手动点 Run 完全够用。但如果你经常做时间序列分析、批量制图、迁移训练样本这类工作，这套自动化逻辑值得花十分钟掌握。

2. 任务机制先拆清楚：理解了才能放心批量启动

2.1 一个任务从创建到完成经历什么状态

这里有一个特别多人踩的认知误区：以为执行了Export.image.toDrive(...)这行代码，任务就开始下载了。实际上不是这样。

GEE 的任务状态大致可以分成几个阶段：

关键就在 READY 这一步。Export.image.toDrive(...)只是把任务提交到任务队列，相当于你在打印机上放好了纸、设置好了打印参数，但还没按下那个“开始”按钮。你要做的启动动作，就是任务列表里的 Run 按钮。而如果你想用代码代替手指，就得调用任务对象上的start()方法。

理解了这一点，你再回头看到“为什么我代码运行了但任务不动”这类问题，基本就能自己判断：多半是少了start()。

2.2 为什么必须用客户端 for 循环创建任务

还有一个高频误区是：尝试用ee.List.sequence(...).map(...)这种服务端循环来批量创建导出任务。这个做法看起来优雅，实际上会失效。

原因很简单：Export.image.toDrive(...)返回的是一个 Task 对象，这个对象存在于客户端环境，是你浏览器里那个页面的一部分。而map()是在服务器端分布式执行的回调，它没有能力创建一个你能在客户端访问的 Task 对象，更不可能调用start()。

所以批量导出脚本的标准姿势，是在客户端用普通的 JavaScriptfor循环，一个任务一个任务地创建，把返回的 Task 对象收进数组，然后再统一对它们调用start()。

这个过程听起来简单，但它是整个自动下载方案能成立的基础。后面所有代码都是围绕这个核心逻辑展开的。

3. 可直接复制使用的批量下载与自动启动代码

3.1 边创建边启动：最稳妥的批量导出姿势

先给出我最常用的一种写法：边创建任务、边收集任务对象，最后统一启动。以“逐年导出 MODIS NDVI 数据”为例：

// 1. 定义研究区，这里用你画好的 geometry 或某个矢量集合的几何 var roi = ee.FeatureCollection('你的数据集').geometry(); // 2. 用于收集所有任务的数组 var tasks = []; // 3. 客户端循环，逐年创建导出任务 for (var y = 2000; y <= 2023; y++) { var ndvi = ee.ImageCollection('MODIS/061/MOD13Q1') .filterBounds(roi) .filterDate(ee.Date.fromYMD(y, 1, 1), ee.Date.fromYMD(y, 12, 31)) .select('NDVI') .max(); var task = Export.image.toDrive({ image: ndvi, description: 'MODIS_NDVI_' + y, folder: 'ndvi_yearly', fileNamePrefix: 'NDVI_' + y, scale: 250, region: roi, maxPixels: 1e13, fileFormat: 'GeoTIFF' }); tasks.push(task); } // 4. 循环结束后，一次性启动所有任务 tasks.forEach(function(t) { t.start(); });

这段代码的运行逻辑很简单：逐年生成一个当年的 NDVI 最大合成影像，把它加入导出队列，收集所有任务句柄，然后在循环外面统一执行start()。

我想强调两个细节。

第一，description和fileNamePrefix一定要带年份之类的唯一标识。之前有人把五十多期影像全部命名为NDVI_export，结果文件全部互相覆盖，等于白导。

第二，maxPixels要记得设大。MODIS 虽然分辨率不高，但如果研究区很大，像素总量很容易超过 GEE 默认的1e8上限。这里设1e13，是给大数据量导出预留空间。具体设多大，取决于你的区域大小和研究目的，别一上来就无脑设1e13，能设合理值最好，实在不放心再放宽。

这种“边创建边启动”的方式最稳定，因为你直接操作的是当前代码运行时创建出来的 Task 对象，不存在版本接口差异问题。新手建议先跑通这一版。

3.2 列表里已有 READY 任务的一键批量启动

另一种更常见的需求是：代码已经运行过了，Tasks 列表里躺着几十个 READY 任务，但我当时没写start()，现在不想重新提交一遍，想直接让它们跑起来。这时候就不能用任务对象了，得通过任务列表接口来处理。

// 1. 获取当前账号下的全部任务 var allTasks = ee.data.getTaskList(); // 2. 过滤出 READY 状态的任务，逐个启动 var startedCount = 0; for (var i = 0; i < allTasks.length; i++) { var t = allTasks[i]; if (t.state === 'READY') { // 不同GEE客户端版本中，该接口命名可能略有差异， // 常见的是 manageTask / startProcessing，思路完全一样。 ee.data.manageTask(t.id, 'start'); startedCount++; } } print('已启动任务数：' + startedCount);

这段脚本的价值在于：你不需要重新跑一遍完整的导出代码，只需针对现有任务列表做一次批量操作，非常适合“任务已经建好但人已经离开电脑前”或者“上次忘了启动、现在想补救”的场景。

需要提醒的是，ee.data.getTaskList()返回的是你当前账号下的任务列表，每个任务对象里会有id、state、description等字段，你可以根据需要增加过滤条件。比如只启动名称里包含某个关键字的任务，或者排除已经失败的任务。这个小细节在任务特别多时会很有用。

3.3 控制节奏：分批启动十多个任务最保险

一次性把所有 READY 任务全部启动，看起来效率最高，但实际跑起来容易出问题。GEE 对不同账号类型都有并发运行数量的限制，虽然具体的数字会随平台策略变化，但一次性提交太多任务很容易导致一部分任务被拒绝执行，甚至直接消失。

我的建议是：每批控制在 5 到 10 个，启动完一批之后观察一下，确认状态没有异常，再启动下一批。

如果你想用代码实现“分批启动”，可以这样写：

var allTasks = ee.data.getTaskList(); var batchSize = 5; var startedCount = 0; for (var i = 0; i < allTasks.length; i++) { if (startedCount >= batchSize) { break; } var t = allTasks[i]; if (t.state === 'READY') { ee.data.manageTask(t.id, 'start'); startedCount++; } } print('本批已启动任务数：' + startedCount);

运行一次启动 5 个，隔一段时间再运行一次，相当于人为控制任务积压的速度。虽然听起来不如“一键全启”痛快，但实际操作下来反而更靠谱。我宁可多花几分钟分几个批次，也不愿意一次把几十个任务全部推上去，然后眼睁睁看其中几个失败。

4. 实测中遇到的高频报错与排查方法

4.1 任务一直停在 READY 不执行

这个问题在论坛里被问过无数次：代码跑完了，任务状态始终是 READY，等了半小时也没见它开始跑。原因十有八九就是少了start()。

我见过有人把Export.image.toDrive(...)写在全局代码里，Run 完一整段脚本，然后盯着任务列表发呆；也见过有人把start()写在循环里，但因为循环条件写错，根本没执行到。

排查步骤其实很简单：

1. 先确认导出代码是否执行成功，有没有报错。
2. 再确认是否调用了task.start()，或者手动点击过 Run。
3. 如果两者都没有，任务当然不会跑。

还有一种情况是：任务确实启动了，但一直停留在 RUNNING 状态很久。这个不属于“不执行”，是 GEE 本身需要排队等待计算资源，尤其是大区域高分辨率导出，排队几小时都不奇怪。这种时候不需要反复提交新任务，越提交越拥堵。

4.2 影像太大超过像素限制

GEE 导出时会检查你的影像总像素量，超过限制就会报错，常见错误信息类似“Image too large”或“Computed image too large”。这类错误通常发生在区域大、分辨率又高的情况下。

解决办法主要有两个方向：

• 调大maxPixels，比如设成1e13，给足余量。
• 把大区域拆成多个小块，分别导出，最后在本地拼接。

这两种方案各有适用场景。如果只是为了快速拿到数据，调大maxPixels更省事；如果是特别大的区域、需要极高分辨率，拆分导出其实是更明智的做法。而拆分导出恰恰又是一个非常适合自动化的场景——几十个分块，每个分块一个任务，批量创建批量启动。

4.3 文件名重复导致数据被覆盖

这个问题很隐蔽，因为 GEE 任务本身不会报错，看起来状态也是 COMPLETED，但你打开网盘一看，文件数量对不上，有些周期的数据被同名文件覆盖了。

原因就是你给不同任务设置了相同的fileNamePrefix。当你把所有导出都命名为export_result或NDVI_data的时候，后完成的任务会直接覆盖先完成的任务。

我的建议是养成固定的命名习惯，比如数据集_区域_时间_类型：

• MODIS_NDVI_2000_max
• MODIS_NDVI_2001_max
• MODIS_NDVI_2002_max

这样既不会冲突，后续下载下来整理数据也方便。批量任务数量越大，命名规整带来的收益就越明显。

4.4 并发提交任务过多被限流

有时候你一口气把所有 READY 任务全部启动，结果过了一会儿发现，一部分任务直接从列表里消失，或者状态变成了 FAILED，错误信息指向资源限制或配额问题。

这就是典型的“一次提交太多”被平台限流了。我在前面已经提过分批启动的思路，这里再补一句：如果发现任务批量失败，先不要急着反复重新提交同一批任务，停下来观察一段时间，确认当前账号下正在运行的任务数量，等几个任务结束再补提交。

5. 让整套流程更省心的几个补充细节

5.1 任务的命名规划要提前想好

这部分虽然不写代码，但我认为它比任何一段代码都重要。

批量导出脚本一旦跑起来，任务列表里的状态你是没法一个个细看的。这时候“一眼能识别任务是什么”就变得特别关键。命名建议包含四个信息：数据集、区域、时间、类型。比如：

• Landsat_NDWI_shanghai_2020_dry
• Landsat_NDWI_shanghai_2020_wet
• Landsat_NDWI_shanghai_2021_dry

这样即便任务失败了，你也能立刻判断是哪一个环节的问题，不会在一个名为Export (1)的任务面前发呆。

5.2 用 Python 接口做同样的批量管理

如果你更喜欢在 Python 环境里跑 GEE，思路完全一样，只是写法略有不同。

import ee ee.Initialize() # 创建批量导出任务 tasks = [] for year in range(2000, 2024): ndvi = ( ee.ImageCollection("MODIS/061/MOD13Q1") .filterBounds(roi) .filterDate(f"{year}-01-01", f"{year}-12-31") .select("NDVI") .max() ) task = ee.batch.Export.image.toDrive( image=ndvi, description=f"MODIS_NDVI_{year}", folder="ndvi_yearly", fileNamePrefix=f"NDVI_{year}", scale=250, region=roi, maxPixels=1e13, fileFormat="GeoTIFF", ) task.start() tasks.append(task)

Python 版本的好处是可以很方便地整合进你自己的数据处理流程里，比如先判断前一批任务是否全部完成、再提交下一批，配合定时任务可以做到完全无人值守。缺点是需要额外维护 Python 环境，初学者如果只是为了开几个导出任务，先用 JavaScript 版就够了。

5.3 顺手写一个状态检查函数

批量任务启动之后，你是不是还得定期打开页面看状态？其实可以写个小函数，把这些事情交给控制台：

function checkTasks(keyword) { var tasks = ee.data.getTaskList(); var states = { READY: 0, RUNNING: 0, COMPLETED: 0, FAILED: 0, CANCELLED: 0 }; tasks.forEach(function(t) { if (keyword && t.description.indexOf(keyword) === -1) return; states[t.state] = (states[t.state] || 0) + 1; }); print(states); } // 用法：只统计 NDVI 相关任务 checkTasks('NDVI');

这个函数会统计任务列表中各个状态的数量。你可以把它和批量启动脚本放在同一个编辑器里，随时运行，随时掌握全局。虽然 GEE 的 Tasks 标签页本身也能看，但数据多的时候还是代码来得直观。

这套脚本在我自己的批次导出任务里用得很顺手。最后再分享一个亲测有效的习惯：凡是批量导出，我第一步永远是确定命名规范，第二步才是写导出循环，第三步才会考虑要不要加start()。顺序反了，后面总有你难受的时候。GEE 的批量下载自动化并不需要多复杂的算法，它就是一件“把重复动作交给代码”的小事，但能把这件事做踏实了，省下来的时间可一点都不少。