1. 填充看着只是一块阴影落地却是一整套数据链绝大多数人第一次意识到填充是个技术活都是在改别人的图纸时图层里明明有填充屏幕上要么一片空白要么密得像块黑板选中之后改比例图案位置又整体跑偏想把它对齐到某个墙角只能靠肉眼一点点挪。我在做CAD 填充增强插件的过程中反复被同一类问题绊住——大家默认填充是装饰性的随手一点就完事结果到了出图、审图、交付环节填充的图案定义、比例、角度、原点、边界关联性任何一项没管住都会演变成返工。这篇内容讲的就是围绕高效读取、编辑与批量创建填充图案这套能力插件该怎么做、坑在哪里、参数怎么定。适合三类人看一是天天画图、被填充折腾过的设计岗二是准备给自家团队做二次开发工具的技术岗三是对图纸数据自动化感兴趣、想搞清楚填充对象内部结构的读者。哪怕你只写脚本、不做完整插件中间关于 PAT 解析、边界闭合判定、事务分块的部分也能直接拿去用。先给结论填充不是一个图形对象而是一组图案定义 边界环 变换参数的复合体。你改任何一项另外两项的语义都可能随之变化。理解这句话后面 80% 的异常现象都有解释。1.1 原生填充命令到底卡在哪三处第一处卡在图案来源。原生填充对话框里能选的图案来自两类一类是平台内置的一类是外部图案定义文件。前者不可改后者要手动放到指定目录、手动刷新团队里换台机器就得重新配一遍。实际项目里经常遇到甲方指定的某类剖面线图案文件在别人电脑上你这边根本没有只能用近似图案凑交付时被挑出来。第二处卡在批量能力缺失。原生交互是拾取一个内部点→生成一个填充十个区域就点十次。一个楼梯详图、一个吊顶布置图动辄几十上百个封闭区域人工点选既慢又不一致——有人按一个方向选有人按另一个方向选最后图案原点各不相同图面看起来乱糟糟。这不是画图水平问题是工具没给出批量投放入口。第三处卡在编辑不闭环。改图案名称、改比例、改角度这些单独操作原生都支持但组合起来就散比例改完角度没跟着调原点没重设边界因为上游多段线被改而失效填充变成一堆孤立线。你想批量修一遍原生没有筛选出所有比例异常的填充这种入口。运营者真正需要的是三件事而不是更花哨的界面把外部图案稳定加载进来、把选中的填充按规则统一改掉、把一片闭合区域一次性填上。插件所有设计都该围绕这三点压缩操作路径。1.2 填充对象落库之后长什么样要写插件先得接受一个事实填充对象在数据库里存的不是画出来的那些线而是种子点 边界环 图案定义 变换参数。显示的时候由图形引擎按图案定义逐条推演线条位置所以它很省存储但也很脆——任何一项参数异常推演结果就离谱。我习惯把填充拆成下面这几块来看排查问题时也按这个顺序过一遍组成关键字段出问题时的典型表现图案定义图案名、图案类型预定义/自定义、线条角度与偏移图案名失效填充变实心或消失变换参数比例、角度、原点基准点图案密度突变、方向错、位置偏边界环外环 若干内环孤岛填充溢出边界、孤岛被填满关联性是否关联到边界对象边界改了填充不跟随或跟随错位显示/打印图层、颜色、透明度、填充显示开关屏幕可见、打印不见或反之这里最容易忽视的是原点。很多人改完比例就以为对齐了其实图案的排布基准是原点 比例 角度三者共同决定的。原点偏移 1 个单位在比例 100 的图案上就放大成 100 个单位的错位。我在插件里把原点做成显式可编辑项就是因为吃过这个亏批量处理时如果不统一原点同一张图上的剖面线完全无法衔接。1.3 三类真实场景决定了插件的功能边界场景一标准图库复用。某设计团队有一套内部图案库不同专业用不同图案表示材料。插件要做的就是扫描指定目录下的图案定义文件做语法校验把可用图案列表缓存下来供快速选择。这里的关键不是能读而是读错了要能报出来——图案文件一个字符写错整行定义就作废原生往往只给一句模糊提示。场景二存量图纸规范化。接手别人画了一半的图填充比例五花八门。插件需要能按图层、按图案名筛选批量把比例归一到某个值同时保持原点相对关系不乱。场景三批量生成。屋面、地面、墙面材料分格一次几十个区域。插件需要从一堆线里识别闭合环再按面积、图层做过滤最后分块创建。这块性能压力最大也是最容易把平台卡死的地方。2. 读懂图案定义文件语法、容错与解析器实现插件要高效读取绕不开图案定义文件通用叫法是 PAT 格式。这个格式极简几行文本定义一个图案族但极简也意味着容错空间小——没有校验、没有版本号错一个字就整行失效。2.1 一行定义里每个数字都有明确语义先看一个典型定义示意非真实示例*MY_PATTERN, 示例图案 用于示意线型 0, 0,0, 0,5, 10,-5 90, 0,0, 0,5, 10,-5 45, 0,0, 2.5,2.5, 8,-4, 2,-2逐字段拆以*开头的行是图案名 描述名字在前、逗号后是说明文字。名字里不能有逗号不能用保留字符。以;开头是注释行空行通常被忽略。定义行是逗号分隔的数字序列前四个是固定语义角度度、原点 X、原点 Y、ΔX沿线条方向的位移、ΔY垂直线方向的偏移之后是一组短线长度序列。短线长度序列里正数 画线段负数 留空0 打一个点。正负交替形成虚线节奏。关键在 ΔX 和 ΔY 的理解。ΔY 决定相邻平行线的间距ΔX 决定同一条线上下一个循环起点的偏移。很多人以为 ΔX 恒为 0其实它在做错缝效果时是核心参数——比如砖砌图案的错缝就靠 ΔX 与 ΔY 的配合。还有一个容易被忽视的点角度是逆时针为正而且它是线条方向角不是旋转整个图案的角。如果你想让某个图案整体转 30 度正确做法不是改定义里的角度而是在填充对象上改旋转角。这两者混用图案会彻底走形。2.2 图案加载失败的五种典型原因我在实际使用中统计过图案选了没效果基本落在这几类文件末尾缺空行或者最后一行被截断。有些编辑器保存时不留结尾换行解析器按行读到最后一行废数据整段丢弃。逗号用了中文全角或者数字里混了空格。肉眼几乎看不出来解析直接失败。角度写了负值或超过 360。部分实现不归化导致线条方向算错图案看起来消失——其实是画到了很远的地方。ΔY 写成 0。垂直线偏移为零意味着所有平行线重合屏幕上就是一条线用户以为加载失败。图案名重复。同名定义在后加载的会覆盖前者容易造成我明明改了文件怎么没变化的错觉。注意解析图案定义时一定要把行号 原始行内容一起记进错误日志。只报某某图案解析失败等于没报排查时你还是得回去逐行看。2.3 写一个能吃脏数据的解析器解析器不需要多聪明但必须永不抛异常、永不吞错误。我的做法是两段式先整文件按行切分再逐行做宽松解析失败的行走收集器最后一次性汇报。// 结构化解析接口名按各平台实际替换 public sealed class PatternDef { public string Name; public string Description; public ListPatternLine Lines new ListPatternLine(); } public sealed class PatternLine { public double Angle, OriginX, OriginY, DeltaX, DeltaY; public Listdouble Dashes new Listdouble(); } public static ListPatternDef Parse(string[] rawLines, Liststring errors) { var result new ListPatternDef(); PatternDef current null; for (int i 0; i rawLines.Length; i) { var line rawLines[i].Trim(); if (line.Length 0 || line.StartsWith(;)) continue; if (line.StartsWith(*)) { var body line.Substring(1); var idx body.IndexOf(,); current new PatternDef { Name idx 0 ? body.Trim() : body.Substring(0, idx).Trim(), Description idx 0 ? : body.Substring(idx 1).Trim() }; result.Add(current); continue; } if (current null) { errors.Add($第 {i 1} 行定义行出现在图案名之前 - {line}); continue; } var parts line.Split(,); if (parts.Length 5) { errors.Add($第 {i 1} 行字段不足 5 个 - {line}); continue; } var nums new Listdouble(); bool ok true; foreach (var p in parts) { if (!double.TryParse(p.Trim(), NumberStyles.Float, CultureInfo.InvariantCulture, out var v)) { ok false; break; } nums.Add(v); } if (!ok) { errors.Add($第 {i 1} 行存在非数字字段 - {line}); continue; } var pl new PatternLine { Angle nums[0], OriginX nums[1], OriginY nums[2], DeltaX nums[3], DeltaY nums[4] }; for (int k 5; k nums.Count; k) pl.Dashes.Add(nums[k]); if (Math.Abs(pl.DeltaY) 1e-9) errors.Add($第 {i 1} 行ΔY 为 0图案会退化成单线 - {line}); current.Lines.Add(pl); } return result; }这里有几个刻意的设计取舍值得说明用 InvariantCulture 解析数字。如果跟随系统区域设置某些环境下小数点会被当成千分位0.5解析成5这种 bug 极难复现因为只在你同事的机器上出现。不因为一行错就放弃整块图案。丢掉错误行、保留有效行比整块丢弃更实用——很多图案只有一根辅助线写错了丢掉一根完全能接受。ΔY 为 0 只警告不报错。有些特殊图案确实会刻意用零间距硬拦下来会误伤。解析完还要做一次缓存。图案列表的读取频率远高于变更频率我一般按文件路径 最后修改时间 文件大小做缓存键文件一改就失效。这样启动时扫一遍之后都是内存命中切图案面板基本无感。3. 编辑已有填充改什么、按什么顺序改、什么时候不该改编辑这块的难点不在 API 调用而在顺序和副作用。填充的图案、比例、角度、原点、边界是相互耦合的随手一改图面就变形。3.1 先筛对象再谈修改批量编辑的第一步永远是把目标集合收窄。我的筛选维度一般是四层类型层只取填充对象别混进多段线、面域。图层层按图层名或图层过滤器圈定范围比如只处理剖面线图层。图案层按图案名含通配筛选比如所有*CONC*。参数层按比例、旋转角、是否关联做范围判断比如比例小于 1 或大于 500 的异常值。第四层是最有价值的。我在实际项目里经常看到同一张图上比例从 0.5 到 2000 都有来源是不同人从不同底图复制粘贴。这种图不改打印出来一定出问题。// 收集阶段只做读操作快速、无副作用 var targets new ListObjectId(); using (var tr db.TransactionManager.StartTransaction()) { foreach (var id in selection.GetObjectIds()) { if (!id.ObjectClass.IsDerivedFrom(hatchClass)) continue; var h (Hatch)tr.GetObject(id, OpenMode.ForRead); if (h.Layer ! layerName) continue; if (!PatternMatch(h.PatternName, CONC*)) continue; if (h.PatternScale 1.0 || h.PatternScale 500.0) targets.Add(id); } tr.Commit(); }先收集、再修改是我坚持的两段式。原因很直接一边遍历一边改容易在同一事务里反复触发重算遇到大图纸直接卡死而且一旦中途异常你不知道改到哪了。收集完打印一份清单让用户确认也避免了一键全改带来的不可逆破坏。3.2 改图案、改比例、改角度、改原点的正确顺序顺序错了会出现改完看起来更乱的假象。我验证下来比较稳的顺序是先设图案定义图案名或自定义定义再设比例再设旋转角最后设原点必要时重算/刷新边界与显示。为什么图案必须最先设因为不同图案的基准偏移量不同图案换了但比例和原点沿用旧值密度和排布就是错配的。为什么原点要放最后因为原点是在当前比例和角度下的基准点先设原点后改比例等于用一个旧坐标系去套新尺度图案会整体漂移。foreach (var id in targets) { var h (Hatch)tr.GetObject(id, OpenMode.ForWrite); h.SetHatchPattern(HatchPatternType.CustomDefined, MY_PATTERN); // 1 图案 h.PatternScale 50.0; // 2 比例 h.PatternAngle Math.PI / 6.0; // 3 角度弧度 h.Origin new Point3d(baseX, baseY, 0.0); // 4 原点 h.Associative true; // 5 关联 }角度单位是弧度这是最常见的换算事故。面板上填 30度直接赋进去实际得到 30 弧度相当于 1719 度图案转得莫名其妙。我在面板层统一做deg * Math.PI / 180.0转换并把这个约定写进配置文件的注释里。3.3 关联性丢失这是设计缺陷还是必然代价填充的关联意味着边界对象被修改时填充跟着变。听起来是好事但实际项目里经常变成麻烦上游多段线被夹点拖了一下填充没跟着重算却仍标记为关联看着像关联的、其实已经错位。更糟的是批量重建边界时关联标志没清干净同一个填充被重复刷新性能直接崩。我的处理策略是按场景分两套逻辑出图阶段一律关闭关联。出图要的是确定的图形状态不需要跟随能力关了关联反而稳定复制、镜像、块插入都不出幺蛾子。方案阶段保留关联但每次批量编辑后强制做一次边界有效性检查——判断每个环的顶点数量、闭合误差是否在容差内不合格的标记出来让用户手动处理。边界重建的成本比想象中高。重建本质上是拿边界几何重新求一次环对直线和多段线很快对样条、带弧的连接、自相交轮廓就很容易踩到退化情况。我的经验值是单个填充的边界顶点数超过 2000、或者环里含超过 4 个方向反转重建就要谨慎宁可提示用户简化几何。3.4 撤销栈与文档锁不做就会出奇怪的错批量改几百个对象时有两个细节不做会出问题一是把整批操作包在单个事务里。用户按一次 CtrlZ 应该整体回退而不是退 300 次。事务粒度按一次用户意图划分这是最基本的体验要求。二是多文档场景加文档锁。如果插件跑在后台或面板线程里操作非当前文档不加锁会直接抛异常或者静默失败。哪怕当前是单文档加锁的开销也可以忽略我习惯性都加上。using (var docLock doc.LockDocument()) using (var tr db.TransactionManager.StartTransaction()) { // 批量修改 tr.Commit(); }提示事务包太大也有代价——极端情况下内存会堆高。我的做法是单批上限 500 个对象超过就分成多个事务但每个事务外再包一层操作组让撤销仍然按组生效。这个折中在实测中比极端的大事务稳。4. 批量创建从一堆乱线到能填的闭合环批量创建是这个插件里最显本事的部分也是最容易翻车的部分。核心链路是候选几何 → 闭合环 → 孤岛关系 → 过滤条件 → 分块创建。每一步都要有明确的失败出口。4.1 闭合环判定的容差怎么定图里的线很少是完美接上的端点差个 0.001 到 0.01 个单位非常常见。判定闭合必须带容差容差定多少直接决定识别率。我的经验做法是双阈值端点吸附容差图纸单位下取1e-3到1e-2取决于图纸精度习惯。公制建筑图取 0.5mm 就够机械图往往要更小。最小环面积过滤掉因为容差误判形成的细缝环。面积低于图纸图框面积的万分之一直接丢弃。判定算法本身如果平台 API 提供了由曲线集合生成闭合区域的能力优先用平台实现省事且兼容性好。没有的话就自己写把端点按容差量化成网格坐标比如乘以 1000 取整用哈希表把端点相同的曲线串起来再从每个未访问的曲线出发做深度优先串联回到起点即为闭环。// 端点量化后建邻接简化示意 long Key(Point3d p, double tol) (long)(Math.Round(p.X / tol) * 73856093L) ^ (long)(Math.Round(p.Y / tol) * 19349663L); var buckets new Dictionarylong, Listint(); // 端点键 - 曲线索引用异或拼哈希会有碰撞我在正式实现里换成了(long)x * 1000003 (long)y这种可逆组合实际更稳。碰撞的后果是两条毫不相干的线被当成相连生成一个跨越整张图的巨大环——这种 bug 排查起来极其费劲因为生成结果看起来是闭合的只是范围离谱。串环时还要处理自相交和重复边。前者如果平台 API 能处理就直接交给它后者一定要去重否则同一个环会被生成两次。4.2 孤岛检测与填充样式选择环识别出来之后要判嵌套关系谁在外、谁在内。判定方法是点在多边形内测试用射线法或者绕数法实现对每个环取一个代表点测试它在其他环内的次数奇数为内环、偶数为外环。这一步决定了填充会不会把小洞也涂满。填充对象支持三种孤岛样式样式效果适用场景普通嵌套交替每深一层填充状态翻转大多数建筑、机械剖面外部只填最外层内部全部挖空有大量开孔的板件忽略内环全部忽略整块填满快速示意不看细节我默认选普通因为它最符合直觉外环填、内环空、内环里的内环再填。但要注意孤岛判定依赖环的包含关系正确如果前一步的环识别把两个不相交的环误判成嵌套填充结果会是一块莫名其妙的镂空。所以我在创建前会输出识别到 N 个外环、M 个内环的统计让用户先看一眼数字对不对再点确定。注意种子点填充内部点的位置别随手取几何中心。带内环的形状几何中心很可能落在空洞里导致填充生成失败。稳妥做法是先用外环做一次内缩点计算再用点在多边形内测试验证它不在任何内环里。4.3 性能为什么一次创建 2000 个填充会卡死填充创建的开销主要在两项边界环的重算和图形数据库的提交。前者是 CPU 密集后者是 IO 和内存密集。两者叠加一次性全上必然卡。我在实测里试过三档策略效果差别很明显策略2000 个填充耗时稳定性全部一个大事务明显卡顿内存峰值高易超时、失败后全部丢弃每个填充一个事务慢提交次数过多稳定但慢分块事务每 100 个折中耗时可接受稳定失败只丢一块分块大小我最终定在 80 到 120 之间按机器性能微调。分块时还要考虑关联性——同块内的填充如果互相依赖同一条边界最好放同一块避免边界对象在两次重算之间处于中间态。另外有两个容易忽略的性能点填充显示模式影响极大。处理过程中把填充显示临时切到简化模式只显示轮廓处理完再切回来图形刷新量能降一个数量级。图层直通关闭。如果给填充设置非直通的图层状态图形引擎的计算量会上升。批量创建时统一用直通创建完再按需调整。4.4 过滤条件决定结果可用度批量创建最大的问题不是填不上而是填太多。一张图里闭合区域成百上千全填上等于把图涂黑。所以过滤条件的设计比创建逻辑本身更重要。我一般提供这几个维度面积区间低于下限的忽略缝隙、误判高于上限的单独提示可能是图框本身。图层归属只处理指定图层上的边界线这是最有效的降噪手段。几何类型只接受多段线、圆、椭圆、闭合样条排除散乱的单线组合。空间范围只对当前视图或指定矩形范围内的区域生效便于分区分批处理。真正落地的做法是预览 确认。先在内存里算出所有候选环用一个临时图层画出轮廓并标注序号让用户看清再执行。这一步多花的时间能省掉后面成倍的返工。5. 实测里最容易翻车的六个现象下面这些现象我在不同图纸、不同版本、不同机器上都撞过排查链路比结论更有参考价值。5.1 填充看得见但选不中先别怀疑插件。按这个顺序过一遍打开选择过滤器确认填充是否被选择预览排除检查填充所在图层是否被锁定——锁定图层上的对象默认不可选这是最高频原因检查填充是不是块内对象块内对象要在块编辑状态或通过嵌套选择才能选中检查图形是否是外部参照内容外部参照本身不可直接编辑。我在实际操作中吃过一次教训写了半天的批量编辑脚本跑完一个对象都没处理最后发现目标图层是锁定的而脚本里没做锁定检测。后来我在收集阶段加了一条跳过锁定图层并计入统计的逻辑日志里明确写跳过 N 个锁定图层对象问题就一目了然了。5.2 屏幕上很淡打印出来一片黑这一类几乎全是比例与打印样式的问题。排查顺序图案比例是否过小。比例 1 的密集图案在 A1 图上打印视觉上就是实心块。判断方法把比例放大 10 倍看图案是否清晰可辨能辨认为止。填充分辨率/线条密度设置是否过高。打印样式表是否把填充颜色映射成了高覆盖率颜色。是否用了实体填充而非图案填充。比例该怎么定我的经验公式是先确定图纸单位与出图比例再按目标线间距反推。假设你要在打印图上看到大约 1.5mm 的线间距出图比例 1:100那么图纸单位mm下的间距应该是 150若图案定义里的 ΔY 是 3则比例 150 / 3 50。这个算法比瞎试快得多而且能保证同一套图纸里所有填充视觉密度一致。5.3 打开别人的图填充变成空白或纯实心跨版本、跨机器打开时图案定义文件不在本机填充会降级显示。排查路径检查填充的图案名是否还在检查本机的图案搜索路径是否包含该定义文件检查图案名是否与内置图案重名冲突检查填充是否被图案不可用降级为实体填充。这一步我做插件时专门加了图案依赖检查功能扫描全图填充提取所有图案名与本机可用图案列表做差集差集里的名字列出来提示用户。这个功能救过好几次交付前的图。5.4 批量处理跑到一半卡住大概率是事务过大 图形刷新过频。处理方式处理前挂起图形刷新处理完统一刷新分块提交每块之间不主动刷新关闭不必要的提示和对话框处理过程中禁用自动保存避免和大事务抢 IO。有个隐蔽点某些场景下填充创建会触发空间索引重建如果图纸里对象极多每次重建都很慢。判断方法是用分段计时看时间是不是花在提交阶段而不是循环体里。如果是说明瓶颈在索引只能靠减少提交次数和分块来缓解。5.5 填充边界跟着动了但图案没动这是关联标志与实际几何不同步的典型表现。原因通常是边界对象被程序化修改过但没触发填充的重新计算。修复方法是在修改边界后显式对相关填充做一次边界重算或者干脆清掉关联标志、按新边界重建。我的建议是程序化改几何时别指望自动同步。要么在改完统一做一次全图填充校验要么在修改时就把对应填充的关联解除改完重建。指望引擎自动帮你搞定十次有三四次会漏。5.6 图案明明定义对了看起来还是错检查三件事角度单位度 vs 弧度前面提过最常见。旋转方向屏幕坐标系与几何坐标系的 Y 轴方向差异导致镜像效果。原点基准原点是在世界坐标系下还是用户坐标系下。如果用户坐标系被旋转过你按世界坐标设的原点会跑偏。我现在的做法比较笨但有效面板上放一个预览小方块实时画出当前参数下的图案样式用户调参数时一眼就能看出对不对不用反复点确定再看图。6. 让插件能长期用下去配置、日志与灰度投放工具能不能活过三个月看的不是功能多少而是出错时能不能快速定位、改动时敢不敢动。6.1 哪些参数该暴露哪些必须锁死我的原则是影响图纸结果的暴露影响内部实现的锁死。该暴露的图案搜索路径、默认比例、默认角度、默认原点策略、分块大小、容差阈值、过滤条件预设。这些是用户在不同项目里必须调整的。必须锁死的数字解析的区域设置固定不变的区域无关解析、角度单位换算方式、事务边界策略、缓存失效规则。这些一旦暴露用户配错了就是灾难而且错误现象极具迷惑性。配置格式我倾向用纯文本键值对不用数据库、不用二进制。理由是版本升级时好做兼容出问题时用户能直接把配置文件发过来看。6.2 日志该记什么日志的价值在于事后能还原现场。我的最小集合是操作类型、目标数量、成功/失败计数、失败原因分类、耗时、配置文件版本、图案库版本。每条失败记录必须带对象句柄 具体原因否则等于没记。[2024-xx-xx 10:21:03] BatchEdit Hatch filter: layer剖面线, patternCONC*, scale1 or scale500 matched412 changed407 skipped5 skip reasons: { lockedLayer: 3, invalidBoundary: 2 } elapsed1842ms chunkSize100这个格式我在实际排查里用过很多次一眼就能看出是过滤条件写错了还是对象本身有问题。6.3 灰度投放先小范围跑再全量推插件上线别指望一次到位。我的做法是分三步第一步只读模式先放出去。用户能扫描、能预览、能出报告但不能改图。这一步收集的是识别准确率和性能数据。第二步单对象编辑。允许改单个填充收集参数换算和边界重建的失败案例。第三步批量能力。这时候容差、分块、过滤条件都已经被真实数据验证过了出问题的概率大幅下降。我自己踩过最疼的一次是跳过前两步直接上批量结果容差设得偏大把一个本该独立的环和旁边一条线串在了一起生成了一个横跨半张图的填充。用户撤销之后不敢再用那个版本的信任度基本归零。从那以后我再没跳过只读阶段。6.4 一个容易被低估的功能图案库自检最后补一个实用功能。插件启动时做一次图案库自检输出四类信息可用图案数量、解析失败的行数与位置、重名图案、以及图纸里用到但本地缺失的图案名。这四个数字放在面板角落平时没人看一旦出问题就是最快的第一手线索。自检的执行成本很低——只读文本、只解析行一千个图案文件也就几百毫秒。我通常把它做成异步启动后后台跑完成后在状态栏闪一下提示。用户不会被打扰但需要的时候信息已经在那儿了。实际用下来填充这块的复杂度和它的存在感完全不成比例——大家觉得它就是画阴影实际上它牵扯到图案定义语法、几何闭合判定、坐标变换、事务性能、跨环境依赖一整套东西。我这套插件做到现在功能上其实没多少花样真正让它好用起来的是那些笨功夫解析器不吞错、批量前先预览、日志带句柄、容差写死在配置里、上线分三步。如果你也在做类似的工具建议先从只读检查这一个功能做起它不改变任何图形但能让你在最短时间里看清一张图纸里的填充到底有多乱。
