01-ShapeDelete静默无效与XML手术

Excel 里 Shape.Delete 不报错也不生效？——COM 静默失效的排查与 XML 手术绕行方案

本文记录一次真实的排查过程。起始状态：一个正在使用中的 .xlsm 业务系统，主页上有几十个用形状做的按钮，其中若干个是历史遗留、配置表里早已没有记录，需要在代码层面彻底删掉。 结论先放前面：Shape.Delete 的"静默无效"只发生在从外部进程调 COM 这条路；写进 VBA 过程里执行是有效的（2.1 有实测数据）。而在动手做 XML 手术之前，请先看 2.2——相当一部分"删不掉"，其实是删掉了又被工作簿自己的代码建回来。

#WorkBuddy

一、现象：脚本说"删完了"，形状还在

先看最朴素的写法：

跑完没有任何报错，退出码 0，日志里也确实打印了"已删除"。

重新打开文件一看：两个形状还在原位。

这种"不报错也不生效"的静默失败，比直接抛异常难查得多——你没有任何错误信息可以搜，只能怀疑人生。

二、先证明是 COM 的问题，别急着改方案

遇到这种事最容易犯的错，是马上去试各种"换个写法"（Select 再删、Shapes.Range(...).Delete、遍历时倒序……）。先把问题定性，成本更低。

我做了一个最小验证：

输出：

定性结论：Shape.Delete 在"从外部进程调 COM"这条路上不生效。同一批验证里还发现三兄弟也一样：

有意思的是 AddShape 正常——所以这不是"COM 整体不可用"，而是特定写操作被吞掉了。这也解释了为什么它容易被认为是"玄学"：同一套代码里有的操作生效、有的不生效。

⚠️ 这个结论有一个限制条件，用错方向的机会很大：这些操作在 Excel 界面里手动执行、或者在 VBA 过程内部执行都是正常的，问题只出在"从外部进程调 COM"这条路。下一节用实测数据把这个限制条件钉死。

2.1 同一句 Delete，换个"从哪调"结果就相反

上面的"静默无效"有一个关键限定：它只成立于从外部进程调 COM 这条路。

同一台机器、同一个文件，把删除动作写进 VBA、再用 Application.Run 从外部调它，结果是真的删掉了：

实测输出：

所以准确的对照表是这样：

实践顺序建议：先花两分钟试"写个 VBA 过程删"，成了就收工——比 XML 手术简单得多。 只有这两种情况才值得下下面的笨功夫：要求文件里不留任何多余代码，或者不想让文件跑宏 / 文件根本打不开（比如一打开就弹登录框、或者不是 .xlsm）。

把删除写进 VBA 还顺带解决一件 XML 手术做不到的事：可以按业务规则判断再删（例如"删掉所有不在配置表里的形状"），而不是给一串写死的名字。

2.2 另一个会把自己骗过去的假象：形状"删了又回来"

在把结论定性成"删除无效"之前，必须先排除这一种情况：形状确实被删掉了，但工作簿自己的代码下次打开时又把它建了回来。

这类遗留形状通常配套一段"找不到就新建"的逻辑：

更隐蔽的是："形状跑到屏幕外"本身也可能是代码干的——当年某次也是 Shape.Delete 删不掉，索性改成"藏起来"：

于是这个形状既不可见、又不在配置表里，看起来就是个"删不掉的历史遗留"——实际是代码每次打开都把它藏一遍。

正确的诊断顺序：

1. 先 grep 形状名：代码里有没有引用？
2. 有引用 → 先删代码里的创建逻辑，再删形状。顺序反了，形状会复活，甚至落在屏幕内的默认坐标上压住别的控件。
3. 只有"代码里零引用"且"删除前后 Shapes.Count 也没变"，才轮到"COM 静默无效"这个结论。

验证要证明的是"不再重建"：跑一次真实的打开流程，比较跑前/跑后的形状数——持平才算通过（多出 1 个 = 代码还在重建）。只验证"现在没有了"是不够的。

