ArcGIS二次开发实战：ArcPy构建评价单元综合限制级别判断矩阵工具

搞过国土空间规划、自然资源评价或者项目选址评估的人，大多数都被同一件事折磨过：手里攥着一份评价单元，面前摊着生态保护红线、永久基本农田、地质灾害易发区、洪水影响区、水源保护区、矿产压覆区……一长串限制性图层，要做的工作就是给每个评价单元算出一个“综合限制级别”。

任务听起来简单，等真动手就发现根本不是那么回事。不同审批部门的限制规则不一样，有的因子只要压到一点就必须“一票否决”，有的因子则要按面积占比折算，还有其他因子的组合效应需要叠加判断。每个图层单独出一张图是一个工作量，把它们和评价单元叠到一起、按规则计算综合级别，又是一个更繁琐的工作量。如果项目周期紧、规则又经常变，靠手工作业会在数据检查上耗费大量精力，别问我怎么知道的。

这类应用正好是ArcGIS二次开发最典型的场景之一。用ArcPy写好判断矩阵逻辑，再做个小工具，把“读取评价单元—空间叠加—逐级判断—输出字段和专题图”整条链路串起来，以后换一个片区、换一套规则，只要换数据和配置就行。这篇文章就把我当时做“评价单元综合限制级别判断矩阵工具”的完整思路、代码写法、踩坑过程都整理出来，给需要做类似限制性评价工具的同学当个参考。

1. 这个工具到底解决什么问题

1.1 限制性评价的典型业务场景

一般在做规划选址、用地适宜性评价或者自然资源“三区三线”协调分析时，会先划出一批评价单元。这些单元可能是行政区里的地块图斑，可能是规划允许建设区里的各个分区，也可能是国土空间规划中某个专项评估的最小统计网格。

评价单元确定之后，需要回答的核心问题就是：这块地能不能用，能用成什么样，需要满足什么前置条件。要回答这个问题，靠的是叠加分析。基本农田属于永久管控线内的，生态红线又压倒一片，再加上水土流失易发区、地灾中高风险区、行洪区等，每个限制因子都对用地性质有不同的控制要求。

如果限制因子只有两个，还能靠手工目视判读；一旦限制因子超过四五个，评价单元数量上千甚至上万，再靠人工逐块翻图判断就基本不现实了。我曾经接过一个片区评估，评价单元大概两千多个，限制因子有六个，第一版数据还没完全到位，规则已经改了三次。这种情况下，唯一的出路就是把逻辑固化成一个可反复跑批的ArcGIS二次开发工具。

1.2 “综合限制级别”是怎么定义的

很多做评价的人会被“综合限制级别”这个名词绕住，觉得是不是要对多个因子做权重、打分、模糊评价、层次分析之类的高深算法。真实的限制性评价通常没那么花哨，多数场景下采用的是“最不利原则”加“组合升级原则”。

我先解释一下“最不利原则”：对同一个评价单元，如果水源保护区给它定的是三级限制，地质灾害易发区给它定的是四级限制，那就取最高的四级作为该单元在这个环节的限制强度。原因很简单，限制性评价本质上是一种安全底线评估，最严格的那个因子往往代表了这个单元不可忽视的制约条件。

然后是“组合升级原则”：当单元内不存在一票否决等级，但出现多个中等限制因子且空间上相互叠加时，限制程度就不能简单以单个最高级别来评价了。比如按矩阵规则，两个三级限制同时存在，应当升级到四级或限制到“有条件使用”。正是这些跨因子的组合判断，构成了一个典型的判断矩阵逻辑。

1.3 为什么必须用ArcGIS二次开发而不是手工做

面对这类工作，ArcGIS桌面端本身也能完成一套基础操作：相交、按位置选择、属性表关联、字段计算器写判断语句，每一步都能做。但麻烦的地方在于，这套流程要反复执行，数据源还可能来自不同分区、不同坐标系、不同属性结构，真要用桌面工具一步步点下去，不但慢，而且中间任何一步手误都可能导致结果错误，又很难从数据上追溯。

ArcGIS二次开发，说白了就是用ArcPy把这一连串地理处理流程串成一整条可控的链路。核心价值不是省去“判断”本身，而是把“判断规则”变成可配置、可重复、可追溯的程序：

