做制图相关模块开发这么些年我收到最多的需求反而不是那种花里胡哨的新功能而是把一件“听起来特别简单”的事做到真正好用。最近刚落地的一个需求就非常典型删除指定名称的图纸页名称为空就全部删除。需求正文就这么一句话评审会上甚至没人觉得它值得单独讨论。可真到设计接口、写删除逻辑、跑边界测试的时候你会发现里面藏着一堆不大不小却很致命的细节动态索引错位、只读页面、全删之后要不要建默认页、撤销怎么合并……一个没想清楚上线就是事故现场。这篇文章我就围绕这个一句话需求把从需求理解到接口设计、再到核心实现和踩坑排查的完整过程记录下来。如果你在做制图平台、CAD二次开发、图纸管理系统或者任何带“多页图纸”概念的工具模块这篇应该能帮你少走几天弯路。1. 一句需求背后的真实场景图纸批量清理到底解决什么问题先说业务背景。制图模块里的“图纸页”跟文档系统里的“页”不是一个概念——它更像一套图纸里的独立画布每张页承载一个视图、一个部件或一个工艺环节。一套完整的产品图纸动辄几十页上百页而实际生产过程中真正需要交付的可能只有其中的一部分。需求侧的典型场景是这样的工程师从模板工程出发一键生成了一套多页图纸然后要在归档前把其中的临时页、试验页、废弃方案页全部清掉。没有批量删除功能之前使用者只能一页一页地打开、选中、删除操作路径长还容易漏。更麻烦的是“全图清理”场景——项目推翻重来整张图纸要重置成空壳状态逐页删除可能要花上十几分钟。所以“指定名称删除 空名称全删”这个组合本质上是在补图纸页生命周期管理里最基础、也最高频的一块短板。这个需求真正服务的人群有两大类终端使用者制图工程师、工艺人员。他们要的是“输入框留空一键重置”的直觉操作不需要理解任何技术概念。二次开发者/平台集成方需要通过API批量操作图纸页例如在自动出图流程中程序生成若干临时页后统一清理。从产品语义上讲这其实是在定义一种“范围选择”的行为给一个名字就删一张或一类页不给名字就删所有页。听上去像是在函数入口加一个分支就能搞定但真正落到代码上首先要解决的并不是“怎么删”而是“怎么定义这两个分支的边界”。整件事的复杂度不在标题本身而在于标题没有写出来的部分删除是不可逆操作必须考虑确认、保护、撤销图纸可能被锁定页码存在动态索引问题删除全部之后图纸不能处于非法状态。这些才是本文想重点展开的内容。2. 接口设计指定名称与空名称两条分支的语义边界动手写代码之前我花了半天时间把接口语义理清楚。这一步看起来很“务虚”但恰恰是后面不返工的关键。2.1 一个函数还是两个函数标题需求表面上是两个功能但我的建议是设计成一个接口用参数区分。原因有三第一两种操作的业务意图一致都是“清理图纸页”拆成两个函数会让调用方多一次选择成本第二交互入口往往是一个输入框 一个删除按钮一个接口天然匹配一个入口第三后续如果需求演变成“名称支持通配符模糊匹配”一个接口的兼容成本反而比两个接口低。函数签名大致是这样/// summary /// 删除图纸页。 /// sheetName 为空或空白字符串时删除全部图纸页否则删除指定名称的图纸页。 /// /summary /// param namesheetName图纸页名称可空/param /// returns删除结果包含成功删除数量、跳过数量和未匹配信息/returns DeleteSheetResult DeleteSheets(string sheetName);这里有一个细节接口注释里我特意写了“为空或空白字符串”而不是“为空”。这意味着调用方传null、空字符串、或者一串肉眼看起来是空格的 都会被当作“全部删除”处理。2.2 空白字符串到底算不算“空”这个决定看起来小实际影响体验。交互层最容易出现的情况是用户打开对话框手抖在名称框里敲了几个空格或者输入法残留了一截空格然后点了删除。如果程序把空格当成真实名称去匹配结果就是“找不到这张页”用户一脸懵如果程序把空格统一归一化为空就会走全删逻辑——这两个结果差别巨大必须二选一并形成产品共识。我的选择是空白字符串统一视为空执行全量删除。理由很简单现实中不太可能有人给图纸页命名成三个空格误操作的概率远大于合理需求。为了降低误触风险全量删除前需要弹二次确认框这个后面单独讲。调用方如果确实要删除一张名字里带空格的页可以在传参前先走转义或精确匹配的专用接口而不是让通用接口去猜。2.3 匹配语义精确匹配还是模糊匹配标题说“指定名称”我理解为精确匹配不涉及通配符。但也遇到过一个实际案例有人希望输入“A3”能把“A3-总装图”“A3-零件明细”全删掉。这属于模糊删除的范畴语义上更危险——名字匹配范围不可控很容易误删。我在第一版实现里只做精确匹配大小写不敏感原因后面细说模糊匹配留到后续版本再考虑。如果真要做也建议设计成显式的通配符语法比如A3*而不是默认包含匹配。默认模糊 默认误删这是删除类功能最忌讳的。2.4 返回值不是布尔值这么简单删除结果对象里除了成功/失败还要能回答三个问题本次删了几张页有哪些页因为受保护不能删用户输入的名称没匹配到任何页时怎么提示这些都直接影响交互层的反馈文案。尤其是“名称未匹配”的情况不能简单弹一个“删除失败”就完事——正确做法是从结果里取出NotMatched字段明确告诉用户“未找到名称为XXX的图纸页已取消操作”同时把操作留在撤销栈里。我把接口语义理清楚之后后续实现就顺了很多。下面直接进代码链路。3. 核心实现从参数校验到循环删除的完整链路代码实现分五个步骤每一层解决一类问题。我以 C# 风格的代码演示但逻辑本身跟语言无关换成 C、Python 或 TypeScript 都适用。3.1 第一步参数归一化所有入口参数先走一遍归一化确保后面的逻辑不用到处判断nullpublic DeleteSheetResult DeleteSheets(string sheetName) { // 归一化null、、全空格 统一转换为 string.Empty string targetName string.IsNullOrWhiteSpace(sheetName) ? string.Empty : sheetName.Trim(); var allSheets drawingDocument.GetAllSheets(); var toDelete new ListSheet(); int skippedByLock 0; if (targetName string.Empty) { // 分支二全部删除 toDelete allSheets.Where(s s.CanDelete).ToList(); skippedByLock allSheets.Count - toDelete.Count; } else { // 分支一按名称删除 // 名称比较统一走 OrdinalIgnoreCase避免大小写问题 toDelete allSheets .Where(s string.Equals(s.Name, targetName, StringComparison.OrdinalIgnoreCase)) .Where(s s.CanDelete) .ToList(); skippedByLock allSheets.Count(s string.Equals(s.Name, targetName, StringComparison.OrdinalIgnoreCase) !s.CanDelete); } ... }这段代码有两点值得解释。第一Trim()写在归一化里意味着传入的名称前后的空格会被去掉这是为了配合交互层输入框的习惯第二先用Where筛选出待删除集合再统一执行删除而不是边遍历边删——这个设计选择留到第4章重点讲。3.2 第二步执行删除并处理受保护页面筛选出待删除集合后进入删除循环。这里需要考虑一个操作细节要不要在删除前做二次确认我的建议是只要走到“全部删除”分支必须二次确认“指定名称删除”且匹配数量较少时可不确认但会在结果反馈里列出被删页面名称。// 全量删除前弹确认框交互层做API 层不强制 bool isFullDelete targetName string.Empty; if (isFullDelete !userConfirmed()) { return DeleteSheetResult.Cancelled(); } // 执行删除收集被删名称用于日志/撤销 var deletedNames new Liststring(); drawingDocument.StartTransaction(); // 开启事务组保证撤销合并成一步 foreach (var sheet in toDelete) { deletedNames.Add(sheet.Name); sheet.Delete(); } drawingDocument.CommitTransaction(); return DeleteSheetResult.Success( deletedCount: deletedNames.Count, skippedByLock: skippedByLock, deletedNames: deletedNames); }事务组这段很重要。在不少制图内核里如果不主动包一层事务批量删除会被记录成 N 步撤销操作——用户删了50页就要按50次CtrlZ才能恢复那体验就成灾难了。事务组能把整批删除变成一个撤销步这也是“批量函数”跟“单个函数”在底层实现上的重要区别。3.3 第三步全部删除后重建默认页这里有一个非常容易被新手忽略的坑很多制图平台不允许图纸集为空。你把所有页都删了保存时直接报错甚至整个文档损坏。解决办法是在全量删除后自动新建一个默认的空白页。if (isFullDelete drawingDocument.GetAllSheets().Count 0) { var defaultSheet drawingDocument.CreateSheet(DEFAULT_SHEET_NAME); defaultSheet.SetAsActive(); result.NewSheetCreated true; }默认页的名字建议叫“页1”或“Sheet1”跟平台新建空白图纸时的默认命名保持一致。这样用户看到的结果是点了全删图纸集被清空然后多了一张干净的空白页——整个图纸集仍然处于可编辑的合法状态不会出现打开文件就报错的情况。还有一个细节如果全部删除后一张新页都没有建很多平台的导出、打印、图纸集管理功能会直接异常。你在做这个功能时务必先去查目标平台的文档确认“图纸集是否允许为空”。如果允许为空那重建默认页做成可选配置就行如果不允许这一步就是必须的。3.4 第四步返回结构化结果最后把DeleteSheetResult组装好返回给调用层。这个结果对象至少要包含四个字段是否被取消、成功删除的数量、因锁定等原因跳过的数量、实际被删除的图纸页名称列表。有了这些数据交互层才能给出精确的文案比如“已删除3张页总装图、零件图-02、工艺示意图。1张页面因被锁定已跳过。”到这里主链路已经通了。但如果你直接拿这段代码去跑真实平台大概率会在“删除前三页、循环还没结束”的时候发现页面删错了。这就是下一章要重点解决的核心坑。4. 最容易翻车的动态索引问题与删除顺序策略这一章是全文的精华部分。图纸页删除跟数组删除有个非常相似的坑集合的索引是动态变化的边遍历边删会跳过元素。4.1 正向遍历为什么必错假设图纸集里有5张页名称分别是“A、B、C、D、E”。你用正向循环去删除所有页for (int i 0; i allSheets.Count; i) { allSheets[i].Delete(); }问题出在Delete()执行后集合会立刻把被删元素移除后面的所有元素索引整体前移一位。于是i0 删除 A集合变成 [B, C, D, E]Count变成4i1 读取的是当前索引1的元素也就是 C而不是预期的 BB直接被跳过了。之后每删一个下一个元素都被跳过。结果是你原以为删了全部5页实际只删了3页剩下的B和D还留在图纸集里。这类Bug在演示环境里发生一次你就再也不会忘。4.2 方案A倒序遍历最简单可靠的解决方法是倒着删for (int i allSheets.Count - 1; i 0; i--) { allSheets[i].Delete(); }倒序删除时删除的是末尾元素它前面的元素索引不受影响。就算索引前移也只影响还没被遍历到的“更靠前”的元素而你下一步正好去取更靠前的索引——逻辑完全吻合。这个方案的优势是代码量最简、不需要额外结构适合“删除全部”和“删除筛选后的全部匹配项”这类场景。我在实际开发中默认采用的就是倒序遍历。4.3 方案B标记后统一删除有些场景不适合边遍历边删典型情况是删除前需要基于完整的集合状态做统计、或者要记录每个元素的位置信息、或者平台删除接口本身会强制刷新集合。这时候可以分成两步——先遍历一遍把所有要删的页面收集到ListSheet第3章代码用的就是这个思路再去统一删除var toDelete allSheets.Where(matchCondition).ToList(); foreach (var sheet in toDelete) { sheet.Delete(); }这一步为什么安全因为toDelete是独立的引用列表它的元素不会因为图纸集索引变化而丢失。哪怕删除过程中集合发生了大规模变动你手里的引用列表依然能定位到正确对象。方案对比一句话版本倒序遍历适合“闭着眼全删”标记后统一删除适合“还要做判断、统计、依赖完整集合状态”的场景。两次删除逻辑的底层都不可或缺实际项目中建议两个方案都写在代码注释里避免后面维护的人“优化”出正序遍历。4.4 实测中的一次教训我在某次功能自测时用正向遍历删一个 60 多页的图纸集结果删完发现还剩 15 张。当时第一反应是“删除接口有 Bug”排查了半天最后才发现是自己循环写法的问题。后来我把代码改成倒序一次通过。这类问题最坑的地方在于它不会崩溃不会报错只会静默地留下一些页面让用户以为删干净了归档时把废弃页一起交付出去——那才是真正的生产事故。所以我在代码里养成了一个习惯删除类函数的旁注里必须写清楚“不要用正序遍历”。5. 只读保护与默认页重建全量删除后的特殊处理删除逻辑跑通之后真正的“工程化”问题才开始冒头。下面三个边界场景是我在测试阶段逐一踩出来的每个都值得单独思考。5.1 只读页面怎么办图纸页不一定都是可编辑的。常见场景图纸集里有一批送审页被平台标记为只读或者页面被签出锁定或者所属图层被冻结。删除这类页面时平台的底层接口通常会直接拒绝有的平台还会抛异常。我的处理策略是两层防护。第一层在筛选待删除集合时就检查CanDelete属性把受保护的页面过滤掉不进入删除循环第二层在删除循环内部再包一层 try-catch防止某些平台属性判断不可靠、底层仍然抛错。过滤掉的数量要放进结果对象返回给用户否则用户会疑惑“我明明点了全删怎么还剩几张”。这里有个产品层面的取舍是“跳过并告知”还是“强制执行删除”现实情况里只读往往是有业务原因的比如已经在走审批流程。除非需求方明确说“只读页也要强删”否则安全优先默认跳过。5.2 全量删除后的空图纸集处理在第3章我提过制图平台通常不允许图纸集为空。这里再补充一个平台差异有的平台是全删后保存才报错有的平台是删到只剩一张时就禁止删除——这两种行为会导致“全量删除”逻辑根本走不通。前者好办删完补建默认页即可后者就麻烦你得判断“当前是不是只剩最后一张可删页”如果是要先新建一张空白页再去执行删除。if (isFullDelete allSheets.Count 1 allSheets[0].CanDelete) { drawingDocument.CreateSheet(DEFAULT_SHEET_NAME); // 先建新页再删旧页 }顺序上必须是“先建后删”否则平台直接禁止删除操作。这段逻辑不亲自跑一遍很难想到很多框架文档也不会写。我在这里翻过车所以单独列出来给同行提个醒。5.3 删除中断与部分成功状态最后一张页还没删完程序崩溃或者被用户强制终止了怎么办这种场景下的图纸集可能处于“删了一半、既不是全量也不是原名”的中间状态。对于图纸这种强状态文档我的经验是尽量让删除过程可串行化、可断点恢复。具体做法是在执行删除前把待删除页面名称快照写进操作日志每删一张就把这张页从日志里划掉。这样即使中途崩溃恢复时也能知道“哪些已删、哪些没删”不至于让用户对着一个状态不明的图纸集干瞪眼。快照的成本很低但对可靠性要求高的图纸工具来说价值非常大。6. 名称匹配细节与撤销回退容易被忽略的隐性需求这一章聊聊那些用户不会直接提、但做得不好一定会被吐槽的隐性需求。主要集中在名称匹配规则和撤销体验两个方向上。6.1 大小写敏感与否图纸页名称的命名习惯因行业而异。有的团队喜欢“A3-001”有的喜欢“图-总装-01”很难说哪种占多数。从工程实际来看大小写不敏感是更稳妥的默认选择——因为图纸页名称大多是给人看的使用者没心思记忆“这张页的A是大写还是小写”。我采用的是StringComparison.OrdinalIgnoreCase既保持精确匹配语义又避免大小写差异导致的“明明有这张页却删不掉”的困惑。如果你所在的领域对大小写有严格要求比如某些自动出图流程里名称是程序生成的编码那可以通过配置项来控制匹配规则但默认仍然建议忽略大小写。6.2 同名页面的删除策略图纸集里有可能出现同名页吗理论上应该避免但实际场景中——尤其是模板生成、多版本复制的情况下——同名页是会出现的。这带来一个决策点输入名称后是删除所有匹配的同名页还是只删第一张我的建议是全部删除但要在结果反馈里明确告知“删除同名页面N张”。理由用户输入一个名称通常意味着“我要清理所有叫这个名字的页”而不是“只清理第一张”。如果只删第一张用户得反复执行同一个操作反而违背批量删除的初衷。当然如果你希望更保守可以在接口里加一个deleteAllMatches参数默认为 true让特殊场景可以切换。6.3 撤销回退必须合并成一步前面提到事务组。这里再细化一下——不同平台对事务组的支持程度不一样支持显式事务组的平台如各种基于COM/.NET的CAD内核直接在循环外层包一个事务提交后整个批量删除成为一个撤销步。不支持事务组、但支持“命令栈”的平台要把删除封装成一个命令对象压入命令栈。两者都不支持的老平台至少要在删除前把图纸文件做临时备份或者记录页面原始状态手动实现“撤销到删除前”。我遇到过一种情况平台支持事务组但事务组内部如果混入了页面重建操作比如5.2里“先建新页再删旧页”而新页创建的撤销栈结构跟删除不同就容易出现“撤销一次只删了半截”的怪现象。所以事务组里最好只包含同类操作新建默认页和删除旧页建议拆成两个事务或者接受“一次撤销同时回退两个操作”的框架默认行为但要跟用户说清楚。6.4 上线前必须跑一遍的测试用例清单这个功能的代码量不大但测试用例可以写出十几条。我实际维护的测试清单如下用例编号测试场景预期行为TC01输入存在的图纸页名称只删除该名称忽略大小写的页面TC02输入不存在的名称不删除任何页面返回“未匹配”提示TC03名称前后带空格归一化后正常匹配TC04名称为空/全空格/null弹二次确认后删除全部页面TC05图纸集含只读页只读页被跳过结果中报告数量TC06图纸集只剩1页并执行全删先建默认页再删旧页确保图纸集不为空TC0760页图纸全删一次性删干净无遗漏验证索引方案TC08批量删除后执行撤销一次撤销恢复全部页面TC09删除过程中底层接口抛异常不崩溃已删页与未删页状态可区分TC10同名页多张全部删除并报告删除数量这十个用例跑完功能基本可以放心提交。最后一个用例曾经真的救过我——早先的版本只删第一张同名页用户反馈“删了等于没删”补测 TC10 之后才发现问题还差点带病上线。整套功能做完我最大的体会是一句话需求背后往往藏着十句没说的需求。“删除指定名称的图纸页名称为空就全部删除”这句话真正落地时需要把接口语义、索引安全、页面保护、空集处理、撤销合并、名称匹配规则全部过一遍才算真正“做完了”。尤其是实测里倒序删除和默认页重建这两个点建议你先在自己的平台验证一遍踩一次坑体会会比我写一千字都深。希望这篇记录能帮你把“听起来简单”的功能一次做对。 做制图相关模块开发这么些年我收到最多的需求反而不是那种花里胡哨的新功能而是把一件“听起来特别简单”的事做到真正好用。最近刚落地的一个需求就非常典型删除指定名称的图纸页名称为空就全部删除。需求正文就这么一句话评审会上甚至没人觉得它值得单独讨论。可真到设计接口、写删除逻辑、跑边界测试的时候你会发现里面藏着一堆不大不小却很致命的细节动态索引错位、只读页面、全删之后要不要建默认页、撤销怎么合并……一个没想清楚上线就是事故现场。这篇文章我就围绕这个一句话需求把从需求理解到接口设计、再到核心实现和踩坑排查的完整过程记录下来。如果你在做制图平台、CAD二次开发、图纸管理系统或者任何带“多页图纸”概念的工具模块这篇应该能帮你少走几天弯路。1. 一句需求背后的真实场景图纸批量清理到底解决什么问题先说业务背景。制图模块里的“图纸页”跟文档系统里的“页”不是一个概念——它更像一套图纸里的独立画布每张页承载一个视图、一个部件或一个工艺环节。一套完整的产品图纸动辄几十页上百页而实际生产过程中真正需要交付的可能只有其中的一部分。需求侧的典型场景是这样的工程师从模板工程出发一键生成了一套多页图纸然后要在归档前把其中的临时页、试验页、废弃方案页全部清掉。没有批量删除功能之前使用者只能一页一页地打开、选中、删除操作路径长还容易漏。更麻烦的是“全图清理”场景——项目推翻重来整张图纸要重置成空壳状态逐页删除可能要花上十几分钟。所以“指定名称删除 空名称全删”这个组合本质上是在补图纸页生命周期管理里最基础、也最高频的一块短板。这个需求真正服务的人群有两大类终端使用者制图工程师、工艺人员。他们要的是“输入框留空一键重置”的直觉操作不需要理解任何技术概念。二次开发者/平台集成方需要通过API批量操作图纸页例如在自动出图流程中程序生成若干临时页后统一清理。从产品语义上讲这其实是在定义一种“范围选择”的行为给一个名字就删一张或一类页不给名字就删所有页。听上去像是在函数入口加一个分支就能搞定但真正落到代码上首先要解决的并不是“怎么删”而是“怎么定义这两个分支的边界”。整件事的复杂度不在标题本身而在于标题没有写出来的部分删除是不可逆操作必须考虑确认、保护、撤销图纸可能被锁定页码存在动态索引问题删除全部之后图纸不能处于非法状态。这些才是本文想重点展开的内容。2. 接口设计指定名称与空名称两条分支的语义边界动手写代码之前我花了半天时间把接口语义理清楚。这一步看起来很“务虚”但恰恰是后面不返工的关键。2.1 一个函数还是两个函数标题需求表面上是两个功能但我的建议是设计成一个接口用参数区分。原因有三第一两种操作的业务意图一致都是“清理图纸页”拆成两个函数会让调用方多一次选择成本第二交互入口往往是一个输入框 一个删除按钮一个接口天然匹配一个入口第三后续如果需求演变成“名称支持通配符模糊匹配”一个接口的兼容成本反而比两个接口低。函数签名大致是这样/// summary /// 删除图纸页。 /// sheetName 为空或空白字符串时删除全部图纸页否则删除指定名称的图纸页。 /// /summary /// param namesheetName图纸页名称可空/param /// returns删除结果包含成功删除数量、跳过数量和未匹配信息/returns DeleteSheetResult DeleteSheets(string sheetName);这里有一个细节接口注释里我特意写了“为空或空白字符串”而不是“为空”。这意味着调用方传null、空字符串、或者一串肉眼看起来是空格的 都会被当作“全部删除”处理。2.2 空白字符串到底算不算“空”这个决定看起来小实际影响体验。交互层最容易出现的情况是用户打开对话框手抖在名称框里敲了几个空格或者输入法残留了一截空格然后点了删除。如果程序把空格当成真实名称去匹配结果就是“找不到这张页”用户一脸懵如果程序把空格统一归一化为空就会走全删逻辑——这两个结果差别巨大必须二选一并形成产品共识。我的选择是空白字符串统一视为空执行全量删除。理由很简单现实中不太可能有人给图纸页命名成三个空格误操作的概率远大于合理需求。为了降低误触风险全量删除前需要弹二次确认框这个后面单独讲。调用方如果确实要删除一张名字里带空格的页可以在传参前先走转义或精确匹配的专用接口而不是让通用接口去猜。2.3 匹配语义精确匹配还是模糊匹配标题说“指定名称”我理解为精确匹配不涉及通配符。但也遇到过一个实际案例有人希望输入“A3”能把“A3-总装图”“A3-零件明细”全删掉。这属于模糊删除的范畴语义上更危险——名字匹配范围不可控很容易误删。我在第一版实现里只做精确匹配大小写不敏感原因后面细说模糊匹配留到后续版本再考虑。如果真要做也建议设计成显式的通配符语法比如A3*而不是默认包含匹配。默认模糊 默认误删这是删除类功能最忌讳的。2.4 返回值不是布尔值这么简单删除结果对象里除了成功/失败还要能回答三个问题本次删了几张页有哪些页因为受保护不能删用户输入的名称没匹配到任何页时怎么提示这些都直接影响交互层的反馈文案。尤其是“名称未匹配”的情况不能简单弹一个“删除失败”就完事——正确做法是从结果里取出NotMatched字段明确告诉用户“未找到名称为XXX的图纸页已取消操作”同时把操作留在撤销栈里。我把接口语义理清楚之后后续实现就顺了很多。下面直接进代码链路。3. 核心实现从参数校验到循环删除的完整链路代码实现分五个步骤每一层解决一类问题。我以 C# 风格的代码演示但逻辑本身跟语言无关换成 C、Python 或 TypeScript 都适用。3.1 第一步参数归一化所有入口参数先走一遍归一化确保后面的逻辑不用到处判断nullpublic DeleteSheetResult DeleteSheets(string sheetName) { // 归一化null、、全空格 统一转换为 string.Empty string targetName string.IsNullOrWhiteSpace(sheetName) ? string.Empty : sheetName.Trim(); var allSheets drawingDocument.GetAllSheets(); var toDelete new ListSheet(); int skippedByLock 0; if (targetName string.Empty) { // 分支二全部删除 toDelete allSheets.Where(s s.CanDelete).ToList(); skippedByLock allSheets.Count - toDelete.Count; } else { // 分支一按名称删除 // 名称比较统一走 OrdinalIgnoreCase避免大小写问题 toDelete allSheets .Where(s string.Equals(s.Name, targetName, StringComparison.OrdinalIgnoreCase)) .Where(s s.CanDelete) .ToList(); skippedByLock allSheets.Count(s string.Equals(s.Name, targetName, StringComparison.OrdinalIgnoreCase) !s.CanDelete); } ... }这段代码有两点值得解释。第一Trim()写在归一化里意味着传入的名称前后的空格会被去掉这是为了配合交互层输入框的习惯第二先用Where筛选出待删除集合再统一执行删除而不是边遍历边删——这个设计选择留到第4章重点讲。3.2 第二步执行删除并处理受保护页面筛选出待删除集合后进入删除循环。这里需要考虑一个操作细节要不要在删除前做二次确认我的建议是只要走到“全部删除”分支必须二次确认“指定名称删除”且匹配数量较少时可不确认但会在结果反馈里列出被删页面名称。// 全量删除前弹确认框交互层做API 层不强制 bool isFullDelete targetName string.Empty; if (isFullDelete !userConfirmed()) { return DeleteSheetResult.Cancelled(); } // 执行删除收集被删名称用于日志/撤销 var deletedNames new Liststring(); drawingDocument.StartTransaction(); // 开启事务组保证撤销合并成一步 foreach (var sheet in toDelete) { deletedNames.Add(sheet.Name); sheet.Delete(); } drawingDocument.CommitTransaction(); return DeleteSheetResult.Success( deletedCount: deletedNames.Count, skippedByLock: skippedByLock, deletedNames: deletedNames); }事务组这段很重要。在不少制图内核里如果不主动包一层事务批量删除会被记录成 N 步撤销操作——用户删了50页就要按50次CtrlZ才能恢复那体验就成灾难了。事务组能把整批删除变成一个撤销步这也是“批量函数”跟“单个函数”在底层实现上的重要区别。3.3 第三步全部删除后重建默认页这里有一个非常容易被新手忽略的坑很多制图平台不允许图纸集为空。你把所有页都删了保存时直接报错甚至整个文档损坏。解决办法是在全量删除后自动新建一个默认的空白页。if (isFullDelete drawingDocument.GetAllSheets().Count 0) { var defaultSheet drawingDocument.CreateSheet(DEFAULT_SHEET_NAME); defaultSheet.SetAsActive(); result.NewSheetCreated true; }默认页的名字建议叫“页1”或“Sheet1”跟平台新建空白图纸时的默认命名保持一致。这样用户看到的结果是点了全删图纸集被清空然后多了一张干净的空白页——整个图纸集仍然处于可编辑的合法状态不会出现打开文件就报错的情况。还有一个细节如果全部删除后一张新页都没有建很多平台的导出、打印、图纸集管理功能会直接异常。你在做这个功能时务必先去查目标平台的文档确认“图纸集是否允许为空”。如果允许为空那重建默认页做成可选配置就行如果不允许这一步就是必须的。3.4 第四步返回结构化结果最后把DeleteSheetResult组装好返回给调用层。这个结果对象至少要包含四个字段是否被取消、成功删除的数量、因锁定等原因跳过的数量、实际被删除的图纸页名称列表。有了这些数据交互层才能给出精确的文案比如“已删除3张页总装图、零件图-02、工艺示意图。1张页面因被锁定已跳过。”到这里主链路已经通了。但如果你直接拿这段代码去跑真实平台大概率会在“删除前三页、循环还没结束”的时候发现页面删错了。这就是下一章要重点解决的核心坑。4. 最容易翻车的动态索引问题与删除顺序策略这一章是全文的精华部分。图纸页删除跟数组删除有个非常相似的坑集合的索引是动态变化的边遍历边删会跳过元素。4.1 正向遍历为什么必错假设图纸集里有5张页名称分别是“A、B、C、D、E”。你用正向循环去删除所有页for (int i 0; i allSheets.Count; i) { allSheets[i].Delete(); }问题出在Delete()执行后集合会立刻把被删元素移除后面的所有元素索引整体前移一位。于是i0 删除 A集合变成 [B, C, D, E]Count变成4i1 读取的是当前索引1的元素也就是 C而不是预期的 BB直接被跳过了。之后每删一个下一个元素都被跳过。结果是你原以为删了全部5页实际只删了3页剩下的B和D还留在图纸集里。这类Bug在演示环境里发生一次你就再也不会忘。4.2 方案A倒序遍历最简单可靠的解决方法是倒着删for (int i allSheets.Count - 1; i 0; i--) { allSheets[i].Delete(); }倒序删除时删除的是末尾元素它前面的元素索引不受影响。就算索引前移也只影响还没被遍历到的“更靠前”的元素而你下一步正好去取更靠前的索引——逻辑完全吻合。这个方案的优势是代码量最简、不需要额外结构适合“删除全部”和“删除筛选后的全部匹配项”这类场景。我在实际开发中默认采用的就是倒序遍历。4.3 方案B标记后统一删除有些场景不适合边遍历边删典型情况是删除前需要基于完整的集合状态做统计、或者要记录每个元素的位置信息、或者平台删除接口本身会强制刷新集合。这时候可以分成两步——先遍历一遍把所有要删的页面收集到ListSheet第3章代码用的就是这个思路再去统一删除var toDelete allSheets.Where(matchCondition).ToList(); foreach (var sheet in toDelete) { sheet.Delete(); }这一步为什么安全因为toDelete是独立的引用列表它的元素不会因为图纸集索引变化而丢失。哪怕删除过程中集合发生了大规模变动你手里的引用列表依然能定位到正确对象。方案对比一句话版本倒序遍历适合“闭着眼全删”标记后统一删除适合“还要做判断、统计、依赖完整集合状态”的场景。两次删除逻辑的底层都不可或缺实际项目中建议两个方案都写在代码注释里避免后面维护的人“优化”出正序遍历。4.4 实测中的一次教训我在某次功能自测时用正向遍历删一个 60 多页的图纸集结果删完发现还剩 15 张。当时第一反应是“删除接口有 Bug”排查了半天最后才发现是自己循环写法的问题。后来我把代码改成倒序一次通过。这类问题最坑的地方在于它不会崩溃不会报错只会静默地留下一些页面让用户以为删干净了归档时把废弃页一起交付出去——那才是真正的生产事故。所以我在代码里养成了一个习惯删除类函数的旁注里必须写清楚“不要用正序遍历”。5. 只读保护与默认页重建全量删除后的特殊处理删除逻辑跑通之后真正的“工程化”问题才开始冒头。下面三个边界场景是我在测试阶段逐一踩出来的每个都值得单独思考。5.1 只读页面怎么办图纸页不一定都是可编辑的。常见场景图纸集里有一批送审页被平台标记为只读或者页面被签出锁定或者所属图层被冻结。删除这类页面时平台的底层接口通常会直接拒绝有的平台还会抛异常。我的处理策略是两层防护。第一层在筛选待删除集合时就检查CanDelete属性把受保护的页面过滤掉不进入删除循环第二层在删除循环内部再包一层 try-catch防止某些平台属性判断不可靠、底层仍然抛错。过滤掉的数量要放进结果对象返回给用户否则用户会疑惑“我明明点了全删怎么还剩几张”。这里有个产品层面的取舍是“跳过并告知”还是“强制执行删除”现实情况里只读往往是有业务原因的比如已经在走审批流程。除非需求方明确说“只读页也要强删”否则安全优先默认跳过。5.2 全量删除后的空图纸集处理在第3章我提过制图平台通常不允许图纸集为空。这里再补充一个平台差异有的平台是全删后保存才报错有的平台是删到只剩一张时就禁止删除——这两种行为会导致“全量删除”逻辑根本走不通。前者好办删完补建默认页即可后者就麻烦你得判断“当前是不是只剩最后一张可删页”如果是要先新建一张空白页再去执行删除。if (isFullDelete allSheets.Count 1 allSheets[0].CanDelete) { drawingDocument.CreateSheet(DEFAULT_SHEET_NAME); // 先建新页再删旧页 }顺序上必须是“先建后删”否则平台直接禁止删除操作。这段逻辑不亲自跑一遍很难想到很多框架文档也不会写。我在这里翻过车所以单独列出来给同行提个醒。5.3 删除中断与部分成功状态最后一张页还没删完程序崩溃或者被用户强制终止了怎么办这种场景下的图纸集可能处于“删了一半、既不是全量也不是原名”的中间状态。对于图纸这种强状态文档我的经验是尽量让删除过程可串行化、可断点恢复。具体做法是在执行删除前把待删除页面名称快照写进操作日志每删一张就把这张页从日志里划掉。这样即使中途崩溃恢复时也能知道“哪些已删、哪些没删”不至于让用户对着一个状态不明的图纸集干瞪眼。快照的成本很低但对可靠性要求高的图纸工具来说价值非常大。6. 名称匹配细节与撤销回退容易被忽略的隐性需求这一章聊聊那些用户不会直接提、但做得不好一定会被吐槽的隐性需求。主要集中在名称匹配规则和撤销体验两个方向上。6.1 大小写敏感与否图纸页名称的命名习惯因行业而异。有的团队喜欢“A3-001”有的喜欢“图-总装-01”很难说哪种占多数。从工程实际来看大小写不敏感是更稳妥的默认选择——因为图纸页名称大多是给人看的使用者没心思记忆“这张页的A是大写还是小写”。我采用的是StringComparison.OrdinalIgnoreCase既保持精确匹配语义又避免大小写差异导致的“明明有这张页却删不掉”的困惑。如果你所在的领域对大小写有严格要求比如某些自动出图流程里名称是程序生成的编码那可以通过配置项来控制匹配规则但默认仍然建议忽略大小写。6.2 同名页面的删除策略图纸集里有可能出现同名页吗理论上应该避免但实际场景中——尤其是模板生成、多版本复制的情况下——同名页是会出现的。这带来一个决策点输入名称后是删除所有匹配的同名页还是只删第一张我的建议是全部删除但要在结果反馈里明确告知“删除同名页面N张”。理由用户输入一个名称通常意味着“我要清理所有叫这个名字的页”而不是“只清理第一张”。如果只删第一张用户得反复执行同一个操作反而违背批量删除的初衷。当然如果你希望更保守可以在接口里加一个deleteAllMatches参数默认为 true让特殊场景可以切换。6.3 撤销回退必须合并成一步前面提到事务组。这里再细化一下——不同平台对事务组的支持程度不一样支持显式事务组的平台如各种基于COM/.NET的CAD内核直接在循环外层包一个事务提交后整个批量删除成为一个撤销步。不支持事务组、但支持“命令栈”的平台要把删除封装成一个命令对象压入命令栈。两者都不支持的老平台至少要在删除前把图纸文件做临时备份或者记录页面原始状态手动实现“撤销到删除前”。我遇到过一种情况平台支持事务组但事务组内部如果混入了页面重建操作比如5.2里“先建新页再删旧页”而新页创建的撤销栈结构跟删除不同就容易出现“撤销一次只删了半截”的怪现象。所以事务组里最好只包含同类操作新建默认页和删除旧页建议拆成两个事务或者接受“一次撤销同时回退两个操作”的框架默认行为但要跟用户说清楚。6.4 上线前必须跑一遍的测试用例清单这个功能的代码量不大但测试用例可以写出十几条。我实际维护的测试清单如下用例编号测试场景预期行为TC01输入存在的图纸页名称只删除该名称忽略大小写的页面TC02输入不存在的名称不删除任何页面返回“未匹配”提示TC03名称前后带空格归一化后正常匹配TC04名称为空/全空格/null弹二次确认后删除全部页面TC05图纸集含只读页只读页被跳过结果中报告数量TC06图纸集只剩1页并执行全删先建默认页再删旧页确保图纸集不为空TC0760页图纸全删一次性删干净无遗漏验证索引方案TC08批量删除后执行撤销一次撤销恢复全部页面TC09删除过程中底层接口抛异常不崩溃已删页与未删页状态可区分TC10同名页多张全部删除并报告删除数量这十个用例跑完功能基本可以放心提交。最后一个用例曾经真的救过我——早先的版本只删第一张同名页用户反馈“删了等于没删”补测 TC10 之后才发现问题还差点带病上线。整套功能做完我最大的体会是一句话需求背后往往藏着十句没说的需求。“删除指定名称的图纸页名称为空就全部删除”这句话真正落地时需要把接口语义、索引安全、页面保护、空集处理、撤销合并、名称匹配规则全部过一遍才算真正“做完了”。尤其是实测里倒序删除和默认页重建这两个点建议你先在自己的平台验证一遍踩一次坑体会会比我写一千字都深。希望这篇记录能帮你把“听起来简单”的功能一次做对。