企业官网建设流程全解析

做.NET文档自动化这行，迟早会碰上奇偶页页眉/页脚这种需求。上个月我这边接了个批量生成技术方案的任务：文档要双面打印装订，翻到任何一页，左边页眉放公司名和项目编号，右边页眉放章节名，页脚的页码还必须镜像排列——奇数页在右下角，偶数页在左下角。需求本身一句话，但落到代码里，如果不想清楚Spire.Doc的页眉页脚模型，能把人卡一下午。

市面上做Word文档生成的库不少，我最终选了Spire.Doc。这篇文章就从实际项目出发，把我用Spire.Doc在.NET里设置奇偶页页眉/页脚的完整思路、核心代码和踩过的坑一起整理出来，给后面做文档自动化的朋友做个参考。内容既覆盖基础API的用法，也会讲页码域、多节文档继承这类进阶细节，适合正在做批量出文档功能的.NET开发。

先说结论：奇偶页页眉/页脚这件事，本质上不是“写两段文字”，而是要理解Word文档的Section、HeadersFooters、域字段这三层结构。Spire.Doc把这套结构映射得很直观，只要你把对应关系弄清楚，剩下就是往四个对象里填内容而已。

1. 先把需求拆干净：奇偶页页眉/页脚到底在解决什么问题

1.1 双面打印场景下的排版痛点

页眉页脚不只是装饰，它在纸质文档里承担阅读导航的功能。单面打印的文档无所谓，可一旦文档做成双面打印，比如投标书、操作手册、技术规格书、论文，装订成册之后，奇数页和偶数页天然分布在纸张的左右两侧，阅读时视线需要在左右两页之间来回切换。如果左右两页的页眉内容完全一样，装订线那一侧的文字会被书脊遮挡，看起来也不专业。

更关键的是页码。双面打印的书刊讲究“页码朝外”：奇数页页码在右上角或右下角，偶数页页码在左上角或左下角，这样读者翻页时，手指捏住的是页码空白区，不会被内容挡住。这个排版细节在Word里靠“奇偶页不同”选项手工设置很容易，但文档一旦进入批量生成流程，比如一次生成几百份合同、几十个章节的手册，再靠人工逐节去调就不现实了。

我在这个项目里要处理的文档大概长这样：封面不需要页眉，版权页单独用罗马数字页码，正文从阿拉伯数字第1页开始，奇数页页眉放章节名右对齐，偶数页页眉放公司主标题左对齐，页脚左右两侧镜像放“第 N 页”。需求拆开来看，就是三件事：每个Section的页面属性要独立、页眉页脚内容要区分奇偶、页码必须是自动计算的域而不是写死的字符串。只要能同时满足这三件事，后面哪怕文档结构再复杂，也是同一套逻辑的重复。

1.2 为什么把Spire.Doc放进备选清单

项目组讨论技术方案时，候选对象有三个：Microsoft.Office.Interop.Word、Open XML SDK、Spire.Doc。先说结论，我最终选的是Spire.Doc，理由很实际。

第一，生成程序要跑在服务器环境里，很多服务器根本不会安装Office。Interop.Word走的是COM调用，必须依赖本机安装的Word客户端，服务器上既不想装也不应该装，而且COM对象在长时间运行的服务里还容易发生进程残留、内存不释放的问题，可以做到功能正常但极其难维护，所以第一个被排除。

第二，Open XML SDK虽然免费、跨平台、不依赖Office，是微软官方推荐的底层方案，但用它操作页眉页脚要写一大堆XML解析和构造代码。设置奇偶页不同需要手动操作settings.xml和sectionPr里的evenAndOddHeaders标志，往里塞页眉内容又要构造wordprocessingml命名空间下的headerReference、paragraph、run、fieldChar这一整套节点，开发成本高，对团队的OpenXML熟练度要求也不低。为了一个页眉页脚功能付出这么多工作量，不划算。

第三，Spire.Doc的API设计非常贴近Word的对象模型，Document里装Sections，每个Section有HeadersFooters，页眉页脚里装Paragraph和TextRange，理解成本和Word操作经验几乎可以无缝迁移。开发效率高，服务器端部署零额外依赖，免费License已经能覆盖页眉页脚、段落排版、图片插入等常规需求，虽然有文档规模限制，但针对项目里单份几十页的文档完全够用。