• 可配置：限制因子列表、级别字段、判断矩阵参数都放在配置里，不需要改代码；
• 可重复：数据更新后重新跑一次脚本就能出新结果；
• 可追溯：每一步生成中间数据，哪一步出错都能追踪到，不会出现“不知道最后结果怎么来的”的窘境。

另外还有一个很实际的好处：ArcGIS脚本工具跑出来的结果可以和ArcGIS Desktop、ArcGIS Pro共用，出图、入库、检查都方便。这个优势在做大型评审项目时特别明显，项目组其他人不需要学Python，只要会点开工具填参数就够了。

2. 开发环境准备与ArcPy关键点解析

2.1 ArcMap还是ArcGIS Pro，Python环境怎么选

开发这个工具之前，先得确认自己手头是ArcMap还是ArcGIS Pro，因为两者对应的Python环境不一样。ArcMap 10.x使用的是Python 2.7，ArcMap里写代码时好些操作要用arcpy.mapping来处理文档对象；ArcGIS Pro则使用Python 3，对应的是arcpy.mp，语法细节上有差别，写脚本时不能混用。

如果你现在是从零开始的新项目，我的建议是直接用ArcGIS Pro。一方面Python 3语法兼容性更好，写的脚本可维护性高；另一方面Pro对大数据集、后台并行、64位处理的支持都比老ArcMap强，处理几千上万个图斑时不至于卡得怀疑人生。ArcMap虽然还有大批存量用户在维护老项目，但新工具开发再基于Python 2.7去写，等于一开始就给自己埋了兼容性的雷。

我开发时用的就是ArcGIS Pro，环境基于Python 3。如果你只能在ArcMap里做，代码逻辑基本可以复用，但凡是涉及当前文档、图层符号、项目环境的API都要做对应替换。最稳妥的方案是先把核心计算逻辑写成不依赖界面对象的纯数据处理脚本，这样到哪个ArcGIS版本上都能跑，最多在包装成工具时改一改外壳。

2.2 空间叠加的核心API：Intersect、SpatialJoin还是TabulateIntersection

限制因子和评价单元的空间关系，一般无非三种：限制面穿过评价单元、限制面部分覆盖评价单元、限制面完全覆盖评价单元。想把“每个评价单元里有哪些限制因子、达到什么级别”这个对应表拿到手，有几种技术路线：

第一种是arcpy.analysis.Intersect，把评价单元和限制因子要素做几何相交，相交后的每个小图斑同时继承评价单元编号和因子级别属性。这个方法最直观，还能对精度要求高的场景计算相交比例，缺点是数据量大时产生的中间要素会非常碎，输出记录可能是输入记录的很多倍。

第二种是arcpy.analysis.SpatialJoin，以评价单元为目标要素、限制因子为连接要素，JOIN_ONE_TO_ONE，再配合字段映射的合并规则取最大值，把因子级别直接写到评价单元的结果字段里。这个方法代码比较简短，适合只关心“最严重级别”的场景。

第三种是arcpy.analysis.TabulateIntersection，最常用于需要统计各类限制因子占评价单元面积比例的场合，输出是一个表，每个评价单元一行，记录与其他图层的相交面积和占比。业务规则只要不是“一票否决”，而是按面积阈值分档，这个方法就比前两种好用。

我当时实际采用的是“Intersect + 字段提取 + 矩阵规则函数”的路线。虽然中间表大，但灵活性最高。因为交出来后我能同时看到每个子图斑的因子来源、面积比例、级别，后面做任何矩阵配置都有完整基础数据，排查问题也方便。SpatialJoin虽然快，但把数据细节藏得太深，出了问题不太容易定位到某一个具体因子上。

2.3 写好脚本的工程化习惯：临时数据与统一工作空间

不管选哪种叠加方式，脚本开发过程中都得养成一套好习惯。最基础的一点是设置统一工作空间并管理中间数据，我一般在脚本开头做这几件事：

import arcpy import os arcpy.env.overwriteOutput = True arcpy.env.workspace = r"E:\Work\RestrictEval\gdb_workspace.gdb" arcpy.env.scratchWorkspace = r"E:\Work\RestrictEval\scratch.gdb"

这样设计是为了让输出落在一个统一的地方，后续步骤可以直接用中间数据名称调用，避免路径混乱。overwriteOutput = True可以保证重复运行时不会因为中间数据已存在而报错，这在工具反复调试阶段特别重要。

