C#生成Word文档：深入理解与底层原理
用 Microsoft.Office.Interop.Word 生成 Word 文档，真不推荐在服务端用
先明确一个核心观点：在服务器环境里依赖 Microsoft.Office.Interop.Word，无异于给自己埋下了一颗定时冲击波。这套方案的本质，是调用本地安装的Word应用程序，这就决定了它天生无法跨平台。在服务端启动一个 Word.Application 实例，问题会接踵而至：进程极易卡死、内存泄漏几乎是必然，更别提微软官方早已明确表态，不支持在服务器端进行此类自动化操作。
常见的场景是，第一次调用或许风平浪静，但后续的请求就会开始出现超时、进程残留，最终导致IIS应用池崩溃，服务彻底瘫痪。
那么，如果非用不可，有哪些必须遵守的“军规”？
- 场景限定：仅限Windows桌面应用（比如WinForms或WPF），并且要确保用户电脑上确实安装了完整版的Office。
- 资源释放：这绝对是重中之重。必须手动调用
app.Quit()，并将相关引用置空，有时甚至还得加上GC.Collect()来强制垃圾回收——即便如此，也未必能保证万无一失。 - 实例隔离：坚决避免多线程共享同一个
Application实例。最稳妥的做法是，每个文档操作都创建并独占一个实例，完成后立即释放。 - 监控与清理：如果线上系统已经用了这套方案，务必严密监控服务器上的
WINWORD.EXE进程数量，并准备好自动清理的脚本，以防进程“僵尸大军”拖垮服务器。
用 OpenXML SDK 写 .docx，才是生产环境正解
想要在生产环境中稳定、高效地生成Word文档？OpenXML SDK 才是那个“标准答案”。它的原理是直接操作Word文档的底层结构——也就是那个ZIP压缩包里的XML文件。这样一来，就彻底摆脱了对Office软件的依赖，纯托管代码，完美支持跨平台（.NET Core/.NET 5+），性能出色且完全可控。
当然，天下没有免费的午餐。获得这些优势的代价，是你需要深入理解 document.xml 的节点逻辑。比如，段落对应 w:p，文本跑在 w:t 里，而样式则通过 w:styleId 来关联。
如何快速上手并避开那些常见的“坑”？
- 从模板逆向学习：找一个现成的、带样式的
.docx文件，把后缀名改成.zip后解压。仔细研究word/document.xml和word/styles.xml这两个核心文件的结构，这是理解OpenXML最快的方式。 - 使用官方包：通过NuGet安装
DocumentFormat.OpenXml（建议2.19或更高版本）。 - 链式构建，别手搓XML：不要尝试手动拼接XML字符串。正确的做法是利用
MainDocumentPart、Body、Paragraph、Run、Text这些对象进行链式构建。例如：var doc = new WordprocessingDocument(stream, FileMode.Create); var mainPart = doc.AddMainDocumentPart(); mainPart.Document = new Document(); var body = mainPart.Document.Append(new Body()); body.Append(new Paragraph(new Run(new Text("Hello")))); - 注意“零件”管理：处理表格、图片、页眉页脚时，它们都需要对应的Part（如
TablePart、ImagePart、HeaderPart）。务必记得调用AddPart()方法，否则很容易遇到Cannot insert a duplicate part这类令人困惑的错误。
用 DocX 或 NPOI 快速出简单文档，但得清楚它们的边界
对于追求开发速度、文档复杂度不高的场景，一些第三方库提供了更便捷的选择。DocX（即Xceed.Words.NET）可以看作是对OpenXML的一层友好封装，它的API设计更贴近Word的UI操作逻辑，适合快速生成包含格式、表格和图片的文档。而 NPOI 虽然以处理Excel闻名，但其Word模块（HWPF / XWPF）主要强在读取，写入功能相当基础，通常不推荐用于生成全新的复杂文档。
选用它们，你需要了解这些实践细节：
- DocX的适用场景：它非常适合中小项目的原型开发或内部工具。通过NuGet安装即可。需要注意的是，在.NET 6+环境下，它可能不支持默认的TLS版本，需要显式设置
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12。 - DocX的细节坑：插入图片时必须提供绝对路径或
byte[]数据，使用相对路径通常会失败。另外，给表格加边框可不是一键操作，需要遍历每个Cell单独设置Border属性。 - NPOI的局限性：使用
NPOI.XWPF的XWPFDocument确实可以新建文档，但它对样式继承、目录生成、复杂分节等高级功能的支持很弱。生成的文档用Word打开时，常常会弹出“内容有问题”的修复提示，而修复后样式大概率会丢失。 - 共同的禁区：必须清醒认识到，这些第三方库普遍无法处理宏（Macro）、ActiveX控件或OLE嵌入对象。如果业务涉及这些，恐怕只能退回风险重重的Interop方案。
生成 DOC 而非 DOCX？基本没靠谱方案
如果客户坚持要旧版的二进制 .doc 格式，那么坦白说，你几乎找不到一个完美且可靠的.NET方案。原因在于，.doc 格式的规范并未公开，微软也从未提供官方的.NET API支持。OpenXML SDK 只针对 .docx；Interop 虽然能通过“另存为”得到 .doc 文件，但依赖Word且输出质量不可控（字体替换、公式错位是家常便饭）；至于 NPOI.HWPF，其写入能力几乎为零，且项目早已停止维护。
面对这种“历史遗留需求”，可以尝试以下路径：
- 优先沟通，推动升级：第一选择永远是说服客户改用
.docx格式。这是自Office 2007以来的标准格式，兼容性毫无问题，而且是国际标准（ISO/IEC 29500）。 - 不得已的备选：如果沟通无效，只能采用
Interop方案：准备一个.doc格式的模板文件，用Word打开后填充内容，再调用Document.Sa veAs2(FileName: "x.doc", FileFormat: WdSa veFormat.wdFormatDocument)保存。关键前提是，目标机器必须安装完整版Office，精简版或绿色版很可能不支持。 - 绝对的红线：千万不要尝试自己通过字节流拼接或者逆向
HWPF来生成.doc文件。已有大量前车之鉴表明，文档结构的微小偏差就可能导致文件彻底损坏且无法恢复。
真正考验功力的，从来不是“如何写出一行字”，而是如何确保样式继承链完美对齐、让列表编号在复杂分页后依然连续、分节符与页眉页脚的关联牢不可破、嵌入的字体不会被意外剥离。这些细节往往不会在代码运行时抛出异常，却会在用户双击打开文档的瞬间，暴露无遗。
