你打开 Google Earth Engine 代码编辑器，右上角或者 Cloud Console 的配额页面多半已经挂了一条提醒：非商业版正式引入计算配额制度，分区申请需要在 4 月 27 日前完成。第一眼看到时我以为是普通的产品更新，仔细读完才发现这次是动真格的——以前是“注册就能跑，跑到顶再说”，现在是“先申请配额、再按档运行”，整个使用节奏都得跟着调整。
这篇文章把我自己调研、实测、跟几位做遥感项目的开发者讨论下来的结论整理一遍。内容包括：这次配额制度到底改了哪些底层逻辑、分级档位怎么选、4 月 27 日前必须完成的申请动作、配额下来之后工作流要怎么改，以及我踩过的一轮坑。无论你是学生、科研人员，还是偶尔用 GEE 做点数据可视化的开发者，这篇文章都能帮你少走弯路。
1. 配额制的底层逻辑变了：从“抢位置”变成“按月分工位”
1.1 过去 GEE 怎么分配算力，现在改成什么
Google Earth Engine 的实际算力分配，一直有一套后台机制在管。早期开发者注册之后，基本是共享一个大池子：你提交一个任务，系统根据当前集群负载、任务优先级和资源余量动态调度。高峰期任务排队，低峰期几乎秒跑，大家感知到的只是一个“够用但不保证”的资源池。
这次非商业版的调整，相当于把这个隐形的共享池改成显性的分级配额。每个账号、每个云项目会有对应的容量档位，按月度计算额度划给你。你在代码编辑器里跑分析、跑Export、反复getInfo，都会计入这个额度的消耗。超出部分要么排队等待，要么需要申请更高档位，不再是无感动态抢占。
用个生活类比：以前 GEE 是个公共自习室，谁能占到座位谁就学，高峰期全靠抢，延迟高低看运气。现在改成预约制工位，按月给你分配固定的使用时长和桌面，你要在这个额度内安排自己的学习计划。好处是可预期，坏处是，过去那种“随便戳一戳、反正不要钱”的随意感没有了。
1.2 这次非商业版调整真正影响到的三类人
第一类是个人学习和 Demo 玩家。没事跑个 NDVI、画个年度水体变化图，单次计算量不大，总体配额消耗很低，这类用户受冲击最小，基本感知不到变化。
第二类是科研人员和高校课题组。他们往往要跑整个省甚至全国的时序影像，一跑就是几百上千景；批量导出预处理产品、逐年的时间序列分析、多源数据融合，这类工作负载直接面对配额上限。不夸张地说，几个大任务如果放同一天跑，很容易把月度容量吃掉很大一块。
第三类是给企业做遥感咨询、数据产品交付的开发者。严格来说这些人已经不算典型的“非商业版”用户，因为你把结果卖给了客户，使用目的已经超出非商业条款。GEE 这次把非商业和商业边界重新强调，等于逼着这部分人重新评估自己的项目归属。别心存侥幸，我认识的同行里已经有人的商业项目在迁移到商业条款后才恢复正常配额。
这次调整最需要留意的不是“限制变多了”，而是“资源分配模型变了”：过去你不需要预估自己一个月要跑多少，现在申请的时候就要说清楚。那些习惯粗放使用的人，接下来会明显难受。
2. 分级配额的四档怎么选：拿你的典型任务对号入座
2.1 四档容量对应什么任务体量
官方配额申请页面会列出几个档位，不同地区和账号状态看到的名称、容量可能有差异，但大致会覆盖下面四种量级：
- 轻量档：适合教学演示、小型区域单期影像分类、偶尔导出几景 Landsat 或 Sentinel-2 图。典型用户是本科生课程作业、兴趣开发者。
- 科研档：适合省级/洲级尺度的年度时序分析、定期更新植被指数、每月的批量影像导出。典型用户是高校课题组、非营利研究机构。
- 高容量档：适合全国尺度拼接、多源遥感数据（Landsat + Sentinel + 气象再分析）的融合处理、每天运行大量导出任务的团队。
- 定制档：适合数据服务商、商业级产品研发，往往对应商业条款，配额和计费方式单独谈。
注意，这里说的“档位”是参考定位，不是替官方下结论。你在申请页面上会看到明确的每月计算容量数值（通常以 Earth Engine Units，也就是 EEU 为计量单位），不同档位的配额量级可能从三位数到四位数不等。不要只盯数字，要拿数字倒推你的任务负载，匹配度才是核心。
2.2 选档决策表：三种典型任务怎么落位
我把自己的实测经验和常见工作任务整理成下面的对照表，你直接对号入座：
| 典型工作负载 | 建议档位 | 理由 |
|---|---|---|
| 偶尔看影像、画一个区域的分类图、课程作业 | 轻量档 | 单次计算量小，总配额消耗低，完全够用 |
| 每月分析一两个省的 NDVI 时序、定期导出几十景影像 | 科研档 | 需要一定的并发余量，但不需要全国级吞吐 |
| 全国尺度的土地覆盖分类、时序变化检测、多数据源融合 | 高容量档 | 任务量大，且长尾导出对容量消耗明显 |
| 面向 B 端客户的影像服务、规模化数据交付 | 定制档/商业条款 | 非商业版按条款本来就覆盖不了这种用途 |
2.3 选大档的隐性成本
很多人第一反应是“我要选最大的档，免得以后不够用”。我劝你先冷静。选大档的确能在短时间内给你更多容量，但随之而来的问题是：审批关注度更高，可能被要求补充更多用途说明；如果关联的是商业项目，可能直接触发商业计费条款；还有，你真拿高容量跑轻量任务，等于浪费自己的审批信用。
更合理的思路：先按你过去 30 天的真实用量估算，取 1.5 到 2 倍作为缓冲，然后申报对应档位。等跑一两个月，后台数据会让你对准确用量有更清楚的认识，再考虑要不要升级。
3. 4 月 27 日前按顺序做完这四件事，申请不会翻车
3.1 第一步：确认身份，你是个人学习还是机构科研
申请配额前，先想清楚你当前使用 GEE 的目的是什么。个人学习用途，走非商业免费申请流程；高校科研、非营利组织，也要明确是“非商业研究”，且不能把结果直接变成商业收入。这个身份判断不只影响你填表，还会影响后续条款合规。
我有一个很实际的建议：先把你自己最典型的两个工作负载写下来，例如“每月用 Landsat 8 做某保护区植被覆盖度评估，导出 20 景影像”或“每周用 Sentinel-2 做城市不透水面变化监测”。写下来之后，你后面填申请时会顺畅很多，因为很多字段你直接抄自己写的就行。
3.2 第二步：在 GEE 和 Cloud Console 里完成项目绑定
现在 GEE 使用 Cloud 项目作为资源归属单位。你需要在代码编辑器右上角查看当前关联的云项目，如果没有，创建一个空的 Cloud Project，不产生费用，但要保证它启用 Earth Engine API。
然后进入 Cloud Console，在配额页面搜索 Earth Engine 相关配额，查看你当前项目的配额设置。这一步经常卡住的点在于：你的 GEE 账号和 Cloud 项目不在同一个组织下，或者项目权限不够。我踩过的坑是，用个人号给一个非管理员项目申请，页面直接提示无权限，换项目管理员身份才正常显示申请入口。
3.3 第三步：把申请单当立项书来写
分级申请里最花时间的不是点按钮，而是用途描述。我见过太多人只填一句“used for research”，这种申请被退回或者被延迟审批的概率很高。你要把下面几项写清楚：
- 具体研究/工作背景：是哪个领域、哪个区域的研究，为什么需要 GEE；
- 主要数据集：Landsat、Sentinel-2、MOD13Q1 等，数据量大就如实写；
- 处理流程：例如“对 2015—2025 年逐月影像做时序分解，计算突变点”；
- 预估月消耗：例如“每月导出 200GB 预处理数据，运行 30—50 个批处理任务”。
申请提交流程走完后，官方会给你一个处理单号，通常在几天内给出结果。我见过最快一小时通过的，也见过两周才批下来的。临近截止日，大家都在赶着提交，审批速度可能会变慢，所以不要拖到最后两天。
3.4 第四步：备份资产与脚本，给最重的任务挪个窝
申请期间你不能保证配额立即生效，所以不要把关键任务压在配额审批上。要把当前用得最勤的脚本复制一份到本地或 GitHub；把常用的 FeatureCollection、训练样本等 Asset 导出备份，避免云项目变更导致数据访问断档；如果已经预估到某个大任务跑不动，可以先把它拆成小区域，等配额确认后再恢复完整运行。
这一步的意义是防止“等待期手痒嘴急”：你申请一提交，旧的不限流模式随时可能切换，中间哪怕有一天配额没生效，你的批处理任务也可能大面积失败。备份是廉价的保险，别省。
4. 配额下来后，我的导出与调度流程改了这三处
4.1 从“一次全跑”改成“分块排队”
过去我导出全国尺度的产品，习惯一次性把几百个 Task 全部提交，让后端自己排队。配额时代这个做法非常危险：大批 Task 并发启动，会在短时间内消耗大量容量额度，一旦中间有 Task 因超时或数据问题失败，你等于白烧了那段计算量。
现在我的做法是：把全国范围按省或按经纬度格网拆分，每次同时提交 5 到 10 个导出任务，完成一批再放下一批。实测下来，总耗时不一定变长，因为任务失败率显著下降，重跑成本也低得多。你可以在代码里做一个简单的任务队列控制：循环提交 Task 前，先查询已有任务的state，等完成数量降下来再补充新任务。
4.2 导出路径从 Drive 改成云端对象存储再拉回本地
以前导出到 Google Drive 很方便，现在我开始优先用对象存储。原因很简单：对象存储更适合大批量文件，而且能用标准工具批量拉取到本地，不依赖 Drive 的容量限制。流程变成：Export.image.toCloudStorage把影像写到存储桶，然后在本地用gsutil同步，或者写一个简单的同步脚本定时拉取。
这个改法对配额消耗也有好处：同样的计算量，导出到对象存储比 Drive 更稳定，失败后的重试成本更低，不会因为存储错误反复重算。如果你只用少量数据，继续 Drive 问题不大，但涉及几十上百个文件时，对象存储真的省心很多。
4.3 把轻量统计从云端getInfo挪到本地 Python
很多开发者习惯在代码编辑器里跑一句image.reduceRegion(...).getInfo()，立刻拿均值、面积等统计结果。这种交互式用法很方便，但也会产生真实计算消耗。配额制度下我养成了另一个习惯：轻量统计尽量在本地做。
具体来说，先用geemap或xarray在 Python 环境读取影像数据子集，再用本地的 pandas、numpy 做统计。只有必须用 GEE 全分辨率算的时候，我才回到云端。这样做的收益非常明显：本地循环不占 GEE 配额，还能用上更灵活的数据处理库。哪怕你只减少一半的无谓getInfo，一个月的额度消耗都能明显降下来。
5. 配额时代最容易踩的坑：我已经替你踩过一轮
5.1 项目没绑定云服务，申请直接卡住
第一次提交配额申请，我卡在“No eligible Cloud Project”这个提示上。原因是我在 GEE 代码编辑器里的账号，没有在 Cloud Console 里创建或绑定项目。这个绑定不是可选项，是硬前置。解决办法：先创建 Cloud 项目，启用 Earth Engine API，然后在 GEE 里把“当前项目”切换过去。整个过程不涉及付费，但要用有权限的账号操作。
如果你有多个项目，确定哪个是你 GEE 脚本实际跑的项目。配额是挂在项目上的，不是挂在个人账号上的。很多人申请完才发现，自己脚本跑在 A 项目，配额却申请在 B 项目，白忙一场。
5.2 大批并发导出任务失败，配额照样被扣
这是最让我肉疼的坑。之前跑一个全国拼接任务，一次性提交 80 个 Export，其中十几个因内存溢出失败。事后看配额明细，失败任务同样消耗了计算额度。我的经验是：宁可把任务拆得更细，也不要盲目并发。一个任务失败后，它的中间消耗是沉没成本；小任务重跑便宜，大任务重跑痛。
另外注意bestEffort: true这个参数。它听起来像是“尽力而为”，实际效果是放宽像素限制、可能选用更高缩放级别，计算量可能翻倍。用在局部小区域无所谓，用在大型导出任务上，配额烧得飞快。我现在的原则是：大任务显式设置maxPixels和scale，不用bestEffort。
5.3 循环里反复getInfo，额度烧得最快
有段时间我写了一个循环：遍历 12 个月的影像，每个月都调用getInfo拿面积，最后拼成趋势表。这个代码逻辑没错，但配额制度下效率极低，每次getInfo都是一次完整的计算往返。12 次循环，吃掉的计算量可以跑完一整景分类图。
解决办法有两个：把统计逻辑放进一个map式的聚合里，或者直接导出一个小的属性表，让 GEE 直接返回结构化结果。如果只是交互式看看，用evaluate回调也比getInfo更合理，至少不会阻塞整个线程。这个习惯改过来，配额消耗能低 30% 以上。
5.4 公共数据集重复计算十遍
另一个隐蔽的浪费：同一个公共数据集，每次用临时影像重新加载并计算，哪怕结果完全一样。比如你反复计算同一个区域的月度降水累计，每次从原始 Climate 数据开始算，配额就等于白烧。
正确做法：把中间产品保存为 Asset。像“预处理后的 NDVI 时序”“掩膜后的水体产品”，这类会被反复引用的结果，跑一次导出成 Asset，后续任务直接引用。前期多花一次导出时间，长期省的是成倍的重复计算量。这条规则在配额制度之前只是“建议”，现在已经是“刚需”了。
6. 最后说点个人经验：申请单写得像样，比等配额更快
6.1 别一上来就申高容量
在配额申请这件事上，我见过太多人想一步到位，结果提交后迟迟没有回音。后来我总结经验：第一档申请你去写“我就跑个实验”，审批看重的是真实用途；高容量申请对应的是高使用预期，材料不够扎实很容易被搁置。与其申高档迟迟不批，不如先按实际用量申一个中等档位，跑顺了再续。
6.2 给 4 月 27 日之后的次日留点缓冲
截止日期压着大家的心，但我建议你在 4 月 27 日前就把系统切到配额状态，不要等到最后一刻。这样如果申请被退回或需要补材料，你还有两三天时间补救。另外配额生效的初期，后台数据可能和你预估的不一致，留出缓冲期来校准自己的任务容量预估，远比当天临时抱佛脚强。
6.3 一个可以长期受益的工作习惯
最后分享一个我在配额制度后养成的习惯：每周末花五分钟，看一眼后台的当月容量消耗和任务成功/失败比例。如果发现失败率高，就再拆细任务；如果某个月的容量快见底，就主动把不紧急的批量任务挪到下个月。这件事听起来很简单，但大多数开发者真的不会去做。配额制度不是要限制谁，而是逼着我们重新理解“算力是一种资源”这个事实——早一点掌握它的节奏，后续就能少很多被动。
