ArcGIS Pro水文分析报错999999？并行处理因子设为0一招解决

做水文分析的同行应该都有过这种经历：手里的DEM明明处理得好好的，填洼、流向、流量一环扣一环，眼看就要出河网了，结果ArcGIS Pro里的工具跑了几秒钟，弹出一个红色报错——999999或者010067，任务直接翻车。更气人的是，同一个数据、同一条流程，换台电脑跑就是好的，换回自己这台就挂。如果你也遇到过这种“玄学失败”，先别急着怀疑数据，十有八九是并行处理因子在捣鬼。这篇文章就把这个坑彻底讲透，从原理到操作，再到排查流程，一次说清。

我最早被这个问题绊倒，是在某次帮一个项目组处理山区小流域的河网提取。当时数据量不算特别大，几百万像元的DEM，按理说ArcGIS Pro跑起来应该毫无压力。但奇怪的是，“填洼”工具跑完没问题，“流向”工具一执行就报错，而且错误代码每次都不同，有时候是999999，有时候是010067，连输出路径都弹不出来。折腾了大半天，最后在一位老前辈的提醒下，把“并行处理因子”改成0，问题瞬间消失。后来我才意识到，这玩意儿在ArcGIS Pro 3.x里，尤其是水文分析这组工具里，翻车率比想象中高得多。

这篇文章适合谁看？凡是需要在ArcGIS Pro里做水文分析、流域划分、河网提取的从业者和学生，只要你用的是Pro 2.5以后的版本，都可能撞上这个坑。文章会把并行处理因子的原理、三种设置路径、以及配套的数据预处理和环境参数全部拆开讲，争取让你下次再遇到水文操作失败，十分钟内就能定位问题。

1. 先对号入座：你的失败是不是这一种

1.1 症状表现

并行处理因子导致的水文操作失败，症状非常有辨识度。最典型的是：工具启动后，进度条动了几下，然后毫无征兆地变红，报错信息里经常带“ERROR 999999”或“ERROR 010067”，有时候还夹杂着“无法创建输出”“无法写入栅格数据集”“进程已停止”之类的描述。

有个容易被忽视的细节是，这种失败往往出现在“流向”和“流量”这两个工具上，而“填洼”反而很少翻车。我见过不少人在网上提问，说填洼跑完了，流向老是失败，甚至有人怀疑是DEM数据本身的问题，重新投影、裁剪、修复栅格折腾一圈，依然无解。如果你也是这种“前面的工具正常，后面的工具连续失败”的节奏，多半和并行计算有关。

另外一个典型特征是失败不稳定。同一个流程，今天跑挂，明天又能跑通；或者小范围数据没事，换成全流域的大范围就挂；又或者同样数据在另一台电脑上没问题。这种“随机性”“环境相关性”的表现，说明问题大概率不在数据本身，而在于运行环境的计算调度机制。

1.2 为什么偏偏是水文工具容易中招

ArcGIS Pro里的水文分析工具集，包括填洼、流向、流量、栅格河网矢量化等，这些工具的计算逻辑本身不算特别复杂，但它们有一个共同点：栅格运算过程中需要频繁访问邻域像元，并且存在严格的迭代依赖关系。

拿“流向”来说，算法要确定每个像元的最陡下降方向，需要反复比较中心像元与周围八个像元的高程关系，这个过程中会产生大量中间结果和临时随机访问。并行计算因子一旦被设置成高于0的数值，系统会把运算切分成多个块交给不同线程处理。问题就出在这里：水文工具在处理分块边界时，邻域信息的同步很容易出现处理不当，分块衔接处的像元计算就会出错，严重时直接让整个任务崩溃。

我的理解是，水文工具在并行化改造上属于“先天不良”的那一类。ArcGIS Pro逐步推行的并行运算，优先照顾的是栅格分类、插值、条件函数这类可以天然分块的工具，而水文分析这种强迭代强依赖的工具，并行化收益有限，反而更容易踩到线程同步的雷区。

1.3 谁最容易被这个坑绊住