对于纯中间环节、不需要留存的临时结果，我通常直接放到in_memory工作空间里。in_memory下的数据读写速度比磁盘工作空间快很多，尤其在叠加几百个图层的时候，效率提升非常明显。不过有一个坑，in_memory数据在某些复杂拓扑计算时偶尔会不稳定，如果Intersect之后报奇怪的“底层数据库错误”，可以把输出路径改到真实gdb里再跑一次验证。这个坑我后面会专门说。

3. 一步步实现评价单元综合限制级别计算

3.1 数据规范检查：统一坐标系、检查字段、标准化级别编号

工具一开始不能急着做空间分析，第一步永远是数据检查。我做第一版的时候就犯过懒，想着直接跑Intersect，结果跑完发现大量评价单元没有叠加到任何限制因子，后来排查到原因是限制图层和评价单元坐标系不一致，空间上根本没重叠在一起。这个问题在ArcGIS处理时太常见了，属于最气人的一种错误，不是代码逻辑问题，而是数据没对齐。

写工具时我会做一个硬性的前置检查：

• 检查评价单元和所有限制因子是否都具备正确的投影坐标系；
• 如果坐标系不一致，先对限制图层做arcpy.management.Project投影转换，而不是让ArcGIS在Intersect时自动提示坐标系冲突；
• 检查评价单元必须有一个唯一标识字段（比如单元编码），并且字段值不能为空或重复；
• 检查每个限制图层是否都带着“级别字段”，级别字段必须是整型，且取值落在预设范围内。

级别字段的标准化非常重要。我在项目里和业务部门统一了一套取值规范：

这些取值不是随便定的，它会直接影响后面的判断矩阵逻辑。0是无限制，1到4限制程度逐级加重，4代表只要压到就禁止。实际项目里如果还有其他因子，可以在各因子的业务规则映射阶段将不同标准翻译成这套统一的0-4数值，千万别直接在多个因子原始级别上做判断，否则每个图层的分类口径不一致，后面规则会写出无数个if-else分支。

3.2 空间相交：把每个评价单元内的限制因子级别提取出来

规范性检查做完，下一步就是让评价单元和所有限制图层做相交，生成一个重叠子图斑结果表。这一步的核心代码逻辑比较简单，重点在相交后的字段组织和后续的统计方式。

unit_fc = r"E:\Work\RestrictEval\data.gdb\eval_units" restrict_layers = [ {"fc": r"E:\Work\RestrictEval\data.gdb\eco_redline", "level_field": "LEVEL", "name": "EcoRedline"}, {"fc": r"E:\Work\RestrictEval\data.gdb\water_source", "level_field": "LEVEL", "name": "WaterSource"}, {"fc": r"E:\Work\RestrictEval\data.gdb\geo_hazard", "level_field": "LEVEL", "name": "GeoHazard"}, ] intersect_output = r"E:\Work\RestrictEval\scratch.gdb\unit_restrict_intersect" arcpy.analysis.Intersect( in_features=[unit_fc] + [item["fc"] for item in restrict_layers], out_feature_class=intersect_output, join_attributes="ALL", output_type="POLYGON", cluster_tolerance=None )

相交之后，生成的要素类会同时包含评价单元的所有字段和限制图层的所有字段，实际字段数量可能很多，属性表看起来会很乱。在进入业务判断之前，我会把真正有用的字段提取出来，存成一张简洁的统计表，而不是直接在相交结果上做聚合。

提取的逻辑是：遍历相交结果的每个要素，按评价单元编码汇总，取得该单元在每个限制因子类别下的最大级别。这里用最大级别代表该单元在该限制因子下的限制强度，符合最保守评价原则；如果你要按面积比例折算，就需要额外计算每个子图斑的面积并除以单元总面积，逻辑会复杂不少，但基于这套中间数据改造起来也不难。

unit_id_field = "UNIT_CODE" level_field = "LEVEL" result_stats = {} with arcpy.da.SearchCursor(intersect_output, [unit_id_field, level_field]) as cursor: for unit_code, level_value in cursor: if unit_code is None: continue level_value = int(level_value) if level_value is not None else 0 if unit_code not in result_stats: result_stats[unit_code] = [] result_stats[unit_code].append(level_value) # 对每个单元生成统计字典 unit_factor_level = {} for unit_code, level_values in result_stats.items(): # 取该限制因子在该单元内最大的限制级别 unit_factor_level[unit_code] = max(level_values)