1.3 三个常规方案的横向对比

我把三个方案的核心差异整理成一张对比表，方便后面做技术选型的朋友直接参考。

个人经验是，选型不能只看功能演示，还要考虑后续维护你的人的心理状态。Interop.Word的API确实和用户在Word里的操作一一对应，但一旦服务器重启、Office更新、权限变化，COM组件经常出现莫名其妙的崩溃。Open XML SDK则反过来，功能上限极高，但普通业务开发维护它很吃力。Spire.Doc算是两者之间最舒服的平衡点，这也是我这次毫不犹豫选它的原因。

2. 环境准备与对象模型：先把Spire.Doc的页眉页脚结构摸清楚

2.1 安装与版本选择

使用Spire.Doc的第一步是安装NuGet包。我项目里用的是.NET 6，直接执行下面的命令就能拉取最新稳定版。

dotnet add package Spire.Doc

如果是传统.NET Framework项目，也可以在Visual Studio的包管理器控制台里执行：

Install-Package Spire.Doc

版本选择上，建议不要无脑追最新，优先选自己项目目标框架支持的稳定版本线。比如.NET 6项目用最新稳定版没有兼容问题，但.NET Framework 4.5这种老框架就需要留意包版本是否还支持。实际发布时我直接把依赖打到服务镜像里，Linux容器里跑完全没问题，这一点比Interop.Word强太多了。

安装完成后，代码里需要引用的命名空间主要有三个：

using Spire.Doc; using Spire.Doc.Documents; using Spire.Doc.Fields;

Spire.Doc是Document类所在的根命名空间，Spire.Doc.Documents包含Section、Paragraph、PageSetup等功能类型，Spire.Doc.Fields里有TextRange、DocPicture、Field等字段相关类。页眉页脚的核心操作几乎全部围绕这三个命名空间展开。

2.2 HeadersFooters对象模型逐个拆

Spire.Doc里，页眉页脚不是挂在Document上的全局对象，而是挂在每个Section下的独立对象。一个Word文档可以包含多个Section，每个Section都有自己的页面尺寸、边距、页眉页脚内容。理解这一点非常重要，很多人写代码时习惯性地认为“设置一次页眉页脚，整篇文档就都生效了”，结果在分节场景下被各种覆盖问题折磨。

在Section对象下，Spire.Doc暴露了一个HeadersFooters集合对象，里面包含这么几个关键的页眉页脚入口：

这里要建立一个心智模型：Spire.Doc把叫Header的那个属性当成默认页眉，一旦你在PageSetup里打开了DifferentOddAndEven开关，这个默认页眉就自动降级为“奇数页页眉”，同时EvenHeader开始参与渲染。所以严格来说，设置奇偶页页眉时，奇数页页眉入口仍然是Header，不是某个OddHeader属性，这一点和Word里看到的“奇数页页眉”名称有一点点偏差，刚上手的人别找错入口。

2.3 从Word界面找到对应的开关

如果你在Word里手动设置过奇偶页页眉，理解Spire.Doc的对应关系会非常快。Word中打开“页面设置”或“页眉和页脚”工具，勾选“奇偶页不同”，Word会自动把默认页眉拆成奇数页页眉和偶数页页眉两个编辑区。程序里对应的就是一句代码：

section.PageSetup.DifferentOddAndEven = true;

另一个容易混淆的开关是“首页不同”，对应Spire.Doc的DifferentFirstPage属性。这两个开关是独立的：首页不同管的是每一节的第一页要不要单独处理；奇偶页不同管的是第一页之后的所有页面要不要分成左右两套。实际项目里经常两个开关同时打开，比如封面用首页页眉页脚且留空，正文再从奇偶页页眉页脚开始走。这两个开关一旦叠加，每个Section里需要填的内容就有五套：首页页眉、首页页脚、奇数页页眉、偶数页页眉、奇数页页脚、偶数页页脚。刚上手时容易懵，但只要记住入口都在同一个HeadersFooters对象下，逐个填充就行。