附带一个判断"哪些隐藏形状才是孤儿"的小技巧：看它是否落在业务区矩形内。在矩形内且 Visible=0 的，很可能是分页/第二页的正常按钮（未翻页时本来就隐藏），删了会出事；在矩形外的（比如 L=1100）才是孤儿。只看 Visible 会误杀，只看位置会误判，两个一起看。

三、方案②：直接改 .xlsm 内部的 XML（彻底，但要处理 rels 和全量重打包）

.xlsm 本质是 zip。形状存在 xl/drawings/drawingN.xml 里，每个形状是一个 <xdr:twoCellAnchor>（或 oneCellAnchor / absoluteAnchor）块，块里的 <xdr:cNvPr name="旧按钮A"/> 就是形状的名字。

所以"删形状"等价于：从 drawing XML 里摘掉那个 anchor 块，同时把 _rels 里它引用的超链接关系也清掉（否则文件会被判为结构损坏，打开报错）。

完整脚本：

四、每步的输入输出对照（用于自查）

回读校验这一步别省，脚本的最后加上：

五、五个失败预警（都是真踩过的）

1. name="..." 后面是形状的 Name 属性，不是显示文字。 中文显示名和 Name 经常不一致（手工画的形状尤其如此）。先用 COM 把 shp.Name 全部打印出来核对，别猜。
2. 只删 drawing 不清 rels，Excel 打开会提示"文件已损坏"。 这是最吓人的一种失败——看起来像把文件搞坏了，其实补一句 rels 清理就好。所以备份必须在最前面。
3. 重打包必须遍历全部 zip 条目，不能只写改动过的那几个。.xlsm 里的 vbaProject.bin、[Content_Types].xml 缺一个就打不开。上面脚本用 for n in names 全量写回，就是这个原因。
4. 文件被 Excel 打开着时改它，改完可能被覆盖回去。 操作前确认没有 ~$xxx.xlsm 锁文件、没有残留 EXCEL.EXE 进程。
5. 只验证"现在取不到"就当收工。 形状可能在下次打开时被代码重建（2.2），也可能有多个同名形状（回读校验要列全部名字，别只查一个）。判据是"跑完整打开流程后数量持平"。

六、顺带解决的一个高频问题

同一个 XML 手术还能做另一件事：只清超链接、保留形状。

把上面 fix() 里 return "" 换成"只挖掉 <a:hlinkClick .../> 元素"：

这解决的是一个极常见的现象：按钮上被手工挂过超链接，之后不管怎么改 VBA，点击都只打开那个链接——因为 Excel 里形状的 Hyperlink 优先级高于 OnAction。很多人遇到"按钮点了没反应"或"点了跳到莫名其妙的地方"，根因都在这。清掉之后，点击才真正走 VBA。

七、小结

• 先排除假象再定性：形状"还在"可能有三层原因——没删掉（COM 静默失效）、删掉了又被代码重建（2.2）、根本没匹配上名字。跳过 2.2 直接下"COM 无效"的结论，会白折腾一轮。
• 外部 COM 的部分写操作会静默失败（Shape.Delete、Hyperlink.Delete、Range.ClearContents 是重灾区），判断依据只能靠"操作前后状态对比"，不能靠"没报错"。
• 定性之后按成本从低到高选方案：① 写进 VBA 过程再 Run（两分钟，代价是文件里多一段代码）→ ② 改内部 XML（彻底，但要处理 rels 和全量重打包）。
• 任何改 .xlsm 内部结构的脚本，备份 → 改 → 回读校验三步一步都不能少。
• 验证的判据要选对：删形状要验"跑完整打开流程后数量持平"，不能只验"现在取不到了"。

配套：文中完整可用的脚本（含命令行参数、自动备份、回读校验）已整理成技能包，见同系列 xlsm_xml_surgery.py。

#WorkBuddy