做文档自动化的人，几乎都逃不过这一关：客户发过来一批模板，页眉还是上个项目的名称，页脚挂着过期的合作方Logo，你不可能让客户自己打开Word手动改几百份文件。用C#在后台批量把页眉或页脚删干净，这个需求我前前后后接手过好几次，今天把能用的方案、代码、踩过的坑一次说清楚。

先给结论：如果你只是在Windows上处理少量文档，用Office的Interop最快；但如果你要做服务端批处理，或者公司环境不允许装Office，Open XML SDK是更稳的选择。这两种方案我都会给完整代码，顺便把Spire.Doc和Aspose.Words这类第三方组件也拿出来对比一下，方便你按场景选。

整个处理流程的核心思路并不复杂——Word的docx文件本质上是一个zip包，页眉页脚是其中独立的XML部件，我们要做的就是对“部件”进行清空或删除。但实际操作中有很多细节坑，比如首页不同、奇偶页不同、节的关联关系，这些不处理好，删完的文档打开还是“有页眉”，或者保存后文件直接损坏。

下面我从选型、原理、代码到排查，完整走一遍。

1. 方案选型：为什么我最后用 Open XML SDK 做这件事

1.1 三种主流方案的横向对比

C#操作Word页眉页脚，绕不开下面几个方案。我先用一个表格把它们的核心差异摆出来，再逐个讲我的实测体验。

Open XML SDK不用装Office，操作的是文件本身，速度比Interop快一个量级。Aspose.Words功能确实全，但一套商用许可成本不低，而且API虽然简单，出了问题反而被困在“黑盒”里。Spire.Doc免费版对文档篇幅有限制，如果你处理的模板恰好超过限制的段落数，运行到一半会直接报错，很尴尬。

1.2 选型背后的真实考量

我自己的选择逻辑很简单：如果这个功能要放进一个会被别人长期调用的服务里，我一定选Open XML SDK。原因有两条。

第一，Interop在服务端容易踩“COM组件权限”的坑。IIS进程默认账户对Office组件的调用经常出现权限问题，你写起来非常顺畅的代码，部署上去就开始报“拒绝访问”。这也是很多人在开发环境测试通过、一到生产环境就懵的原因。Open XML SDK只是解压和重写XML文件，完全绕开了这个权限模型。

第二，批处理性能差异巨大。我用Open XML SDK处理过几百份带图文的合同模板，总耗时三十多秒；同样数量的文档如果走Interop，可能要跑十几分钟，中间还不能有人碰那台电脑的Word进程。如果你的需求是“一次处理一批”，你不会有耐心用Interop。

如果你是一次性处理几份文档，且就在自己的Windows电脑上跑，Interop确实快得多，代码也短，后面我也会给一份备用代码。

2. 先说清楚：Word 里的页眉页脚到底长什么样

2.1 页眉页脚不是“文档里的文字”，而是“节里的部件”

很多第一次做这个需求的开发者会直接用查找替换的方式去删页眉里的文字，发现根本删不干净——因为页眉页脚根本不在Document.Body里。

一个docx文件解压后，你会看到这样一组文件：

word/ document.xml // 正文内容 header1.xml // 第1个页眉部件 header2.xml // 第2个页眉部件 footer1.xml // 第1个页脚部件 media/ // 图片、Logo等资源

正文的document.xml通过引用关系指向这些header和footer部件。一个Section节点下会用HeaderReference和FooterReference标明“我这个节用了哪个页眉部件”。

所以删除页眉页脚的本质操作是：

• 遍历Document.Body下面的所有Section；
• 找出每个Section引用的HeaderPart和FooterPart；
• 对部件内的内容进行清空，或者直接移除引用并删除部件文件。

理解到这一层，你就不会写出“把Document里的某个Paragraph删除”这种无效代码了。

2.2 三种页眉页脚类型与两个页面开关

每一个Section可以拥有三种页眉和三种页脚：

• Primary：默认页眉/页脚；
• First：首页页眉/页脚（需要在页面设置里打开“首页不同”）；
• Even：偶数页页眉/页脚（需要在页面设置里打开“奇偶页不同”）。

在Open XML SDK里对应的是HeaderFooterType枚举：HeaderFooterValues.Primary、HeaderFooterValues.First、HeaderFooterValues.Even。如果你遇到“明明删了Primary，首页还有页眉”的情况，八成是忘记了First类型的存在。

