用 Microsoft.Office.Interop.Word 转 PDF 卡死或报错，是因为该组件依赖本地安装的桌面版 Word，未安装或使用 WPS/Office Online 等替代品均不支持；需确认安装完整版 Word、以管理员权限运行、避免在无交互会话中调用。
用 Microsoft.Office.Interop.Word 转 PDF 会卡死或报错？先确认你有没有装桌面版 Word
这个组件不是独立库，它本质是启动本地安装的 word 程序做自动化操作。没装 word（尤其是没装带完整 ui 的桌面版），applicationclass 初始化就会失败，常见错误是 comexception: 检索 com 类工厂中 clsid 为 {000209ff-0000-0000-c000-000000000046} 的组件时失败。wps、office online、甚至 microsoft 365 app（非传统桌面版）都不支持。
实操建议：
- 检查系统是否安装了完整版 Microsoft Word（如 Office 2016/2019/2021 或 Microsoft 365 桌面应用）
- 以管理员权限运行你的 C# 程序（尤其在 Windows Server 上，Word 启动常因权限被拦截）
- 不要在 IIS、Windows Service 或无交互会话（Session 0）中调用 —— Word 需要桌面会话环境
- 若部署在服务器，优先换方案（见下一条）
为什么 Document.ExportAsFixedFormat 导出 PDF 后字体乱码或排版偏移？
这是 Interop 最典型的“隐形坑”：Word 后台进程默认使用系统默认打印机上下文渲染 PDF，而服务器常无默认打印机或字体映射缺失。哪怕代码里指定了 ExportFormat.Pdf，底层仍依赖 GDI 打印子系统。
实操建议：
- 务必在调用前设置
wordApp.Visible = false和wordApp.DisplayAlerts = WdAlertLevel.wdAlertsNone，避免弹窗阻塞 - 导出前显式指定打印机：
wordApp.ActivePrinter = "Microsoft Print to PDF"（需系统已安装该虚拟打印机） - 确保文档中所有字体在目标机器上存在；中文推荐用
SimSun、Microsoft YaHei这类系统自带字体，避免嵌入未授权字体 - 导出后立即调用
doc.Close(false)和wordApp.Quit()，否则 Word 进程残留会导致后续调用变慢甚至崩溃
替代方案：不用 Office 组件，用 DocX + QuestPDF 或 Syncfusion.DocIO 可行吗？
可以，但要注意能力边界。原生 Interop 能处理宏、OLE 对象、复杂页眉页脚、修订标记等；纯 .NET 库大多只支持“渲染结果”，不解析 Word 逻辑结构。
实操建议：
-
DocX（ClosedXML 衍生）只能读写 .docx 结构，不能直接转 PDF —— 得配合其他 PDF 库（如iTextSharp）手动重排版，工作量大且失真率高 -
Syncfusion.DocIO支持ConvertToPDF，但需商业授权；免费版有水印，且对 VBA、ActiveX、某些域字段支持弱 - 真正轻量可靠的组合是：
DocX解析文本/表格 → 用QuestPDF生成语义一致的 PDF（适合报表、合同等结构化文档） - 如果原文档含扫描件、手写批注、签名行——别硬转，直接用
Word.Application是目前最稳的选择
为什么本地能跑通，一上服务器就超时或内存暴涨？
根本原因是 Word 进程没有被正确回收。.NET 的 COM 互操作不会自动 GC 进程，尤其在高并发场景下，每个请求都 new 一个 Application，却没调用 Quit() 或没释放 COM 引用，Word 实例越积越多。
实操建议：
- 绝对不要在循环里反复 new
Application；应复用单例（注意线程安全）或严格控制生命周期 - 必须用
try/finally包裹，确保doc?.Close()和app?.Quit()执行；别依赖 using（它不释放 COM 对象） - 调用
Marshal.ReleaseComObject(app)显式释放（调一次即可，多次会崩） - 服务器上建议加超时保护：用
Process.GetProcessesByName("WINWORD")定期扫残留进程并Kill()
Interop 调用看着像普通 API，实际是跨进程、跨会话、跨权限边界的重型操作。每一步松懈，都会在凌晨三点变成一个没日志、没堆栈、只剩 WINWORD.exe 占满 CPU 的告警。