3. 核心实现：设置奇偶页页眉/页脚的完整流程

3.1 第一步：创建文档并开启奇偶页不同

先创建Document对象和第一个Section，同时把页面尺寸、边距、奇偶页开关设置好。我习惯在添加正文之前就把这些配置写完，这样后续往页眉页脚里填东西时，所有渲染条件已经就绪，不容易出现“写了内容但显示不出来”的怪问题。

using Spire.Doc; using Spire.Doc.Documents; using Spire.Doc.Fields; using System.Drawing; Document doc = new Document(); Section section = doc.AddSection(); section.PageSetup.PageSize = PageSize.A4; section.PageSetup.Margins.Top = 75f; section.PageSetup.Margins.Bottom = 75f; section.PageSetup.Margins.Left = 85f; section.PageSetup.Margins.Right = 85f; // 关键开关：启用奇偶页不同 section.PageSetup.DifferentOddAndEven = true;

这里DifferentOddAndEven必须在写页眉页脚内容之前设置为true。虽然Spire.Doc没有强制要求开关在前，但从逻辑清晰度出发，先开启模式再填充数据是最稳妥的写法。边距数值我这里写的是常见的装订场景配置，具体数值要根据实际版心需求调整，如果涉及装订线，还需要在PageSetup里单独设置装订线位置和宽度。

3.2 第二步：填写奇偶页页眉

奇偶页页眉的核心逻辑是“镜像”。奇数页页眉通常在纸张右侧，内容向右对齐；偶数页页眉在纸张左侧，内容向左对齐。这样从书脊往两侧看，页眉层次是整齐的。

先写奇数页页眉。入口是section.HeadersFooters.Header：

// 奇数页页眉：章节名，右对齐 Paragraph oddHeaderPara = section.HeadersFooters.Header.AddParagraph(); TextRange oddText = oddHeaderPara.AppendText("第1章 项目立项"); oddText.CharacterFormat.FontName = "微软雅黑"; oddText.CharacterFormat.FontSize = 10.5f; oddText.CharacterFormat.TextColor = Color.Gray; oddHeaderPara.Format.HorizontalAlignment = HorizontalAlignment.Right;

再写偶数页页眉。入口是section.HeadersFooters.EvenHeader：

// 偶数页页眉：公司主标题，左对齐 Paragraph evenHeaderPara = section.HeadersFooters.EvenHeader.AddParagraph(); TextRange evenText = evenHeaderPara.AppendText("XX公司技术方案"); evenText.CharacterFormat.FontName = "微软雅黑"; evenText.CharacterFormat.FontSize = 10.5f; evenText.CharacterFormat.TextColor = Color.Gray; evenHeaderPara.Format.HorizontalAlignment = HorizontalAlignment.Left;

这里有几个细节要注意。每往页眉里写文字，都要保证生成的是独立的Paragraph，并且显式设置段落对齐方式。如果你不加对齐设置，页眉内容会沿用默认的左对齐，左右镜像效果就出不来了。字体的设置也要主动做，页眉默认字体可能和正文风格不一致，打印出来会显得突兀。我在项目里通常把页眉字体、字号、颜色集合成一个公共方法，减少重复代码。

如果页眉下方需要一条横线，可以在段落的边框设置里给下边框指定线型和宽度。这个效果不能靠文字模拟，否则打印出来线的高度、粗细都和真边框有差异。实际代码里通过Paragraph.Format.Borders相关属性来配置，我后面封装模板时会把这也抽进去。

3.3 第三步：页脚加文字和页码域

页脚是奇偶页设置里最能体现自动化价值的地方。如果你直接在文本里写死“第1页”，那每页显示的内容都会一模一样，完全失去页码的意义。正确做法是插入Word域，让页码在文档打开或打印时自动计算。

奇数页页脚的代码：

// 奇数页页脚：页码右对齐 Paragraph oddFooterPara = section.HeadersFooters.Footer.AddParagraph(); oddFooterPara.AppendText("第 "); oddFooterPara.AppendField("pageNumber", FieldFieldType.FieldPage, null); oddFooterPara.AppendText(" 页"); oddFooterPara.Format.HorizontalAlignment = HorizontalAlignment.Right;

