ArcGIS工具箱汇总使用指南：tbx/atbx/pyt与批量裁剪投影避坑
简介：这是一份面向地理信息从业者、土地调查与制图分析人员的ArcGIS工具箱合集，围绕三调、日常空间数据处理和批量制图等场景，汇集了可直接调用的工具与配套数据，帮助减少重复操作、提升作业规范性与出图效率。压缩包共57个文件，约4.71MB，包含tbx工具箱、esriaddin插件、lyr图层样式，以及shp、dbf、prj等矢量数据与mdb数据库、字体文件，兼顾工具加载、符号配置和示例数据查看。已有1020人学习下载，说明其在GIS实操群体中具有一定参考价值。内容覆盖三调工具箱、虾敏工具箱、批量出图、批量投影、矢量排序和一键面拓扑等模块，并附三调字体库与安装使用说明；读者可据此完成土地调查数据处理、多数据集坐标统一、专题图批量输出及面要素拓扑检查修复，也能借鉴工具组织方式，逐步搭建适合自身项目的工作流。
1. 工具箱汇总用起来像开盲盒：先分清 tbx、atbx、pyt 三种壳
解压一份 arcgis工具箱汇总，最容易出问题的一步是双击第一个文件：图标长得一样，双击却蹦出一串看不懂的报错。问题不在工具本身，而在工具的外壳。.tbx 是 ArcMap 时代的二进制工具箱，.atbx 是 ArcGIS Pro 的新容器，.pyt 是纯文本的 Python 脚本工具箱，本质是一个带参数声明的 .py 文件。三种外壳对版本和运行时的要求完全不同，混装在一个目录里几乎必然出问题。这份汇总要解决的是重复劳动：批量裁剪、批量投影、字段批量改名、四至导出一类的活，每次都要重写一遍。它适合手里有几十上百个图层要处理的测绘、规划、自然资源方向从业者，也适合刚上手 arcpy、想先看看别人怎么组织工具的人。先看清外壳，再谈怎么用。
2. 挂载前的环境对齐：Python 版本、目录树与工作空间
装不上、跑了报错、跑完结果不对，这三类问题里至少一半出在挂载之前。工具箱本身只是参数声明的集合，真正干活的是它背后那个 arcpy 运行时。ArcMap 用的是 Python 2.7 加 32 位 arcpy，ArcGIS Pro 用的是 Python 3.x 加 64 位运行时，两者对字符串、编码、打印语句的处理方式完全不同。同一个 .pyt 在两边表现不一致，八成不是代码写错，而是根本没跑在你以为的那个解释器里。
2.1 先确认运行时：Python 2.7 与 Python 3 的两套 arcpy
我自己的习惯是：拿到任何一份别人整理的工具箱，先不着急导入，而是在软件自带的 Python 窗口里跑三行确认环境。ArcGIS Pro 在“分析”选项卡里点 Python 窗口，ArcMap 在 ArcToolbox 里右键打开 Python 窗口，两边的入口位置不一样，但目的相同——确认 arcpy 能被导入、版本号对得上、临时工作空间确实存在。
import sys import arcpy print(sys.version) # ArcMap 上是 2.7.x，Pro 上是 3.x，决定你能不能用 f-string info = arcpy.GetInstallInfo() # 返回安装信息字典 print(info["Version"], info["InstallDir"]) print(arcpy.env.scratchGDB) # 临时工作空间，脚本中途落中间数据全写这里这段代码的作用是自检，不是业务逻辑。sys.version决定了工具箱里的字符串写法能不能直接照搬：Python 2 里print "x"合法，到了 3 就是语法错误；反过来，Python 3 的 f-string 在 2.7 里会直接抛 SyntaxError。GetInstallInfo()拿到的 Version 字段能帮你判断工具箱是不是为当前大版本写的，比如一个标着 10.x 时代写法的脚本，在 Pro 里挂载后参数面板往往是空白的。scratchGDB这一行最容易被忽略，它默认指向一个临时文件地理数据库，如果这个路径不可写（比如指向了只读盘或者已经被清理掉的目录），后面所有需要落中间数据的工具都会在跑到一半时失败，报错信息还跟你真正在做的业务毫无关系。
提示：在 ArcMap 的 Python 窗口里
import arcpy成功，不代表在系统 cmd 里也能成功。32 位 arcpy 只随 ArcMap 安装注册，外部解释器里根本没有这个包。
版本确认完之后，还要看位数。ArcMap 是 32 位进程，处理大栅格或者几百万个要素的图层时，2GB 地址空间就是天花板，报“内存不足”不是数据有问题，是进程位宽的问题。同样的工具放到 Pro 的 64 位环境里跑，内存瓶颈会宽松很多。所以一份汇总里如果有明显吃内存的工具（大范围栅格裁剪、栅格计算器、大规模叠加分析），优先在 Pro 里跑；而依赖旧版扩展模块或者老 .tbx 模型的工具，才退回 ArcMap。
2.2 挂载动作：Pro 与 ArcMap 的目录树差别
挂载本身不复杂，麻烦的是挂载之后“能看到但用不了”。ArcGIS Pro 的路径是：目录窗格 → 工具箱 → 右键“添加工具箱” → 选中 .atbx、.pyt 或 .tbx。ArcMap 的路径是：ArcToolbox 窗口 → 右键空白处 → 添加工具箱。两边都能把 .tbx 加进去，但 Pro 对 .tbx 基本是只读兼容——模型能展开，里面的旧工具引用却经常找不到，双击之后参数面板一片空白。血泪经验是：只要目标环境是 Pro，就别指望 .tbx 能原样跑，要么在 Pro 里另存为 .atbx，要么直接把逻辑改写成 .pyt。
.pyt 的结构值得单独看一眼，因为汇总里可维护性最好的部分基本都是它。它没有二进制黑匣子，改一个参数只需要改一行文本。
# -*- coding: utf-8 -*- import arcpy class Toolbox(object): def __init__(self): self.label = "批量处理工具集" # 挂载后在目录树里显示的名字 self.alias = "batchtools" # 别名只能用字母、数字、下划线 self.tools = [BatchClip, BatchProject] class BatchClip(object): def __init__(self): self.label = "01 批量裁剪" # 加序号能强制工具在列表里排序 self.description = "按分割字段逐条裁剪，输出到指定地理数据库" self.canRunInBackground = False # 后台运行会吞掉交互提示，批处理建议关 self.category = "矢量处理" def getParameterInfo(self): p_in = arcpy.Parameter( displayName="输入要素", name="in_features", datatype="DEFeatureClass", parameterType="Required", direction="Input") p_mask = arcpy.Parameter( displayName="掩膜要素", name="mask_features", datatype="DEFeatureClass", parameterType="Required", direction="Input") p_field = arcpy.Parameter( displayName="分割字段", name="split_field", datatype="Field", parameterType="Required", direction="Input") p_field.parameterDependencies = [p_mask.name] # 字段下拉跟随掩膜联动 p_out = arcpy.Parameter( displayName="输出工作空间", name="out_workspace", datatype="DEWorkspace", parameterType="Required", direction="Output") return [p_in, p_mask, p_field, p_out] def isLicensed(self): return True def updateParameters(self, parameters): return def updateMessages(self, parameters): # 输出别选 shapefile，字段名 10 字符上限会把业务码截断 if parameters[3].value and str(parameters[3].value).lower().endswith(".shp"): parameters[3].setErrorMessage("输出请选文件地理数据库") return def execute(self, parameters, messages): arcpy.AddMessage("参数已就绪，开始跑批")关键在getParameterInfo这一段。datatype决定了参数面板给你弹什么选择器：DEFeatureClass是要素类，DEWorkspace是工作空间，Field是字段，DESpatialReference是坐标系。parameterType分 Required 和 Optional，标了 Required 而用户没填，工具根本进不了 execute。direction的 Input 和 Output 影响的是相对路径的解析方式，Output 参数在模型里还能自动接上后续工具的输入。parameterDependencies是最容易被漏掉的一行：字段类型的参数必须挂在某个上游要素参数上，否则下拉列表里会列出当前工作空间所有图层的所有字段，选错一次就够排查半天。
canRunInBackground我一般明确设成 False。后台运行的本意是让界面不卡，但批处理工具一旦进了后台线程，arcpy.AddMessage的输出顺序会乱，出错时的堆栈也不完整，调试期纯属给自己添堵。等逻辑稳定了再打开，收益才明显。
2.3 工作空间、编码与输出目录的固定套路
路径是另一处高频事故点。ArcMap 的 32 位进程对长路径敏感，完整路径接近 260 个字符时，各种“无法创建输出”“000210 无法打开”就开始出现，而且报错指向的位置往往跟真实原因差着十万八千里。中文目录、带空格的目录、层级特别深的目录，三样占一样就够难受。我现在的固定做法是开一个D:\gis\work这样的短路径工作区，所有输入输出都往里放，跑完之后再整体搬走。
import os import arcpy work = r"D:\gis\work" # 纯英文、无空格、层级浅，别放桌面或中文目录 arcpy.env.workspace = work arcpy.env.overwriteOutput = True # 重跑不报“已存在”，调试期能省一半时间 arcpy.env.parallelProcessingFactor = "0" # 0 表示按可用核数上限跑 scratch = os.path.join(work, "scratch.gdb") if not arcpy.Exists(scratch): arcpy.management.CreateFileGDB(work, "scratch.gdb") arcpy.env.scratchGDB = scratch print(arcpy.env.scratchGDB)env.workspace设好之后，ListFeatureClasses()这类函数就不用每次传完整路径，工具的相对路径解析也有了基准。overwriteOutput是最实用的一个开关，默认关闭时，同名输出会直接报错中断，开着则覆盖重写，反复调试同一个工具时体验差别巨大。parallelProcessingFactor设成 “0” 表示按可用核数上限并行，对大范围栅格运算提升明显；但要注意并行和游标、临时文件之间偶尔会打架，脚本里如果混着da.UpdateCursor，先设成 “1” 老实串行跑通，再放开。
临时工作空间单独建一个 gdb，是为了把中间结果和正式成果分开放。所有Dissolve、Project、FeatureToLine之类的过渡数据丢进 scratch，跑完直接删目录，不用在一堆xxx_1、xxx_2里靠猜去找真正的成果。这个习惯养成之后，输出目录会干净很多。
3. 批量裁剪与批量投影：把两个最高频的动作拆到参数级
汇总里使用频率最高的就是这两个工具，也最容易在“跑通了但结果不对”上翻车。它们的技术门槛都不高，难的是边界条件：掩膜重叠怎么算、坐标系不一致时以谁为准、跨基准面要不要给变换参数。把这两件事讲透，剩下的工具基本都是同构的。
3.1 批量裁剪：先用融合去掉重复边界
最朴素的写法是遍历掩膜要素，一条一条做裁剪。如果掩膜是一份村级界线，几千个面就是几千次循环，每次循环都要把源数据完整读一遍，几十万要素的源图层跑一晚上都很正常。我一般会先Dissolve一次，把分割字段值相同的相邻面合并成一个多部件要素，循环次数能从几千降到几百，速度差别是数量级的。
import os import arcpy src = r"D:\gis\work\in.gdb\landuse" # 要被分割的源图层 mask = r"D:\gis\work\in.gdb\township" # 分割边界 split_fld = "TOWN_CODE" # 分割字段，值相同的合成一个掩膜 out_gdb = r"D:\gis\work\out.gdb" arcpy.env.overwriteOutput = True arcpy.env.workspace = out_gdb # 1) 先融合，相邻碎面合并成多部件要素，循环次数大幅下降 dissolved = os.path.join(arcpy.env.scratchGDB, "mask_diss") arcpy.management.Dissolve(mask, dissolved, split_fld, multi_part="MULTI_PART") # 2) 逐条掩膜裁剪，内存里同时只存在一个分组 with arcpy.da.SearchCursor(dissolved, [split_fld, "SHAPE@"]) as cur: for code, geom in cur: if geom is None or geom.area == 0: continue # 空几何直接跳过，别让整批挂掉 out_name = "LU_{}".format(code) # 用业务码命名，事后能一对一核对 try: arcpy.analysis.PairwiseClip(src, geom, os.path.join(out_gdb, out_name)) except arcpy.ExecuteError: arcpy.AddWarning("{} 裁剪失败：{}".format(code, arcpy.GetMessages(2)))Dissolve的第三个参数是分割字段，multi_part="MULTI_PART"表示同一个字段值的多个不相邻面合并成一个要素，这样一次掩膜就能覆盖全部区域，不会漏掉飞地。SearchCursor取SHAPE@而不是SHAPE@XY，是因为要的是完整几何对象，可以直接当掩膜用，省掉把每个分组先导出成临时要素类再裁剪的一步，IO 少一半。PairwiseClip的第二个参数支持传几何对象，这是很多人不知道的一点，也是这段代码能压掉中间文件的关键。
try/except包在循环内部而不是外面，是刻意为之：一条掩膜失败不该让剩下几百条全部作废。捕获arcpy.ExecuteError之后用AddWarning打出来，跑完看消息列表就知道哪几个编码需要单独重跑。输出命名直接用业务码，别用output_1、output_2，后者在几百个文件的情况下根本没法核对。
栅格裁剪是另一套接口。PairwiseClip对栅格支持有限，常见做法是走arcpy.sa.ExtractByMask，需要 Spatial Analyst 许可；或者在 Pro 里用arcpy.management.Clip，它的rectangle参数能直接吃范围对象。栅格裁剪务必确认snapRaster环境，否则相邻分幅之间会出现半像元的错位，拼接时接缝肉眼可见。
注意：裁剪结果的坐标系跟着输入走，不是跟着掩膜走。掩膜和源数据坐标系不一致时，工具会做即时投影，但这个即时投影用的是默认变换，跨基准面时精度没保证。
3.2 批量投影：投影和地理变换不是一回事
投影这件事被误解得最多。同一基准面下的坐标转换（比如 CGCS2000 地理坐标转 CGCS2000 高斯克吕格投影）是纯数学变换，可逆、无精度损失；跨基准面的转换必须给地理变换参数，而地理变换是有精度损失的，三参数、七参数、不同区域模型结果都能差出几米。工具不管你有没有给对变换，它只按你给的执行，给错了就静默偏移，跑完数据看着正常，套到别的图层上才发现整体错位。
import arcpy target = arcpy.SpatialReference(4490) # CGCS2000 地理坐标系；投影坐标系换成对应 WKID arcpy.env.workspace = r"D:\gis\work\in.gdb" for fc in arcpy.ListFeatureClasses(): sr = arcpy.Describe(fc).spatialReference if sr.name == target.name: continue # 已经是目标坐标系，跳过，避免二次重采样 # 跨基准面才需要变换；同基准面返回空列表，method 留空即可 transforms = arcpy.ListTransformations(sr, target) method = transforms[0] if transforms else "" out_fc = fc + "_prj" arcpy.management.Project(fc, out_fc, target, method) print("{} -> {} 变换={}".format(fc, out_fc, method or "无"))SpatialReference(4490)用 WKID 而不是名称字符串，是因为名称匹配对大小写和写法很敏感，CGCS2000、China Geodetic Coordinate System 2000在不同版本里写法不统一，用数字最稳。Describe().spatialReference拿到的name只到坐标系级别，判断“是不是已经是目标坐标系”足够了；如果要更严格，比factoryCode。
ListTransformations返回的是当前环境下一组可用的变换方法，按适用性从高到低排。直接取第一个是常见做法，但前提是你知道自己数据的基准面确实存在对应的官方变换，取不到就返回空，这时候method留空，工具会按同一基准面处理，跨基准面的情况下等于默认偏移。稳妥的做法是把候选列表打出来人工确认一次，确认过的变换名写死在脚本里，别每次跑都靠自动挑。
preserve_shape和max_deviation两个参数在批量场景里通常保持默认。前者设为PRESERVE_SHAPE会为了保持形状做额外加密，代价是要素节点变多、文件变大；后者只在部分变换方法下生效，设了不支持的参数会被静默忽略。要素数据集里的要素类还有一个额外约束：它必须和所属数据集坐标系一致，不能单独投影，遇到这种报错先看数据是不是在数据集里。
4. 字段与属性表类工具：改名、四至与类型转换
属性表相关的工具在汇总里占比很高，因为它们最枯燥、最容易写错、也最容易被反复重写。这类工具的共同特点是：操作本身很简单，但 ArcGIS 的字段模型有几个反直觉的限制，不知道就会绕远路。
4.1 批量字段改名：AlterField 改的是别名不是名字
很多人第一次用AlterField改字段名，跑完发现字段名没变，只是显示的名字变了。这不是 bug，是设计如此：地理数据库里字段有name和alias两个属性，AlterField改的是后者，真正的字段名在地理数据库里是不可修改的。要真改名，只有一条路——建新字段、拷值、删旧字段。麻烦但可靠。
import arcpy def safe_rename(fc, old, new, new_type=None): """建新字段 -> 拷贝值 -> 删旧字段；AlterField 只改别名，改不了真名""" fields = arcpy.ListFields(fc, old) if not fields: return False # 字段不存在，跳过，批量调用时很常见 desc = fields[0] ftype = new_type or desc.type # 类型要换时显式传入，比如 Double 转 Long arcpy.management.AddField( fc, new, ftype, field_length=desc.length, # 长度、精度、小数位必须跟着原字段，否则截断 field_precision=desc.precision, field_scale=desc.scale) # 用字段名直接赋值，比 CalculateField 拼表达式快，也不会被中文值坑 with arcpy.da.UpdateCursor(fc, [old, new]) as cur: for row in cur: row[1] = row[0] cur.updateRow(row) arcpy.management.DeleteField(fc, old) return TrueListFields(fc, old)传第二个参数做通配，字段不存在时返回空列表而不报错，批量调用时靠这个做存在性判断，比try/except干净。AddField的三个可选参数不能省：field_length对文本字段就是字符上限，不传会取默认 50，中文名称很容易被截；field_precision和field_scale对浮点字段决定了有效位数和小数位数，不传的话从 Double 拷过来的数值可能被四舍五入。
用da.UpdateCursor而不是CalculateField，速度差距在小数据上不明显，几十万行时能差出好几倍。CalculateField要把表达式送进解析器，字符串拼接、字段名转义、中文值都可能出问题；游标是逐行读写，逻辑直白。代价是新字段永远追加在表末尾，字段顺序会乱，如果下游有工具依赖字段顺序，得在建字段前先规划好。
Shapefile 还有 10 个字符的字段名硬限制，超了会被自动截断，TOWN_CODE_NEW变成TOWN_CODE_，两个字段撞名之后的行为很难预测。所以批量改名工具的输出目录我一般强制要求地理数据库，在updateMessages里直接拦掉 .shp 路径。
4.2 四至与外接矩形：extent 的单位陷阱
图斑四至是汇总里被问得最多的工具之一。逻辑本身只有四行：取几何的外接矩形，读出 XMin、YMin、XMax、YMax，写进四个字段。真正容易出问题的是单位——地理坐标系下这四个值是度，投影坐标系下是米，两者混在一张表里，下游算面积或者做图廓的时候会得到荒唐的结果。
import arcpy fc = r"D:\gis\work\out.gdb\parcel" # 字段不存在才建，重复跑不会报错 exist = {f.name.upper() for f in arcpy.ListFields(fc)} for name in ("XMIN", "YMIN", "XMAX", "YMAX"): if name not in exist: arcpy.management.AddField(fc, name, "DOUBLE", field_precision=15, field_scale=3) with arcpy.da.UpdateCursor(fc, ["SHAPE@", "XMIN", "YMIN", "XMAX", "YMAX"]) as cur: for row in cur: geom = row[0] if geom is None: continue # 空几何在外接矩形上会直接抛异常 ext = geom.extent row[1], row[2], row[3], row[4] = ext.XMin, ext.YMin, ext.XMax, ext.YMax cur.updateRow(row)field_precision=15, field_scale=3是有讲究的：精度 15 表示总的有效位数，小数位 3 表示保留到毫米。度为单位时三位小数大约对应 100 米，精度明显不够；米为单位时三位小数是毫米级，够用。如果数据是地理坐标系，把 scale 调到 6 到 8 更合适，或者先投影再算。判断方法很直接，跑之前print(arcpy.Describe(fc).spatialReference.linearUnitName)看一眼就知道单位是 Meter 还是 Degree。
SHAPE@会把完整几何读进内存，几十万要素的大图层会比较慢，但对四至来说没法省——SHAPE@XY只给质心坐标，拿不到范围。geom.extent是几何自带的外接矩形，读它不会触发重新计算，比逐个遍历节点快得多。空几何必须判断，None和面积为 0 的退化几何在extent上都会抛异常，一条脏数据能让整批中断。
四至算出来之后，还有一个常见需求是拼成“东至XX、南至XX”的文本。拼接时用format控制小数位，别直接str()转换，浮点数会给你一串 15 位的尾巴。文本字段长度按最长的可能值预留，中文一个字占两个字节的情况在 shapefile 里还要再加倍。
4.3 属性表批量导出的两种姿势
四至、面积这类结果最终往往要进 Excel 或者汇总表。汇总里的工具一般给两种导出方式：一种是TableToExcel，直接写 xlsx，字段名就是表头，缺点是大表慢且不支持超过 65535 行的老格式限制；另一种是用da.SearchCursor逐行写 CSV，纯文本、无依赖、几百万行也扛得住，缺点是中文编码要自己指定。
我一般默认走 CSV，encoding="utf-8-sig"，带 BOM 的话 Excel 双击打开不会乱码，这个小细节能省掉一堆“你发的表怎么是乱码”的来回。真要 xlsx，就用TableToExcel，别自己拿第三方库往地理数据库里塞，许可和版本都可能出问题。
5. 避坑与排查：五个反复出现的翻车记录
工具箱用不起来，绝大多数不是逻辑复杂，而是几个固定的坑反复踩。下面这五条是我自己记录过的，按现象、原因、解决三段写，遇到时对照着看就行。
5.1 挂载与环境
现象一：工具箱在 Pro 里能看到，展开也有工具，双击之后参数面板一片空白。原因基本可以锁定在 .tbx。它是 ArcMap 时代的二进制容器，里面的模型引用了旧版的工具 ID，Pro 只做只读兼容，遇到不认识的引用就把参数藏起来，界面上看不出任何错误提示。解决方式是不要试图修 .tbx，直接在 Pro 里新建工具箱把逻辑重建一遍，或者改用 .pyt 重写。重建一次的成本，比在兼容层上反复试错低得多。
现象二：脚本单独运行正常，挂到工具箱里执行就报No module named arcpy。原因是在系统 Python 里双击运行了 .py 文件。arcpy 不是 pip 包，它只跟随软件安装注册在特定的解释器里，系统的 Python 环境里根本没有。解决方式是只通过软件自带的 Python 窗口或者工具箱入口执行；确实需要在命令行跑，就用软件安装目录下那个批处理启动器，它会把环境和路径都配好。判断方法很简单，在报错的那个环境里import sys; print(sys.executable)，路径不是软件目录就是走错门了。
现象三：一晚上跑完，输出目录里有一半文件是 0 字节或者干脆没生成。路径问题。中文目录、带空格的目录、层级太深，三样占一样就可能触发。ArcMap 的 32 位进程对完整路径长度敏感，接近上限时创建输出会失败，但报错信息经常指向别的工具。解决方式是把工作目录换成纯英文短路径，输出文件名控制在 30 个字符以内，中间结果统统丢进临时地理数据库。改完路径还不行，再看磁盘剩余空间和输出目录的写权限。
5.2 参数与结果
现象四：裁剪跑得很顺，属性表也齐全，但面积字段还是裁剪前的老数值。面积、长度、周长这类字段是静态字段，几何变了它不会自动重算。很多汇总工具在输出时会带上源图层的字段结构，面积字段原样复制过来，看着有值，实际是错的。解决办法是裁剪完统一重算一遍，Pro 的字段计算器里用!shape.area!，脚本里用da.UpdateCursor读SHAPE@AREA写回字段。凡是涉及几何变化的操作，面积字段都要当作无效值处理。
现象五：批量投影完成，坐标系显示正确，套到其他图层上却整体偏移几百米。跨基准面没有给地理变换参数。Project工具在源和目标基准面不同、又没指定变换方法时，会按默认方式处理，不同版本的默认值还可能不一样，结果就是静默偏移。排查方法是先用arcpy.ListTransformations(源坐标系, 目标坐标系)把可用变换打出来，确认有没有官方推荐的那一个，然后写死到参数里。再顺手做一次抽检：挑一个特征明显的角点，投影前后各记一次坐标，反算距离，偏差超过预期就说明变换选错了。
6. 把工具串成流水线：跑批日志与三项体检
单个工具跑通只是第一步。真实项目里更常见的是“投影 → 裁剪 → 算四至 → 导表”这样一串动作，几十个图层滚动跑一遍，中间任何一个环节出问题都要能定位到具体是哪个图层、哪一步。我现在的固定做法是给整个批次套一层日志，跑完立刻做三项体检。
import os import time import arcpy def run_batch(fcs, out_dir, log_path): """逐图层跑流水线，异常不中断整批，全部记录到日志""" with open(log_path, "a", encoding="utf-8") as log: for fc in fcs: t0 = time.time() try: # 这里换成投影 -> 裁剪 -> 四至的真实调用顺序 arcpy.AddMessage("处理 {}".format(fc)) log.write("OK {} {:.1f}s\n".format(fc, time.time() - t0)) except arcpy.ExecuteError: # 第二个参数 2 只取错误级别消息，日志不会被提示信息淹没 log.write("FAIL {} {}\n".format(fc, arcpy.GetMessages(2))) except Exception as e: log.write("FAIL {} {}\n".format(fc, e)) log.flush() # 长批次必须手动刷，进程被中断时日志才不会丢两个细节值得说。arcpy.GetMessages(2)只取错误级消息，不取警告和提示，日志文件能小一个数量级，排查时也更容易扫。log.flush()在跑几个小时的批次里是必需品，不刷缓冲的话进程一旦被杀，日志里什么都留不下，等于没记。异常分两层捕获：arcpy.ExecuteError是工具层面的失败，能拿到完整消息；其余异常是脚本层面的，比如字段不存在、类型不匹配，也要记下来而不是直接崩。
跑完之后的体检我固定做三项：要素数对不对、面积合计对不对、坐标系对不对。要素数用GetCount比，裁剪后总数应该和源图层接近但不相等（边界会被切掉一部分），差得离谱说明掩膜有问题；面积合计用游标累加SHAPE@AREA，投影前后的差异应该在可接受范围内，差出百分之几说明投影参数错了；坐标系直接读Describe().spatialReference.name，和目标值逐字符比对。
这三项加起来不到二十行代码，但拦住过我好几次事故。有一次批量投影的变换参数写错，要素数和属性表全都正常，只有面积合计比预期大了 3%，靠这一项才揪出来。从那以后我每次跑完批处理，不管多急，这三项体检都强制走一遍，宁可多花五分钟，也不想在交付之后被返工。希望帮到你。
本文还有配套的精品资源，点击获取