从我自己接触到的案例来看，几类场景特别容易触发问题。第一类是处理高分辨率大范围DEM，比如30米分辨率覆盖整个地级市的DEM数据，像元数量轻松上亿，这种情况系统很容易切分大量计算块，并行冲突的概率直线上升。第二类是机器配置比较好的用户，核心数越多越容易触发，ArcGIS Pro默认会根据CPU核数自动计算并行因子，一个16核的机器可能默认就给到8甚至更高，这反而增加了故障概率。

第三类是使用某些特定栅格存储格式的用户。ArcGIS Pro原生推荐的云栅格格式在并行写操作上存在一些兼容性问题，我之前有几次就是输出格式选成了云栅格格式导致报错，后来改成TIFF就一切正常。如果你属于以上三者之一，这篇文章接下来的内容值得认真读完。

2. 并行处理因子到底是啥，它和水文操作怎么结下的梁子

2.1 工作机制简单说

并行处理因子，英文界面里叫Parallel Processing Factor，是ArcGIS地理处理工具的一个环境参数，用来控制工具允许使用多少个处理器核心来执行计算。它位于“环境设置”选项卡里，常见的可填选项有0、50、100，以及任意百分比或整数。

这里的逻辑并不复杂：0表示不进行并行计算，或者说以最低并行度运行；50表示使用一半的计算资源；100表示全部核心参与，默认值通常就是100。如果你填一个具体的数字，比如4，那就表示让工具只使用4个核心。

有些朋友可能会以为设成0是“让程序只用0个核心”，这其实是误解。更准确地说，0在ArcGIS Pro的这套并行逻辑里代表关闭并行计算调度，让工具用最保守的顺序计算方式执行任务。这个设定在早期版本里效果尤其明显，因为旧版本水文工具本身的并行分支不成熟，关掉之后反而走的是最稳的代码路径。

2.2 水文分析为什么容易触发并行故障

并行计算的大原则是分而治之：把整个栅格按行或按块切碎，分给多个线程分别计算，最后再拼起来。听起来很美好，但水文分析有个硬伤——它的每一步计算都强依赖邻域和上游结果。

拿“流量”工具举例，每个像元的累积流量，等于上游所有汇入它的像元的流量之和。这个计算存在明显的先后依赖：上游没算完，下游就不能开工。如果并行调度把下游的块先派给某个线程处理，而那个线程又拿不到上游的最新结果，计算就会出错，或者需要反复通信等待，线程越多，这种协调成本越高，出错概率也越大。

更要命的是Sink和Flat区域的递归处理，填洼和流向工具里涉及大量迭代修正。当数据里有大面积平坦区域或者错误洼地时，迭代次数会激增，并行计算下的分块边界处特别容易发生数据不同步。我怀疑这也是为什么“流向”工具在高并行度设置下最容易莫名其妙的失败——它正是水文工具中迭代逻辑最重的那一个。

2.3 设0为什么被视为“万能解药”

把并行处理因子设为0，等于强制工具走单线程、顺序处理的旧路径。虽然性能会下降一些，但对于水文分析这种计算量不算特别夸张的任务来说，牺牲一点时间换稳定，完全值得。

尤其是当你处理的数据本身不是TB级别时，并行计算带来的性能提升其实感知不强。我自己实测过，一个千万级像元的DEM跑流向，并行因子100的时候跑挂的概率大约三成；设成0以后虽然耗时多了约四分之一，但连续跑十个流程全都稳稳落地。稳定性优先的原则，在水文分析里永远是对的。

还有一个隐藏好处：设成0之后，ArcGIS Pro不会自动创建额外的临时并行缓存文件，这对磁盘空间紧张的环境也是减压。我之前在某台磁盘只剩几个GB的机器上，就是靠这个参数救回来的。

3. 实操：三招把并行处理因子改成0

3.1 第一招：在工具对话框里临时生效

最直接的办法，就是每次运行水文工具时，在工具对话框右侧展开“环境”选项卡，找到“并行处理”这一项，把“并行处理因子”从默认值改成0。这个操作只对当前这次运行生效，不会影响其他工具和其他流程，非常干净。