上面这个示例只演示了一个因子图层的情况。真实工具里，需要循环处理多个因子图层，最终给每个评价单元生成一个类似{"UNIT001": {"EcoRedline": 4, "WaterSource": 2, "GeoHazard": 3}}的中间字典，再把这字典传给综合判断函数去套判断矩阵。这种“先抽取因子级别矩阵、再做规则判断”的做法，能让逻辑分层很清晰，以后想加一张因子图，不需要动判断函数，只要增加图层配置就行。

实际跑批时，如果评价单元数量很大（几万甚至几十万），把所有结果存进Python字典可能会占用比较高的内存。这时候可以换一种思路，先把Intersect结果按单元编码汇总成表，再通过arcpy.da.UpdateCursor逐行更新评价单元的最终字段。不过一般几千到一万多的评价单元，直接使用字典是没问题的，写起来也直观。

3.3 判断矩阵规则：把复杂的业务规则变成可执行代码

规则是本工具最核心的部分，也是业务部门最容易反复修改的部分。我强烈建议不要把这个判断矩阵写成几十行散落的if-else，而应该先设计成一张明确的规则表，再翻译成函数。

先给一个业务规则的示例。假设某项目规定：

• 任意一个限制因子级别为4，评价单元综合限制级别直接定为4（一票否决）；
• 不存在级别4的情况下，如果出现两个及以上级别3的因子，综合限制级别定为4；
• 不存在级别4和级别3叠加的情况时，取所有因子的最大级别，但如果最大级别为3且同时有两个级别2的因子，综合限制级别定到3；
• 其余情况综合限制级别等于所有因子中的最大级别；
• 如果所有因子级别都在0和1之间，综合限制级别取最大级别。

这个规则其实已经是一个判断矩阵的雏形了。我在代码里会用“多因子级别字典 + 降序排序 + 规则计数”的方式来实现：

def calc_composite_level(factor_levels: dict) -> int: values = [int(v) for v in factor_levels.values() if v is not None] if not values: return 0 # 一票否决：如果有4级因子，直接返回4 if any(v >= 4 for v in values): return 4 # 统计各等级数量 level3_count = sum(1 for v in values if v == 3) level2_count = sum(1 for v in values if v == 2) # 两个或以上3级因子组合升级为4 if level3_count >= 2: return 4 # 单个3级因子但有2个及以上2级因子，维持3级属于偏严处理 max_level = max(values) if max_level == 3: return 3 # 正常情况下取最高等级 return max_level

这个函数短小清晰，但它只反映“最不利 + 简单组合升级”的规则。如果你的业务规则更加复杂，比如不同因子之间有不同的权重组合关系，那我更推荐把配置外置成一个矩阵配置文件。下面是一个典型的“级别组合规则表”的设计思路：

规则表可以放在Excel或CSV中，每次跑批前让工具读取配置。业务人员调整规则时不需要开发人员介入，这种“前后端分离”的思路，做进了二次开发工具里，日常维护会轻松非常多。

3.4 写回结果并生成基础专题图

判断结果算出来之后，需要写回到评价单元的属性表中。我的做法是给评价单元要素类提前预留一个“综合级别”字段，如果字段不存在则用arcpy.management.AddField新建，然后用arcpy.da.UpdateCursor逐行写入。

这个过程有一处非常容易踩坑：评价单元的唯一标识字段和Intersect结果中的编码字段类型必须一致，都必须是文本或都是数值。如果一个是文本型，另一个是数值型，Python字典查询时永远匹配不上，最后所有单元都会落到默认值。另外，如果编码字段有空格差异、中英文全半角差异，也可能出现“看似匹配上，实际写不进去”的怪问题。我在几个项目里都遇到过这种数据源天花乱坠的毛病，真正写代码前花十分钟统一字符格式绝对不吃亏。

写完字段后，还要出一张专题图。ArcGIS Pro里可以用ArcPy创建图层和配色，也可以提前做一个符号化图层模板，写好结果字段之后直接把图层符号刷新到对应级别。对大多数学过规划、但不是专业开发的人来说，最省事的方式反而是把成果先输出成要素类，然后在Pro里手动套一个做好的图层文件.lyr。因为级别分类只有固定几类，手动配置一次颜色，以后每次跑完数据刷新一下符号系统就能直接用，不必把所有东西都自动化。