另外还有几个关键节点概念：

• DifferentFirstPageHeaderFooter：对应Word界面里的“首页不同”；
• OddAndEvenPagesHeaderFooter：对应“奇偶页不同”。

这两个开关不在Header/Footer部件里，而在SectionProperties的PageSetup节点上。你删除部件后，还要决定要不要把这个开关关掉，否则Word仍然会按“存在页眉”的方式渲染，视觉上可能还会留出页眉占位区域。

2.3 LinkToPrevious：最容易翻车的隐藏关联

每个Section的HeaderReference节点上有一个LinkToPrevious属性。这个属性表示“当前节是否沿用上一节的页眉”。

这里有个非常现实的问题：如果你的文档有多个Section，你在第一节里把页眉内容清空了，但第二节、第三节的HeaderReference如果带有LinkToPrevious，它们实际上还是在引用第一节的页眉部件——你把第一节的部件删了，后面所有节的页眉也就没了；如果你只处理了第二节，而第二节是LinkToPrevious=true，那么你修改的东西根本不会生效，因为Word渲染时会直接展示前一节的页眉。

这也是“删了等于没删”的最常见原因之一。

所以我在代码里都会先做一个判断：拿到一个HeadReference后，先读它的LinkToPrevious值，如果为true，要么把这个值改成false再操作，要么跳过并继续处理前一个Section。这个逻辑我会在后面的代码片段里完整体现。

3. 核心代码：真正把页眉或页脚删干净的完整实现

3.1 先删内容：遍历并清空页眉/页脚中的全部内容

我用的开发环境是.NET 6 + Open XML SDK 3.0.1，你如果用的是.NET Framework 4.7.2，代码基本不需要改，只是包版本建议选2.x的老版本。

先安装一下依赖：

dotnet add package DocumentFormat.OpenXml --version 3.0.1

然后看主方法。这个方法做的事情是：打开文档，遍历所有节，找出所有页眉和页脚部件，把里面的内容全部删掉。