需要注意一个小细节：在部分ArcGIS Pro版本里，“并行处理因子”输入框的值默认是空的，显示为“无”，但你点开旁边的下拉箭头，能看到0、50、100等预设值。直接选0就行。如果界面显示的是百分比输入框，输入0再回车，效果一样。

这个方法适合偶尔遇到问题时临时验证，比如你怀疑当前这个报错是不是并行导致的，先用临时方式验证一下，确认有效再去改全局设置，避免盲目改配置影响其他正常工作。

3.2 第二招：在全局地理处理选项里一劳永逸

如果你确定自己的机器跑水文工具经常出问题，那最好直接在ArcGIS Pro的全局设置里把“并行处理因子”默认值改成0。具体路径是：顶部菜单“工程” -> “选项” -> “地理处理” -> “环境”选项卡，往下找到“并行处理”，把因子改为0。

这样设置之后，你后续打开的所有地理处理工具，环境里都会默认带着这个0值，不需要每次手动调，也不用担心忘记设置导致再次翻车。这里我个人的建议是：如果你主要是做水文分析、流域提取这类型的工作，干脆全局保持0也别心疼；如果平时还要跑一些大数据量插值和分类，那再单独给这类工具临时调回50或者100也不迟。

提示：全局修改并行处理因子是“木桶策略”，只影响新开工具默认值，已经在运行的任务不会受影响。改完以后要新开工具对话框才能看到变化。

3.3 第三招：脚本与自动化批处理场景

如果你平时喜欢用Python脚本或者ModelBuilder做水文处理流水线，那设置并行处理因子就得放在代码里或者模型参数里。ArcPy里的写法很标准，通过arcpy.env.parallelProcessingFactor赋值即可：

import arcpy arcpy.env.workspace = r"D:\水文项目\流域提取.gdb" arcpy.env.parallelProcessingFactor = "0" arcpy.env.cellSize = "10" # 填洼 filled_dem = arcpy.sa.Fill("dem_10m") filled_dem.save("fill_dem") # 流向 flow_dir = arcpy.sa.FlowDirection(filled_dem) flow_dir.save("flow_dir")

注意arcpy.env.parallelProcessingFactor赋值的是一个字符串"0"，不是数字0，这个细节容易踩坑。赋值之后，后续调用任何地理处理工具都会按照这个环境值执行，包括arcpy.sa.Fill、arcpy.sa.FlowDirection、arcpy.sa.FlowAccumulation这些水文工具。

用ModelBuilder的朋友也不用愁，在模型环境属性里同样可以设置并行处理因子。打开模型属性，切到“环境”选项卡，勾选并行处理并赋值为0，整个模型里所有工具就都统一了。这个做法适合做标准化的自动处理流程，省得每次改。

3.4 三种方式的对比

为了让你看得更清楚，我把三种方式和适用场景整理成一张表：

三者的优先级也有讲究：工具对话框内的环境设置高于脚本环境，脚本环境又高于全局工程选项。如果你全局设成0，但某个工具对话框里手动填了100，那实际运行还是会按100来执行。所以有时候你明明全局改了0还报错，要么是工具级设置覆盖了，要么是脚本里又赋了新值。

4. 只改并行因子还不够，附赠一套水文操作保平安流程

4.1 数据处理前的姿态：投影、裁剪、修边界

水文分析对数据有一个先决条件：DEM必须是投影坐标系，绝对不能直接用经纬度的地理坐标系去做填洼和流向。原因很简单，流向算法里要计算水平距离和垂直距离的比值来决定最陡下降方向，经纬度坐标下单位不一致，算出来的坡度方向就是错的，后续所有结果都不可信。

我见过不少人跳过投影这一步直接跑流向，工具虽然不报错，但出来的河网支离破碎、流向错乱，还以为是并行问题。正确的做法是先把原始DEM重投影到适合目标区域的投影坐标系，比如常见的UTM或者高斯克吕格投影，然后按研究区范围裁剪，并检查DEM边界上有没有负异常值或者边缘噪点。