4. 实操过程中的常见问题与排查记录

4.1 “范围不一致”导致叠加后大量漏算

我最早遇到的高频问题，就是评价单元和限制因子数据范围不一致。看起来两个图层都在同一个区域，但打开后有的大、有的小，相交结果自然会对不上。更隐蔽的一种情况是坐标系一致但空间参考定义不一致，比如一个图层是CGCS2000_3_Degree_GK_Zone_39，另一个被误定义成CGCS2000_3_Degree_GK_Zone_40，ArcGIS叠加上去的时候不做强制报错，但结果会偏得离谱。

所以脚本前置检查环节里，我建议加上坐标系的硬校验：

sr_units = arcpy.Describe(unit_fc).spatialReference for item in restrict_layers: sr_item = arcpy.Describe(item["fc"]).spatialReference if sr_item.name != sr_units.name: arcpy.management.Project(item["fc"], item["fc"] + "_proj", sr_units)

关于范围不一致，还要提醒一点：如果限制因子只是覆盖评价单元的一部分，比如只有东部区域做了水源评价，西部没有该图层覆盖，在叠加时西部单元因子的对应位置不会有记录。业务上，这部分应视为“没有该限制因子”还是“数据缺失”，一定要提前和业务方确认清楚，不然地图上会出现大片“无限制区”，可能误导最终结论。

4.2 Intersect结果字段重名导致的属性错位

多个限制图层做Intersect时，如果这些图层本身含有重复的字段名，ArcGIS会自动给重名字段加后缀，比如LEVEL_1、LEVEL_2。如果脚本里直接写死了字段名LEVEL，在第二个及以后的限制图层上就会取不到值，返回空或报错。

碰到这种情况，一个比较稳妥的方法是做Intersect前，先把所有限制图层的字段精简成统一命名，比如ECO_LEVEL、WAT_LEVEL、GEO_LEVEL。这样相交结果不会冲突，后面的统计代码也直白。ArcGIS的arcpy.management.AlterField可以改写字段名，但图层之间可能还要遵循数据源规范不能随便改字段名，这时在内存中复制一份精简版本则更安全。

4.3 处理几千上万个图斑时性能太差怎么办

这个工具如果用桌面环境一步步跑，处理小数据量没有问题，但遇到大面积图斑、多个限制因子密集分布时，性能会明显下降。我第一次拿全市域网格数据测试时，Intersect跑了几十分钟还没结束，当时第一反应是代码死循环了，后来检查才发现是数据本身包含大量非常碎的小面，而且在默认gdb里写中间结果，磁盘IO比较慢。

提升性能有几个有效措施。一是把中间结果写到in_memory工作空间，减少磁盘写入；二是对限制因子和评价单元先做范围过滤或字段裁剪，只分析真正需要的范围；三是在运行前先做一次arcpy.management.RepairGeometry，避免几何错误导致Intersect反复尝试；四是如果数据量实在太大，可以分块处理，按评价单元编码范围或者空间分区切成几个子集分别跑，再把结果合并。

我个人的经验是，ArcGIS Pro里用in_memory能换来几倍的性能提升，但要注意代码结束时把这些临时数据清掉，否则内存占用会一直往上涨。另外，如果工具只跑一次，无所谓后台还是前台；如果要在软件界面上循环测试几十次，建议开启后台地理处理，把界面上的等待时间省下来。

4.4 常见报错：许可、安装与版本问题

做ArcGIS二次开发时，环境问题有时比业务逻辑问题更让人烦躁。经常碰到的一种提示是You are not licensed for ArcGIS for Desktop Advanced，出现这类提示的原因五花八门，可能是Desktop许可级别不够，也可能是扩展模块没有单独启用。在Pro里要检查“设置—许可”是否包含需要的扩展模块，如果用到空间分析或者高级编辑工具但没有授权，ArcPy调用到相应工具时就会在运行中途报错，而不是在脚本开头就提示。