using DocumentFormat.OpenXml.Packaging; using DocumentFormat.OpenXml.Wordprocessing; public static class HeaderFooterRemover { public static void RemoveAllHeadersAndFooters(string filePath) { using (WordprocessingDocument doc = WordprocessingDocument.Open(filePath, true)) { MainDocumentPart mainPart = doc.MainDocumentPart; foreach (SectionProperties sectionProps in mainPart.Document.Body.Elements<SectionProperties>()) { // 遍历当前节下的所有页眉引用 foreach (HeaderReference headerRef in sectionProps.HeaderReferences) { HeaderPart headerPart = (HeaderPart)mainPart.GetPartById(headerRef.Id); RemoveContents(headerPart.Header); // 这里可以先移除引用，也可以等遍历完再统一处理 } // 遍历当前节下的所有页脚引用 foreach (FooterReference footerRef in sectionProps.FooterReferences) { FooterPart footerPart = (FooterPart)mainPart.GetPartById(footerRef.Id); RemoveContents(footerPart.Footer); } } mainPart.Document.Save(); } } private static void RemoveContents(Header header) { if (header == null) return; // 删除所有段落 foreach (Paragraph para in header.Descendants<Paragraph>().ToList()) { para.Remove(); } // 删除所有表格（页眉里也可能有表格，比如带通栏表格的页眉） foreach (Table tbl in header.Descendants<Table>().ToList()) { tbl.Remove(); } // 删除内容控件（页眉里的复杂域控件，例如自动插入的标题域） foreach (SdtBlock sdt in header.Descendants<SdtBlock>().ToList()) { sdt.Remove(); } } private static void RemoveContents(Footer footer) { if (footer == null) return; foreach (Paragraph para in footer.Descendants<Paragraph>().ToList()) { para.Remove(); } foreach (Table tbl in footer.Descendants<Table>().ToList()) { tbl.Remove(); } foreach (SdtBlock sdt in footer.Descendants<SdtBlock>().ToList()) { sdt.Remove(); } } }

这段代码里有两个容易忽略的地方。第一，Descendants干完活之后要加ToList()，否则遍历集合的同时删除元素，会直接抛InvalidOperationException。第二，SdtBlock在页眉里的出现频率比你想象的高得多——Word 2013以后的“标题域”就是存储在SdtBlock里的，你不删它，就会出现“明明没内容了，但页眉里还有一条项目名横线”。

3.2 再处理占位符：顺手把那条“空页眉横线”也干掉

删完内容后，如果你立刻打开Word看效果，大概率会发现页眉区域还是有一条横线。这是页眉默认样式“页眉”里定义的段落边框。Word渲染一个空白页眉时，段落边框依然会绘制。

正确做法是：删除内容后，把ParagraphProperties里ParagraphBorders的BottomBorder清掉。我封装了一个方法：

private static void RemoveHeaderBorder(Header header) { if (header == null) return; Paragraph firstPara = header.Elements<Paragraph>().FirstOrDefault(); if (firstPara == null) return; ParagraphProperties paraProps = firstPara.ParagraphProperties; if (paraProps == null) return; ParagraphBorders borders = paraProps.ParagraphBorders; if (borders == null) return; borders.BottomBorder = null; // 左右边框也一并清掉，防止某些样式下横线跑偏 borders.LeftBorder = null; borders.RightBorder = null; borders.TopBorder = null; }

有人会问：既然删空了，这段代码还有意义吗？有意义。因为你在3.1里把Paragraph都删了，Word打开文档时会在空Header部件里自动生成一个新的空Paragraph，这个空Paragraph照样会带“页眉”样式的下边框线。所以比较稳的做法是：不把所有段落都删完，而是保留一个空白段落，清掉它的边框，再清空Run里的文字内容。

调整一下策略：每个Header或Footer只保留第一个Paragraph，清空里面的所有Run和SdtRun，再清掉边框；其余的Paragraph全部删除。这样既没有内容，也不会有横线。

private static void EnsureEmptyHeaderWithoutBorder(Header header) { if (header == null) return; List<Paragraph> paras = header.Descendants<Paragraph>().ToList(); for (int i = 0; i < paras.Count; i++) { if (i == 0) { // 保留第一个段落，清空其内容和边框 Paragraph firstPara = paras[i]; firstPara.RemoveAllChildren<Run>(); firstPara.RemoveAllChildren<SdtRun>(); firstPara.RemoveAllChildren<Hyperlink>(); ParagraphProperties props = firstPara.ParagraphProperties; if (props != null) { props.ParagraphBorders?.Remove(); } // 重置文本 firstPara.Append(new Run(new Text(string.Empty))); } else { paras[i].Remove(); } } }

页脚同样处理。逻辑完全一样，区别只是操作的对象从Header换成了Footer。

3.3 按需删除链接节？还是只清空？先把判断逻辑想明白

在我自己写功能时，往往会纠结一个问题：到底要不要删除HeaderPart，还是只清空内容？

我的实践经验是：如果这个文档后续还要给其他人编辑，只清空内容比删除部件更安全。因为删除部件涉及修改DocumentBody里每个Section的HeaderReference，还要处理Part的RelationshipId，DeleteParts和DeletePart的调用时机稍有不对，容易让文档残留孤立引用。

下面是一个“先清空内容，再统一清理链接关系”的版本。这个方法更稳健，也解决了前面说的LinkToPrevious问题：

public static void RemoveHeadersFootersPreservingStructure(string filePath) { using (WordprocessingDocument doc = WordprocessingDocument.Open(filePath, true)) { MainDocumentPart mainPart = doc.MainDocumentPart; List<HeaderPart> headerParts = new List<HeaderPart>(); List<FooterPart> footerParts = new List<FooterPart>(); // 第一步：把所有节里引用的页眉页脚找出来，去重 foreach (SectionProperties sectionProps in mainPart.Document.Body.Elements<SectionProperties>()) { foreach (HeaderReference headerRef in sectionProps.HeaderReferences) { HeaderPart headerPart = (HeaderPart)mainPart.GetPartById(headerRef.Id); headerParts.Add(headerPart); } foreach (FooterReference footerRef in sectionProps.FooterReferences) { FooterPart footerPart = (FooterPart)mainPart.GetPartById(footerRef.Id); footerParts.Add(footerPart); } } // 第二步：清空内容 foreach (HeaderPart headerPart in headerParts.Distinct()) { EnsureEmptyHeaderWithoutBorder(headerPart.Header); } foreach (FooterPart footerPart in footerParts.Distinct()) { EnsureEmptyHeaderWithoutBorder(footerPart.Footer); } // 第三步：关闭所有节上的“首页不同”和“奇偶页不同”， // 否则页面上还会留下页眉相关的占位区域。 foreach (SectionProperties sectionProps in mainPart.Document.Body.Elements<SectionProperties>()) { PageSetup pageSetup = sectionProps.GetFirstChild<PageSetup>(); if (pageSetup == null) { pageSetup = new PageSetup(); sectionProps.AddChild(pageSetup); } pageSetup.TitlePage = false; // 首页不同 -> false pageSetup.EvenAndOddHeaders = false; // 奇偶页不同 -> false } mainPart.Document.Save(); } }

HeaderPart.Distinct() 这个细节很重要。多个节可以引用同一个HeaderPart，你如果不做去重，同一个部件会被清两遍，虽然没什么致命影响，但会多做无用功。真正会导致报错的场景是：某个HeaderPart已经被删除了，但节里还有旧引用指向它，你再用GetPartById去找，直接抛异常。

Distinct()能消除一部分风险，但如果你要“真的删除部件”，还需要遍历引用关系。我建议宁可保留空部件也不删部件，理由刚才也说了——稳。

3.4 换成 Interop 怎么删（给你一套备用短代码）

如果你的场景就是单机少量处理，而且Office肯定是装了的，Interop版本的代码非常简洁。核心思路是遍历Sections的Headers和Footers，然后Clear()。

using Word = Microsoft.Office.Interop.Word; public static void RemoveHeadersFootersByInterop(string filePath) { Word.Application app = new Word.Application(); app.Visible = false; app.DisplayAlerts = Word.WdAlertLevel.wdAlertsNone; Word.Document doc = app.Documents.Open(filePath, ReadOnly: false); // 遍历所有节 foreach (Word.Section section in doc.Sections) { // 删除首页页眉 section.Headers[Word.WdHeaderFooterIndex.wdHeaderFooterFirstPage].Clear(); // 删除偶数页页眉 section.Headers[Word.WdHeaderFooterIndex.wdHeaderFooterEvenPages].Clear(); // 删除默认页眉 section.Headers[Word.WdHeaderFooterIndex.wdHeaderFooterPrimary].Clear(); section.Footers[Word.WdHeaderFooterIndex.wdHeaderFooterFirstPage].Clear(); section.Footers[Word.WdHeaderFooterIndex.wdHeaderFooterEvenPages].Clear(); section.Footers[Word.WdHeaderFooterIndex.wdHeaderFooterPrimary].Clear(); } doc.Save(); doc.Close(); app.Quit(); }

Clear()会把内容和格式都重置掉，比手动逐段落删除更省事。但注意两个使用陷阱：

• 用完一定要Close和Quit，否则后台会残留多个WINWORD进程，时间长了内存吃满；
• 如果Word模板里的头部类型被锁定，比如“链接到前一节”被勾选，那么Clear()在某些节上不对后面的节起作用，逻辑和Open XML里LinkToPrevious的坑是对应的。

4. 实战中一定会踩的坑与排查速查表

4.1 保存后文件打不开

症状：用Open XML SDK处理完文档，用Word打开时提示“文件损坏，是否尝试恢复”。

原因：最常见的不是逻辑问题，而是保存前忘了做Dispose。WordprocessingDocument.Open之后，如果你不释放，文件句柄一直被占着，保存时可能写不完整。另一个原因是你在删除Paragraph等元素时把XML结构改坏了，比如删了SectionProperties里所有HeaderReference，但没有清理对应的Relationship。

排查思路：

• 确保using块正确包裹；
• 把处理后的docx后缀改成zip，打开看word/document.xml是否结构完整；
• 检查有没有空的Namespace引用。

我个人在开发时有一个习惯：处理完一个文档，立刻用解压工具打开一次，肉眼扫一眼XML。第一次写的时候就是因为忘了删除孤立Relationship，修了大半天。

4.2 第一节删了，后面的节的页眉还在

症状：文档有多个节，第一节的页眉删掉了，但第二节、第三节的页眉依然显示。

原因：这就是上面反复说的LinkToPrevious。你清空了第一节的页眉部件，但第二节的HeaderReference还链接着那个部件，或者第二节沿用了第一节的渲染。

解决思路：要么遍历全部节，把所有节的HeaderReference都指向同一个被清空后的HeaderPart（这样整个文档统一为空）；要么处理到每个节时，把LinkToPrevious属性强制设为false再清空。

要注意的是，LinkToPrevious="1"或true时，实际上不一定有独立的HeaderPart引用。正确做法是：发现某个节的HeaderReference带LinkToPrevious时，新建一个空的HeaderPart，替换掉它原本的引用。

private static void DisconnectLinks(SectionProperties sectionProps, MainDocumentPart mainPart) { foreach (HeaderReference headerRef in sectionProps.HeaderReferences.ToList()) { if (headerRef.LinkToPrevious != null && headerRef.LinkToPrevious.Value) { // 新创建一个空的页眉部件 HeaderPart newHeaderPart = mainPart.AddNewPart<HeaderPart>(); newHeaderPart.Header = new Header(new Paragraph(new Run(new Text(string.Empty)))); // 让该引用指向新部件，并取消链接 headerRef.RemoveAttribute("w:linkToPrevious", "http://schemas.openxmlformats.org/wordprocessingml/2006/main"); headerRef.Id = mainPart.GetIdOfPart(newHeaderPart); } } }

这套逻辑在只清空内容、不删除部件的场景里其实很少触发，但你的代码如果是要“移除文本后彻底空白”，它非常关键。

4.3 奇偶页和首页不同导致“漏删”

症状：你只删了Primary页眉，但打开文档首页还是有页眉。

原因：文档开了“首页不同”或“奇偶页不同”，而你只处理了Primary类型。

这是我在一个客户案例里踩到的。当时拿到的模板是某公司在正式合同基础上改出来的，首页定了独立的页眉样式，绑定“公司内部文件”几个字，其他页是空白的。我只删了Primary，以为完事了，结果第一页还挂着那行字。

后来我把三类都处理了：

foreach (HeaderFooterType type in Enum.GetValues(typeof(HeaderFooterType))) { HeaderPart part = headerParts.FirstOrDefault(x => x.HeaderFooterType == type); if (part != null) { EnsureEmptyHeaderWithoutBorder(part.Header); } }

这里HeaderFooterType就是前面讲的Primary、First、Even三种，你要每个类型都检查，不要想当然“我的文档只有一种页眉”。

4.4 批处理几百个文档的性能与内存

如果你要批量处理，建议每处理完一个文档就释放一次资源，避免把所有文档同时装进内存。我的做法是：

foreach (string file in files) { using (WordprocessingDocument doc = WordprocessingDocument.Open(file, true)) { ProcessHeader(doc); ProcessFooter(doc); } GC.Collect(); // 实测下来，批处理场景下这个调用能明显降低峰值内存 }

GC.Collect()在服务端不推荐频繁调用，但批量工具里这么做可以快速释放文件流上下文。另外请把日志打在任何可能抛异常的位置，Open XML SDK的异常信息通常很底层，没有日志你根本不知道是哪份文件出的问题。

还有一个我比较推荐的做法：处理前先备份一份副本到临时目录。因为页眉处理逻辑有风险时，你在开发自测过程中很容易把原始模板搞坏，没有副本只能重新找客户要文件。

5. 一点个人经验

做文档批处理这几年，我最大的体会是：删除类操作比生成类操作更容易翻车。生成东西出错，最多是格式不对；删除东西出错，可能把原始文件结构搞坏，数据丢了很难补救。

所以现在我的工具里，第一步永远是备份原文件，第二步是读取文档结构打日志，第三步才是执行删除。这套流程看起来多花几秒钟，但对业务项目来说是值得的。

还想起一个小技巧：如果你做完删除后还想再对比一下效果，可以把处理后的docx复制一份改成zip，然后手动保留header1.xml和footer1.xml，其余XML文件删掉，再用解压工具查看。这样能在不重新打开Word的情况下，快速确认页眉里是不是真的没有残留内容了。

页眉页脚删除这个需求，表面上是个“清空内容”的小功能，实际上牵扯到Word的部件结构、节的引用关系、页面设置开关。希望这篇文章里的代码和避坑经验能帮你少走弯路，一次把文档处理干净。