裁剪这一步尤其重要。很多时候水文工具失败不是因为算法，而是因为DEM在裁切边界处出现了孤立像元或者NoData区域，导致邻域计算时遇到非法值。所以在填洼之前，先把DEM的NoData区域和边界检查一遍，最好用边界清洗工具把边缘的小块异常像元处理掉。

4.2 填洼和流向的配套环境参数

除了并行处理因子，水文工具组的另一个关键环境参数是“像元大小”。我建议在跑水文流程之前，显式地把环境里的cellSize设为DEM原始分辨率，避免系统自动根据输出范围调整出一个莫名其妙的值。

还有“处理范围”这个参数，如果输出数据和输入数据范围不一致，流向和流量结果很容易在边缘出现大面积NoData。最好把处理范围锁定为DEM数据的实际范围，或者用“与栅格分析相同”选项，确保每次输出都在同一坐标系和边界下对齐。

如果你处理的区域里存在大量平地或者洼地，填洼的“z限制”参数也要留意。填洼有两种模式：一种是填充到最低边界出流点为止，一种是只填充指定深度以内的洼地。在丘陵、平原混合区域，默认的填洼模式可能把大片平原填成“湖面”，影响后续流向的准确性。这个参数虽然不是环境设置，但在失败排查中经常被忽略——因为并行报错把你带偏了，实际上有时候是填洼太狠导致下游计算溢出。

4.3 输出格式与目录的选择

ArcGIS Pro 3.x默认输出栅格格式经常落到云栅格格式，这个格式在并行读写时的稳定性让我踩过两次坑，一次是流量计算输出到云栅格格式直接失败，一次是保存时卡在“正在写入栅格数据集”十几分钟没反应。

后来我的习惯是：水文分析的每一级输出都显式指定文件地理数据库（FileGDB），或者干脆用TIF格式。FileGDB里的栅格在顺序读写时非常稳，极少出现锁和临时文件冲突；TIF则便于后续在别的软件里做进一步分析。如果你坚持要用云栅格格式，至少先把并行处理因子设成0，并且确认磁盘空间充足，不然临时文件爆掉也会报错。

工作目录也别选在同步网盘上。某云端同步目录的坑我印象很深，工具每次运行到一半，同步客户端就开始把临时文件往云端传，锁文件冲突，任务直接被杀。把工程和中间输出放在本地纯数据盘，是最省心的方案。

4.4 后台地理处理开关：64位与32位的区别

ArcGIS Pro默认使用64位后台地理处理，这意味着大多数地理处理任务能突破32位内存上限。但如果你所在的环境里，后台地理处理被关闭或者意外切换成了32位模式，水文工具在处理大范围DEM时就会频繁内存不足、意外崩溃。

检查路径：工程 -> 选项 -> 地理处理，确认“启用后台处理”是勾选状态，并且下面的“后台处理位数”是64位。改完设置后必须重启ArcGIS Pro才生效。

这里还有一个容易被忽略的内存参数，同样是地理处理选项页里的“临时栅格数据存储位置”。ArcGIS Pro运行水文工具时会产生大量临时栅格，默认路径可能在系统盘，如果C盘空间不足，并行计算和临时数据写入会互相争抢资源，任务失败概率大增。我的习惯是把临时栅格路径指定到大容量数据盘，比如D盘专门建一个“临时栅格缓存”文件夹，实测能减少不少莫名其妙的报错。

5. 常见报错速查与实战排查经验

5.1 高频报错对照表

这些报错里，ERROR 999999是最气人的，因为它本身是一个“万能错误”，本身不告诉你真正的原因。我自己遇到999999时，排查顺序是固定的：先改并行因子为0，不行再看磁盘空间，再不行看输出路径是否包含中文或特殊字符，最后才怀疑数据本身。这个顺序踩了很多次坑才总结出来。

5.2 一个真实的排查过程