还有一类更打击人的报错发生在安装阶段，比如安装过程中出现Assembly component 0x80070005和Error 1935。这种错误一般跟ArcGIS本体关系不大，更多是操作系统的VC++运行库缺失、.NET Framework补丁没有装全，或者操作系统用户权限不足。遇上这类问题先别急着反复重装软件，先把系统补丁和运行库装齐，然后用管理员身份运行安装程序，成功率会高很多。有时候杀毒软件或安全策略会拦截组件注册，装到一半报错退出，这时候临时关掉防护再装一次也能解决。

排查环境类问题，最忌讳的就是只凭报错信息中的一两个关键词去查，很多错误提示是通用的，比如0x80070005本质是“拒绝访问”，并不能说明具体哪个文件或注册表项出了问题。我的建议是先看安装日志，找到第一个报错发生的位置，然后针对性地修那个组件，比盲目卸载重装有效得多。

5. 把工具做得更通用：配置化思路与个人经验

5.1 规则和因子从写死改成配置化

工具开发到后期，业务方最常提的一句话是：我们规则优化了一下，你帮我把工具里的判断逻辑改一改。如果判断逻辑全写在代码里，改一次就要重新发布一次，开发方和业务方来回拉扯非常累。后来我把因子类型和判断矩阵全部抽到了配置表里，代码基本不再改动。

配置表有两张。第一张是图层与因子配置表，记录限制因子名称、源数据路径、级别字段、是否参与判断；第二张是级别组合规则表，记录什么组合情况输出什么综合限制级别。脚本每次运行时先读配置表，再动态组装叠加图层和判断规则。效果很明显，业务方再提调整需求时，我通常半小时内就能给出新的运行结果，而不是被绑定在开发环节里。

这种做法也方便结果追溯。底稿数据、配置表版本、ArcPy脚本版本全部留档，将来评审人员问“为什么这个地块是三级限制”，可以倒推回去，看到底是哪个因子因为什么规则触发了升级。

5.2 从矢量扩展到栅格评价单元

有些评价场景里，评价单元不是地块面，而是规则网格或像元。比如某些生态敏感性评价，需要把研究区域划分成固定大小的网格，每个网格输出一个综合限制级别。用ArcGIS栅格分析做这类计算也和矢量工具的底层逻辑类似，但需要在叠加前把矢量限制因子转成栅格并确保所有栅格的像元大小、范围完全一致，否则后续重分类会出问题。

栅格工具里经常出现的ERROR 010568，多数就出在掩膜提取时，目标栅格和掩膜栅格的范围或分辨率不一致。解决办法是按需求预先设置arcpy.env.extent和arcpy.env.snapRaster，把掩膜栅格设为基准，让所有中间栅格都对齐到同一个像元网格上。处理“arcgis更改像元个数”其实也走同样的路径，用重采样工具调整像元大小，再配合范围约束生成统一规格的栅格。总之，栅格方案对数据一致性要求更高，因为一个像元的偏移就可能导致无数网格的级别错位。

5.3 我对这类工具开发的经验体会

做了几个类似的ArcGIS二次开发小工具之后，我最大的体会是：空间分析类的工具开发，算法本身通常不是瓶颈，数据脏、规则乱、需求反复变才是真正消耗时间的地方。

所以我现在开发这类工具时，会先花至少三分之一的时间去摸数据和理清业务规则，把每个限制因子的数据来源、字段含义、更新频率、取值口径都整理成一张表，再开始写代码。代码尽量保持结构简单，把多层判断逻辑下沉到独立的规则解析函数中，宁可多写一点配置文件，也不要在业务判断代码里堆砌一堆分支条件。

另一个经验是要学会利用ArcGIS生态里已有的能力。很多人一提到“二次开发”就想着从头造所有轮子，其实很多问题用arcpy自带的地理处理工具就能解决。评价单元的几何检查、属性汇总、坐标系转换，这些基础能力ArcGIS已经很成熟，脚本要做的更多是把它们有效串联起来，真正的人工作业量其实都花在数据清洗和规则确认上。

最后分享一个实用的小技巧：脚本工具越是后期越要保持单次运行的确定性。我的脚本里永远会在开头生成一个带时间戳的运行目录，把每次跑批的中间结果、配置表副本和日志都单独记录到那个目录下。一旦业务方后来提出“上次结果和这次结果为什么不一样”，我都能打开当时的目录还原现场。这个习惯在反复修改规则的项目里救过我很多次，虽然会占点磁盘空间，但相比反复排查数据差异的时间成本，这点空间投入太值了。