偶数页页脚的代码：

// 偶数页页脚：页码左对齐 Paragraph evenFooterPara = section.HeadersFooters.EvenFooter.AddParagraph(); evenFooterPara.AppendText("第 "); evenFooterPara.AppendField("pageNumber", FieldFieldType.FieldPage, null); evenFooterPara.AppendText(" 页"); evenFooterPara.Format.HorizontalAlignment = HorizontalAlignment.Left;

AppendField的第一个参数是这个域的标识名，可以随意起，不影响显示结果；第二个参数FieldFieldType.FieldPage表示这是一个PAGE域，也就是页码。如果还要显示总页数，可以用FieldFieldType.FieldNumPages，效果相当于Word里的“共 X 页”。

页码域的原理可以类比Excel里的公式：写进去的是一个“算式”，不是“结果值”。Word打开文档时会自动计算每个域当前的值，所以第一页的页码、第二页的页码会自动递增，不需要我们手工算好再填进去。这一点在批量生成场景下尤其重要——文档页数经常变化，用域可以保证页数再变，页码也不会出错。

3.4 完整代码示例与运行效果

把前面的关键代码整合成一个方法，方便项目里直接调用：

public void GenerateDocumentWithOddEvenHeaderFooter(string filePath) { using (Document doc = new Document()) { Section section = doc.AddSection(); section.PageSetup.PageSize = PageSize.A4; section.PageSetup.DifferentOddAndEven = true; // 奇数页页眉（右侧） Paragraph oddHeader = section.HeadersFooters.Header.AddParagraph(); TextRange oddHeaderText = oddHeader.AppendText("第1章 项目立项"); oddHeaderText.CharacterFormat.FontName = "微软雅黑"; oddHeaderText.CharacterFormat.FontSize = 10.5f; oddHeader.Format.HorizontalAlignment = HorizontalAlignment.Right; // 偶数页页眉（左侧） Paragraph evenHeader = section.HeadersFooters.EvenHeader.AddParagraph(); TextRange evenHeaderText = evenHeader.AppendText("XX公司技术方案"); evenHeaderText.CharacterFormat.FontName = "微软雅黑"; evenHeaderText.CharacterFormat.FontSize = 10.5f; evenHeader.Format.HorizontalAlignment = HorizontalAlignment.Left; // 奇数页页脚（右侧页码） Paragraph oddFooter = section.HeadersFooters.Footer.AddParagraph(); oddFooter.AppendText("第 "); oddFooter.AppendField("pageNumber", FieldFieldType.FieldPage, null); oddFooter.AppendText(" 页"); oddFooter.Format.HorizontalAlignment = HorizontalAlignment.Right; // 偶数页页脚（左侧页码） Paragraph evenFooter = section.HeadersFooters.EvenFooter.AddParagraph(); evenFooter.AppendText("第 "); evenFooter.AppendField("pageNumber", FieldFieldType.FieldPage, null); evenFooter.AppendText(" 页"); evenFooter.Format.HorizontalAlignment = HorizontalAlignment.Left; // 添加一段示例正文，方便验证 section.AddParagraph().AppendText("这是文档正文。在Word中打开，你会看到奇数页和偶数页有不同的页眉页脚。"); doc.SaveToFile(filePath, FileFormat.Docx2013); } }

这段代码保存后，用Word打开，翻到任意一张偶数页，页眉在左上角显示公司名，页脚在左下角显示页码；翻到奇数页，页眉变成右上角的章节名，页脚变成右下角的页码。整个文档看起来就像一份正式出版物。我用WPS也验证过，Word和WPS对奇偶页页眉页脚以及PAGE域的解析行为基本一致，兼容性不用太担心。

4. 进阶场景：页码规则、图片页眉与多节文档处理

4.1 页码格式与起始页码控制

基础版页码显示“第 N 页”已经够用，但实际项目里往往还有更精细的格式要求。最常见的是论文和手册的“前置部分用罗马数字、正文用阿拉伯数字”。这个需求要靠多Section结构来实现：前置部分和正文部分各占一个Section，前置部分的页码格式设为罗马数字，正文部分的起始页码重新从1开始。

页码格式的设置在PageSetup里，可以通过PageNumberStyle相关属性调整，常见的枚举值有PageNumberStyle.RomanUpper、PageNumberStyle.RomanLower、PageNumberStyle.Arabic。比如想让前置章节显示小写罗马数字，就把该Section的页码格式设置为RomanLower。想让正文从第1页开始重新编号，则需要在正文所在Section设置起始页码，不需要手动给每一页写死数字，只要起始页码指定了，后面的页码域会自动递增。

首页不显示页码是另一个高频需求。实现方式不是把页码文字删掉，而是开启“首页不同”开关，让首页页脚保持空白。代码上是设置section.PageSetup.DifferentFirstPage = true，然后确保section.HeadersFooters.FirstPageFooter里没有内容。这样首页页脚是空的，从第二页开始才正常显示奇数页/偶数页页脚。

4.2 图片Logo页眉的写法

页眉不一定要放文字，公司Logo、项目编号、条形码都可能在页眉里出现。Spire.Doc插入图片的方式很直接，用AppendPicture方法把Image对象挂到Paragraph上。

using System.Drawing; Paragraph logoHeader = section.HeadersFooters.EvenHeader.AddParagraph(); DocPicture logo = logoHeader.AppendPicture(Image.FromFile("logo.png")); logo.Width = 80f; logo.Height = 32f; logoHeader.Format.HorizontalAlignment = HorizontalAlignment.Left;

这里有两个容易踩的细节。第一，Image.FromFile的文件路径尽量用绝对路径，或者用Path.Combine(AppContext.BaseDirectory, "assets", "logo.png")拼出来。因为程序可能跑在Linux容器里，相对路径的工作目录和本机开发环境不一样，图片很容易找不到。第二，插入的图片建议先压缩再放进文档，否则生成出来的docx体积会明显膨胀，转PDF后文件也大，邮件附件都不好传。一张普通截图压到1000像素宽以内基本不影响印刷效果。

如果希望页眉左侧放Logo、右侧放文字，可以在页眉里插入一个只有两列的表格，左列放图片、右列放文本。表格比用tab键做定位更稳定，打印时不会出现错位。这种方式在目录页和章节页里很常见。

4.3 多节文档最容易翻车的继承逻辑

多节文档是页眉页脚设置的“重灾区”。Word的每个Section默认会继承前一节的页眉页脚，这种继承关系在Spire.Doc里由IsLinkedToPrevious属性控制。当这个属性为true时，当前节的页眉页脚内容引用的是上一节的内容，你在当前节写任何东西都不会生效，或者会反过去污染上一节。

举个实际场景：文档分三节，封面节无页眉，前言节用罗马数字页码，正文节用阿拉伯数字页码。如果你直接在第三个Section的HeadersFooters下写内容而不处理继承关系，Word打开后正文页显示的很可能还是第二个Section的页眉。正确的做法是先把链接断开，再写当前节自己的内容。

section.HeadersFooters.Header.IsLinkedToPrevious = false; section.HeadersFooters.EvenHeader.IsLinkedToPrevious = false; section.HeadersFooters.Footer.IsLinkedToPrevious = false; section.HeadersFooters.EvenFooter.IsLinkedToPrevious = false;

断开链接之后，再往对应的页眉页脚对象里填充内容。这个操作需要在每个需要独立页眉页脚的Section里重复执行。我遇到过的典型翻车场景是：程序跑完没报任何错误，打开Word发现正文部分的页眉是封面那节的空白页眉，排查了半天才想到是继承开关没断开。所以多节文档的逻辑一定要写在代码注释里，否则半个月后再看，很容易忘记哪个节断开了链接、哪个节还在继承。

5. 实测踩坑记录与排查速查表

5.1 问题1：奇数页页眉正常，偶数页页眉一片空白

这是最典型的问题，网上求助帖里一半以上是这个症状。代码里明明写了EvenHeader内容，生成出来偶数页却完全没有页眉。究其原因，大部分情况是DifferentOddAndEven没有设置为true，或者设置的位置和代码执行顺序有问题。Spire.Doc新建文档默认不开启奇偶页不同，此时EvenHeader即使写了内容，也不会参与渲染。

另外还有一种情况是往EvenHeader里写内容之前，程序先写了一句section.HeadersFooters.Header.Clear()之类的清理逻辑，把整个页眉集合的段落状态搞乱了。我的建议是：先设置DifferentOddAndEven = true，再操作EvenHeader，最后才动Header，并且避免对整个HeadersFooters做清除操作，尽量按段落级别去清。

5.2 问题2：页码域在预览和PDF里不显示

插入页码域后，在Spire.Doc自身的预览界面里可能看不到页码数字，这是正常现象。因为域是“计算型”内容，它的值要由Word或PDF转换器在渲染时计算出来。如果转PDF后发现页码域位置是空的，可以在保存前强制更新一次域。

Spire.Doc里可以通过doc.IsUpdateFields = true让文档在保存或导出时刷新所有域。这个属性不是所有版本都叫这个名字，有的版本用UpdateFields()方法，具体以当前版本API为准。我的习惯是生成docx后，再用Spire.PDF把docx转一次PDF，同时设置更新域，这样交付出去的PDF页码一定是完整可用的。

如果打开Word后页码正常，只是用WPS或者某些在线预览工具显示不出来，那通常是预览工具本身不刷新域，不代表文件有问题。遇到这种情况，按F9刷新一下域就能确认。

5.3 问题3：首页页眉被正文页覆盖

封面不想显示页眉，但生成出来封面却带着整篇的页眉。原因是不小心把内容写进了默认的Header，而封面没有独立的FirstPageHeader。要想让封面无页眉，必须开启DifferentFirstPage并清空首页页眉页脚内容。

section.PageSetup.DifferentFirstPage = true; section.HeadersFooters.FirstPageHeader.Paragraphs.Clear();

同理，如果封面页脚也不要“第 1 页”，就把FirstPageFooter也清空。注意这里清空的是首页页眉页脚，不是默认的Header和Footer，否则正文页的页眉页脚也会跟着丢。这块逻辑很容易手滑写错，建议操作之前先在纸上画出每个Section里需要用到的页眉页脚对象关系图。

5.4 常见异常速查表

把项目里面出现过的问题整理成一张表，方便快速定位。

还有一个关于性能的经验：Spire.Doc底层组件在多线程并发时并不总是线程安全的，批量生成时不要图省事直接用Parallel并行创建Document。我在项目里试过并行跑8个任务，最后有一小部分生成出来的文件页码错乱，排查后发现是同一个Spire.Doc版本在并发写全局样式时出了问题。改成串行循环后，一切恢复正常。批量任务优先保正确性，想提升吞吐量就用独立进程隔离，而不是在同一个进程里盲目开线程。

6. 个人经验与后续扩展

这套奇偶页页眉页脚的方案，我后来封装成了一个批量生成标书的小工具。核心思路是先把公共模板做好：一个带标准页眉页脚的docx模板文件，程序只需要用Document.LoadFromFile加载模板，再往对应位置填入动态内容。比起每次从头new Document()再拼页眉页脚，加载模板的方式样式更统一，生成速度也更快，因为页眉页脚这类相对固定的部分不需要反复重建。

如果你接下来要做“不同章节不同页眉”的需求，可以更进一步：维护一个章节名和页眉文本的对照表，在遍历Section时把章节名写到奇数页页眉里，偶数页页眉统一保持公司信息。这样只需要把我在第三节里写的页眉填充部分改成查表操作，其他逻辑全部复用。整套流程下来，从模板到输出，一个小时内能跑通两百份文档的批量生成。

根据我个人经验，最后再提醒一句：压测的时候一定不要只看文档能不能打开，要实际翻几页检查奇数页和偶数页的页眉页脚位置、页码起始值、封面是否干净这三项。文档自动化最怕的就是生成速度快但排版细节有暗病，打印出来才发现问题，返工成本很高。把检查清单固化到交付流程里，比事后补锅省心得多。