有一次帮人在ArcGIS Pro 3.0上处理一个流域的河网提取，到了“流向”这一步，连续三次报ERROR 999999。第一次我先尝试把并行因子设成0，结果还是报错，于是我的排查链条继续走。

第二步我检查了工作目录，发现工程放在了某云盘同步目录下，立刻把整个工程复制到本地纯数据盘，重新跑，流向成功了，但“流量”又卡住了。接下来我怀疑是中间临时文件的问题，把菜单选项里的临时栅格位置也改到数据盘，再把流量输出格式从云栅格格式换成TIF，整个过程立刻顺畅了。那次经历让我深刻意识到：并行因子设0是第一步，但光设0不能解决所有环境类问题，整个运行链路的稳定性要一起检查。

5.3 避坑心得：设置完还要留个心眼

有些朋友把并行因子设成0后，跑通了小范围数据，就放心地拿着大面积数据直接开跑，结果半夜起来看发现又挂了。这种情况多半不是并行因子的问题，而是数据量太大导致临时文件占用过多空间。

我的建议是：大范围高分辨率的水文分析，拆成区块处理是常态。先按子流域或者方格网把大范围DEM切成几块，分别跑完水文流程，再通过栅格拼接工具合并。表面上看多了一步操作，但每一块的失败风险整体降低不少，反而比一次性跑完全部更省时间。

另外，ArcGIS Pro有时候改完环境设置后，新开工具对话框才能生效。如果你在现有工具对话框里改了环境值但没重新打开，工具用的还是旧值，这个问题非常隐蔽。我的做法是每次调完并行因子，就把当前工具对话框关掉重新打开，确保看到的就是实际用的。

还有一个容易忽视的小细节：如果你在ArcGIS Pro的Python窗口里直接执行工具，窗口本身有自己的环境状态，有时候你之前测试代码时设过env值，但之后手动改了全局设置，Python窗口里的旧值还在生效。最简单的办法是把Python窗口关掉重新打开，或者显式在代码开头重新赋值并行因子。

最后再补一个经验：ArcGIS Pro的版本差异很大，2.x和3.x在并行处理的稳定性和选项文案上都有变化。每次升级之后，水文工具第一次跑之前，我都习惯性打开环境看一下并行因子的默认值，别指望系统自己记住你的偏好。

6. 把并行处理因子日常化为“默认动作”

我在实际工作中已经养成了条件反射：只要下一步要跑水文分析相关工具，先看并行处理因子是不是0。这不是矫枉过正，而是在无数次凌晨排查报错里换来的教训。

可能有人会担心，并行因子设0会让大范围栅格处理慢到不可接受。其实在我的数据规模下——一般也就一亿像元以内——差异并不明显。水文分析工具本身并不是原生并行收益很高的工具，稳定运行比节省几分钟重要得多。如果你的数据确实到了需要并行才能跑完的级别，我建议你也别死磕水文工具本身，先去想想是不是应该对DEM做分幅、投影重采样或者降采样，数据处理策略比工具参数更能解决问题。

这里再分享一个我后来经常用的小技巧：把整个水文流程的“环境参数”存成ArcGIS Pro的一个模板工程。打开ArcGIS Pro后，直接从这个模板工程启动，所有环境设置都是预设好的，包括并行处理因子0、临时栅格位置、输出坐标系、像元大小，连默认输出目录都帮你固定好。这样你每次拿到新数据，只需要加载DEM、按流程跑工具，不需要再花时间检查环境设置。我用这个办法之后，水文分析的第一次成功率从原来的六成提到了九成以上，剩下的一成基本是数据本身的质量问题。

做水文分析这些年，越来越觉得这行比拼的早就不是“会不会用工具”，而是“出了问题找不找得到原因”。一个人对着满屏报错毫无头绪的时候，能快速定位到是环境的哪个参数在搅局，才是真正的核心竞争力。如果你现在正被ArcGIS Pro水文操作的某个旋涡拖着走，不妨先把所有“聪明的并行计算”关掉，让工具老老实实一步一步算，结果反而会给你惊喜。