简介：VC++操作Word文档是一份面向VC++开发者的组件对象模型（COM）自动化编程实例，演示在Visual Studio 2008环境下使用微软基础类库封装Word对象模型，完成文档的打开、读取、修改、保存等自动化操作，适合需要编写报表生成、批量文书处理、文档格式转换等工具的工程师参考。压缩包共44个文件，体积约89KB，属于轻量级示例代码。其中30个头文件逐一封装了Word的常用类与对象，如应用程序、文档、区域、选区、表格、段落、查找等；4个C++源文件包含基本的对话框程序框架和调用示例；2个Word文档作为测试文件；另有工程配置文件与说明文本，结构清晰，可直接编译运行。资源发布以来已有426人学习，较受欢迎。代码目录完整度高，几乎覆盖Word对象模型的主要类型，读者可以在不陷入底层接口细节的前提下快速搭建自己的Word操作模块。通过研读这些封装类，还能掌握使用派发接口调用COM自动化对象的关键写法，并注意异常处理和对象释放，为后续扩展到Excel、PowerPoint等办公自动化场景打下扎实基础。
1. VC++操作Word文档：为什么这个老技术还值得你花半小时上手
做桌面工具的人迟早会接到同一个需求：把数据生成一份格式固定、能直接打印或归档的 Word 文档。我见过很多团队的第一反应是找开源库，绕了一圈又回到原生方案——用 VC++ 调 Word 的 COM 接口，让 Word 自己在后台完成排版。这个方案的好处是生成的文档和你手工打开 Word 排版的效果几乎一致，表格、页眉、页码、域都可以控制，不需要在代码里重新实现一套排版引擎。适合的场景很明确：内部工装、检测报告生成器、合同批量填写、导出 Word 版数据报表。这篇文章按我自己的使用路径来讲：先说明 COM 调用 Word 的原理和工程配置，再给出能跑通的最小代码，然后讲模板填充、格式控制、表格操作，最后把最容易翻车的几个坑逐个说明。
2. 从 COM 原理到环境准备：搞清楚 VC++ 操作 Word 到底在做什么
2.1 COM 自动化背后的对象模型：你调的不是文件，是 Word 进程
说清楚原理很重要，否则排错时完全靠玄学。Word 本身是个独立的进程，VC++ 程序想让它干活，靠的是 COM（组件对象模型）。你的代码创建的是一个Application对象，这个对象指向正在运行的 Word 进程内部暴露出来的自动化接口。你通过接口命令它打开文档、查找文本、写入表格，Word 进程自己去执行这些操作。生成文档时的排版渲染全部由 Word 自己完成，你的程序只是"发号施令"。
Word 自动化对象模型的顶层是Application，下面挂着Documents集合，集合里是Document对象，文档再往下有Content、Range、Find、Tables、Bookmarks、Paragraphs这些对象。调用链路基本是：创建Application-> 取Documents-> 打开或新增Document-> 用Range或Find定位内容 -> 写入或替换文本 ->Save/SaveAs->Close->Quit。在 VC++ 里，我们通过#import指令引入 Word 类型库（.olb文件），编译器会生成对应的智能指针包装类，比如_ApplicationPtr、DocumentPtr等，代码写起来和操作普通 C++ 对象很像。
另一个关键概念是绑定方式。常见做法是早期绑定（导入类型库，编译期就确定接口），开发时能看到完整的成员列表，代码提示和编译检查都友好；但缺点是和特定版本的 Word 类型库耦合。另一个做法是晚期绑定（用IDispatch::Invoke按名称调用成员），接口名写错要等运行时才报错。我一般用早期绑定配合ProgID创建实例，后面会详细说明为什么这样可以兼顾开发效率和版本兼容。
2.2 工程配置与类型库引入：把三处设置一次做对
VC++ 项目要操作 Word，工程配置有三处最容易出错。第一处：MFC 项目要在InitInstance里调用AfxOleInit()，纯 Win32 项目用CoInitializeEx(NULL, COINIT_APARTMENTTHREADED)初始化 COM 套间。第二处：在stdafx.h或某个公共头文件里写#import指令，引入 Word 类型库。第三处：项目字符集必须使用 Unicode，操作文档里的中文时，窄字符转换问题会非常折磨人。
#import指令有一个常见写法：
#import "C:\\Program Files\\Office16\\MSWORD.OLB" \ rename("ExitWindows", "wordExitWindows") \ rename("FindText", "wordFindText") \ no_namespace这段指令说明：#import让编译器读取类型库并生成.tlh、.tli包装头文件；rename重命名了和系统接口重名的符号，防止编译冲突；no_namespace让生成的类型不包在命名空间里，调用更简洁。路径里的Office16对应 Office 2016 及更新版本，不同电脑上 Office 安装路径和版本可能不同，直接把类型库路径写死到代码里会让程序换台机器就编不过。
更稳妥的做法是让编译器去注册表里找类型库。把上面的#import改成这样：
#import "libid:000209FF-0000-4C00-0000-000000000046" \ rename("ExitWindows", "wordExitWindows") \ rename("FindText", "wordFindText") \ no_namespacelibid是 Word 类型库在注册表中的唯一标识，不依赖具体安装路径。编译器会根据libid去注册表里查找对应的类型库文件位置。这样项目换到装 Office 的机器上都能编译。要注意的是，本机必须有 Word 或者完整 Office 组件，只有 WPS 不一定注册这个libid，编译阶段就会失败。
配置完成后先做一个最简单的探测：用一句代码创建Application实例，看能否成功。下面这个代码块验证工程配置是否正确：
#include <afxdisp.h> BOOL bComReady = FALSE; HRESULT hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); if (SUCCEEDED(hr)) { CLSID clsid; hr = CLSIDFromProgID(L"Word.Application", &clsid); if (SUCCEEDED(hr)) { _ApplicationPtr pApp; hr = pApp.CreateInstance(clsid); if (SUCCEEDED(hr)) { pApp->Visible = FALSE; pApp->Quit(); pApp = NULL; bComReady = TRUE; } } CoUninitialize(); }这段逻辑要说明白：CoInitializeEx初始化 COM 套间，线程模型用APARTMENTTHREADED，因为 Word 的自动化接口在大多数场景下都支持这个模型；CLSIDFromProgID把Word.Application这个编程标识符转换成实际的CLSID，这才是CreateInstance真正要的参数；CreateInstance本质上是启动一个 Word 进程并返回自动化接口指针；Visible = FALSE让 Word 在后台运行，不弹窗口；最后Quit再置空指针。如果这段代码能跑通，说明类型库引入和工作环境都没问题，可以进入真正的文档操作。如果CreateInstance失败，优先检查 COM 初始化是否成功以及注册表中是否有 Word 的ProgID。
3. 用 VC++ 把 Word 文档打开、生成、保存写进代码
3.1 创建新文档并写入内容：最小可跑通的完整代码
环境没问题之后，我通常先把"新建文档、写一句话、保存、关闭"这四步跑通，再往上加功能。下面的代码是一个完整的函数，能生成一个新的.docx文件：
void GenerateSimpleDoc(const CStringW& strFilePath, const CStringW& strContent) { HRESULT hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); if (FAILED(hr)) return; CLSID clsid; CLSIDFromProgID(L"Word.Application", &clsid); _ApplicationPtr pApp; if (FAILED(pApp.CreateInstance(clsid))) return; pApp->Visible = FALSE; DocumentsPtr pDocs = pApp->GetDocuments(); DocumentPtr pDoc = pDocs->Add(); _bstr_t bstrContent(strContent); pDoc->Content->Select(); SelectionPtr pSel = pApp->GetSelection(); pSel->TypeText(bstrContent); _bstr_t bstrPath(strFilePath); pDoc->SaveAs2(bstrPath, wdFormatXMLDocument); pDoc->Close(); pApp->Quit(); pSel = NULL; pDoc = NULL; pDocs = NULL; pApp = NULL; CoUninitialize(); }这段代码的关键是操作顺序：GetDocuments()拿到文档集合，Add()新建一个空白文档；Content->Select()把光标定位到文档主体区域；Selection对象的TypeText在光标处输入文本，好处是文本会继承当前光标的默认格式；SaveAs2是 Word 2010 之后新增的保存接口，兼容旧版本可以用SaveAs。wdFormatXMLDocument是.docx格式对应的枚举值，如果需要生成.doc就用wdFormatDocument并保存成.doc文件名。函数结束前把所有接口指针置空再CoUninitialize，这一步是防止 Word 进程残留的关键，后面避坑章节还会重点讲。
3.2 打开已有文档：路径、只读模式和格式参数的设置
和新建文档不同，打开已有文档时我们需要传入明确的参数。Documents->Open的签名参数很多，但实际使用中我一般只设置最关键的几个：
_variant_t vPath(strFilePath); _variant_t vReadOnly(true); _variant_t vAddToRecentFiles(false); _variant_t vVisible(false); // 文档打开后不显示 DocumentPtr pDoc = pDocs->Open( vPath, // FileName vReadOnly, // ConfirmConversions: 理解为只读标记 vReadOnly, // ReadOnly vAddToRecentFiles, // AddToRecentFiles vVisible, // PasswordDocument, 顺位占位 vVisible, // PasswordTemplate, 占位 vVisible, // Revert vVisible, // WritePasswordDocument vVisible, // WritePasswordTemplate vVisible, // Format vVisible // OpenAndRepair );这段代码要说明为什么这么多vVisible占位：Open方法的前 11 个参数是变体类型，每个都必须给出_variant_t值，缺一个都不行。常见的做法是把不需要的关键参数填VARIANT_TRUE或VARIANT_FALSE。vReadOnly(true)的作用是打开文档时禁止修改原文件，生成报告的场景下建议开启，避免程序误改模板。vAddToRecentFiles(false)是让 Word 不要把这个文件加进"最近使用的文档"列表，减少对用户的干扰。
参数设置完之后，检查是否真正打开成功，有一个简单办法：pDoc智能指针如果为NULL，说明Open内部失败，通常原因是路径不存在或者文件已经被占用。建议在打开前先用GetFileAttributes验证路径有效性，给用户更准确的提示，而不是让 Word 弹出一个英文错误框。文件占用问题也很常见，尤其之前有残留的WINWORD.EXE进程锁着文件，打开会返回HRESULT错误0x800A1066，这时排查方向不是代码逻辑而是进程残留。
3.3 保存文档的不同形态：覆盖保存、另存为新名和导出 PDF
保存操作有三种常见形态：原文件覆盖保存、另存为新名、另存为 PDF 或纯文本。覆盖保存最简单，直接调pDoc->Save()；但生成报告的常见做法是另存，把数据文件和新文件名分别设置，避免手动清理临时文件。
_bstr_t bstrNewPath(newFilePath); // 覆盖式保存：文档当前内容直接写回原路径 pDoc->Save(); // 另存为新名：指定格式为 docx pDoc->SaveAs2(bstrNewPath, wdFormatXMLDocument); // 另存为 PDF：注意目录名不能含特殊字符 pDoc->SaveAs2(bstrNewPath, wdFormatPDF);代码里wdFormatPDF是常用的格式枚举值之一。这里有一个容易忽略的点：SaveAs2出来的文件格式是否可用，取决于目标机器里的 Word 是否安装了对应的导出组件。标准 Office 安装一般都有，但精简版可能没有 PDF 导出功能。生成后最好用GetFileAttributes确认文件确实出现在磁盘上，而且大小不为 0。如果文件存在但内容是空白，多半是Content写入环节出了错，需要回到写入逻辑去排查。
另一个注意点是：保存路径如果是中文目录，比如C:\报告\一月\质量报告.docx，_bstr_t构造必须用宽字符版本。传统的CString在未开启 Unicode 字符集时传给_bstr_t会丢失汉字，这是字符集问题的重灾区。我个人在项目里统一用CStringW，传参数时用_bstr_t((LPCTSTR)strPathW)，从根上避开编码转换。
4. 让 Word 文档按你的模板走：查找替换、格式控制与表格操作
4.1 查找替换：批量生成合同时最常用的一条路径
如果模板里预先写好了"占位符"，程序必须把占位符替换成真实数据。Word 的Find对象就是干这个的，它和你在 Word 界面里按Ctrl+H是同一个功能。下面演示核心用法：
void ReplacePlaceholder(DocumentPtr pDoc, const wchar_t* oldText, const wchar_t* newText) { FindPtr pFind = pDoc->GetContent()->GetFind(); pFind->ClearFormatting(); pFind->GetReplacement()->ClearFormatting(); _bstr_t bstrOld(oldText); _bstr_t bstrNew(newText); pFind->Put_Text(bstrOld); pFind->GetReplacement()->Put_Text(bstrNew); VARIANT_BOOL bForward = VARIANT_TRUE; VARIANT_BOOL bWrap = wdFindStop; VARIANT_BOOL bReplace = VARIANT_TRUE; pFind->Execute( bstrOld, // FindText bForward, // Forward bWrap, // Wrap bReplace, // ReplaceWith NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL ); }这块代码的逻辑链是：Content->GetFind()拿到文档全范围的查找器；ClearFormatting清掉查找条件和替换文本可能继承的字体格式，否则你替换上去的文字会莫名其妙变成模板里占位符的字体和字号；Put_Text分别设置查找目标和替换目标；Execute是真正执行查找替换的动作，第一个参数是FindText，第三个参数Wrap设为wdFindStop表示找到最后就停，不会循环查找；最后一个参数ReplaceWith这里传了bReplace（值为VARIANT_TRUE），表示执行替换。
值得多说一句：Execute的参数个数很多，不同版本的 Word 类型库生成的头文件里签名可能有细微差异，编译报错的时候优先查参数个数和类型，不要先怀疑逻辑。替换动作完成后，如果模板里有多个占位符，把上面函数循环调用几次即可。
4.2 字体、段落与页面设置：给生成文档定基本样式
模板替换只能改文字，如果要从零生成一份排版完整的文档，需要控制Font、ParagraphFormat、PageSetup这些对象。下面这段代码设置了文档整体的基础样式：
// 设置文档内容默认字体和大小 pDoc->GetContent()->GetFont()->Put_Name(L"宋体"); pDoc->GetContent()->GetFont()->Put_Size(12); // 设置第一段的段落属性：居中、行距固定值 22 磅 ParagraphPtr pPara = pDoc->GetParagraphs()->GetFirst(); pPara->Put_Alignment(wdAlignParagraphCenter); pPara->GetFormat()->Put_LineSpacingRule(wdLineSpaceExactly); pPara->GetFormat()->Put_LineSpacing(22); // 设置页面边距：上下左右各 2.5 厘米 PageSetupPtr pPage = pDoc->GetPageSetup(); pPage->Put_TopMargin(70.9); // 单位是磅，2.5 厘米约 70.9 磅 pPage->Put_BottomMargin(70.9); pPage->Put_LeftMargin(70.9); pPage->Put_RightMargin(70.9);为什么单位是磅而不是厘米？因为 Word 内部长度单位就是磅，你在界面里看到厘米，COM 接口里仍用磅表示。1 厘米约等于 28.35 磅，2.5 厘米就是 70.9 磅左右。这个单位问题我第一次用的时候没注意，直接把 2.5 传进去，结果页面边距窄得几乎看不见。字体名称建议用"宋体"、"微软雅黑"这些系统中文字体名，不能像新宋体那样混入其他样式；如果你不确定目标机器有没有某个字体，先选最通用的宋体，否则排版会全部乱掉。
对段落操作还要注意ParagraphFormat与Paragraph的区别：Paragraph对象是段落个体，ParagraphFormat是段落格式。实际使用中不少人把pPara->Put_Alignment写错，更稳的写法是pPara->GetFormat()->Put_Alignment(...)。两种写法在老版本类型库里都存在，优先用GetFormat()方式，兼容性更好。
4.3 表格写入与数据提取：读写 Word 表格的两个方向
报告类文档离不开表格。Word 表格在 COM 对象模型里对应Tables集合和Table对象。表格的读写都要先定位表格，再定位单元格。看例子：
// 在文档末尾新增一个 3 行 4 列的表格 RangePtr pEndRange = pDoc->GetContent(); pEndRange->Collapse(wdCollapseEnd); TablePtr pTable = pDoc->GetTables()->Add( pEndRange, 3, // NumRows 4, // NumColumns wdAutoFitWindow, NULL // DefaultTableBehavior 默认值 ); // 往第 2 行第 3 列写入数据 pTable->GetCell(2, 3)->GetRange()->Put_Text(L"实测值"); // 给表格应用内置样式 pTable->Put_Style(L"网格型");Tables->Add的第一个参数必须是插入位置的一个Range，直接用Content会把表格插入到文档开头的段落上，所以先Collapse(wdCollapseEnd)把范围折叠到文档末尾。wdAutoFitWindow让表格宽度自适应页面宽度，这比硬编码列宽更安全。GetCell(2, 3)返回第 2 行第 3 列的单元格，行号列号从 1 开始，不是从 0 开始，这是个容易犯的编码思维错位。
反方向的数据提取同理：遍历表格的Rows和Columns，用Cell(i, j)->GetRange()->GetText()拿单元格文本。提取时要注意Text末尾会带一个\r\x07（回车和单元格结束符），直接拼接会混入特殊字符，需要自己裁剪。我一般写一个小函数，把首尾两个字符截掉再返回。表格对象的操作还有个隐性坑：对单元格写入文本后，如果写入的内容带有换行符，Word 表格会自动拆行或扩展行高，排版结果可能和预期不同，所以我通常用纯文本字符串传入，换行控制在单元格外部完成。
5. VC++ 操作 Word 的 5 个必经大坑：进程残留、格式丢字与异常崩溃
这个章节每条记录我都按"现象 -> 原因 -> 解决"来描述，内容全部来自实际开发中的踩坑记录。
5.1 坑一：任务管理器里 WINWORD.EXE 残留，文档被锁死
现象：程序退出后，任务管理器的进程列表里能看到多个WINWORD.EXE，下次运行程序则打不开之前生成过的文档，提示文件正在被另一进程使用。
原因：COM 智能指针pApp、pDoc、pSel等对象在作用域结束时如果没有显式置空，或者Quit()调用失败（比如之前某行代码抛了异常），Word 进程就不会退出。MFC 程序在未调用CoUninitialize的情况下退出，COM 运行库来不及通知 Word 释放对象，进程便一直挂在后台。
解决：在正常流程里，每个接口指针用完立即置NULL；把Quit放在剪切板清理之后；用__try/__catch或 MFC 的CATCH块捕获异常，确保异常分支也执行Quit和指针置空。我一般把释放动作封装到一个ReleaseWord()函数，在函数出口统一调用。如果确实出现了顽固残留进程，也可以在程序启动时枚举进程清理WINWORD.EXE，但风险较高，不建议主动结束用户正在使用的 Word 进程，正确做法是把自己的实例管好。
5.2 坑二：中文路径显示为下划线或乱码，保存时崩溃
现象：用CString传递中文路径时，生成的文档名变成"___报告.docx"，或程序在SaveAs2时抛出0x800A1020。
原因：项目字符集是"多字节字符集"，CString内部的窄字符需要转换，而_variant_t构造时拿到了错误的字符编码。COM 统一使用BSTR宽字符，不识别当前代码页的窄字符串。路径传入时如果有非 ASCII 字符，转换过程没有设置指定代码页，导致中文全部丢失。
解决：项目属性里把字符集设为"使用 Unicode 字符集"，CString使用CStringW；传参时通过_bstr_t(strContentW)或SysAllocString把宽字符转成BSTR。如果项目必须兼容旧的窄字符代码，至少保证所有 Word 接口参数走CStringW，不做隐式转换。我把这个总结成一条铁律：Word 的 COM 参数，一律宽字符，一律显式转 _variant_t。
5.3 坑三：替换文本后，字体格式跟模板不一致
现象：Find.Execute执行完，目标文本替换成功了，但替换后的文字变成宋体加粗或变大了，和周围排版不搭。
原因：查找和替换文本都默认继承了模板里占位符的格式。如果占位符本身是某一种格式，替换内容就会保持那个格式；如果替换内容还要和容器格式一致，但ClearFormatting只清了查找条件，没有清替换条件，同样会出问题。
解决：替换前对pFind->ClearFormatting()和pFind->GetReplacement()->ClearFormatting()都调用一次，让替换文本遵循模板所在位置的段落和字体默认格式。如果仍需要特定字体，在替换执行前显式设置GetReplacement()->GetFont()->Put_Name(...)和Put_Size(...)。这里还有一个细节：如果替换进去的是占位符的"行内文本"，字体设置会被段落格式覆盖，所以设置字体时机尽量放在Execute之前的Replacement上，而不是替换完成后再改。
5.4 坑四：Visible = FALSE 时 Word 偶尔弹出恢复文档对话框，程序卡住
现象：程序挂后台运行，早上还能正常跑，下午升级了一个模板文件后，程序在无人值守时突然挂起不动，直到有人去服务器上点掉一个"文档恢复"界面。
原因：Word 在非交互会话中初始化自动化对象时，遇到上次非正常退出留下的"自动恢复"文件或宏安全提示，会弹出模态对话框等待用户确认；虽然Visible = FALSE，对话框依然可以弹出，程序主线程就阻塞在 COM 调用上。
解决：程序启动时设置注册表项，禁止 Word 的自动恢复对话框，或者启动过程捕获ApplicationEvent事件；更贴近实际的做法是让初始化检测当前用户的 Word 配置，如果发现异常，先按照模板的Document.Open提供一个明确的错误提示。对服务器环境，我倾向于在CreateInstance之后立刻设置pApp->Put_DisplayAlerts(0)（即wdAlertsNone），禁止所有弹窗。这样虽然会覆盖用户对弹窗的偏好，但无人值守场景下稳定压倒一切。
5.5 坑五：表格行数我传了 0，程序直接崩溃
现象：调用Tables->Add时传了0行或0列，程序没有任何报错直接崩溃；排查很长时间才发现是行号列号从 1 开始但传入了 0。
原因：Add方法内部对参数检查不严格，0可能被解释为默认值，但也有可能触发非法内存访问。另一个相近的坑是GetCell(3, 1)在表格只有 2 行时返回无效对象，继续调用GetRange()->Put_Text也会崩溃。
解决：所有涉及表格行列号的传参，先做一次越界判断，读取pTable->GetRows()->GetCount()和GetColumns()->GetCount()后再访问。另外，动态添加行时用Rows->Add()，它会在表格末尾追加一行，返回值是Row对象，有了它再去取Cells，比手写GetCell更安全。
6. 进阶技巧：用模板加书签做批量文档生成
如果你已经能操作单份文档，下一步就是批量。批量生成报告最常见的方式不是逐条查找替换，而在模板里预先埋好书签（Bookmark），然后循环填充书签。书签比查找替换快的核心原因是：书签是文档范围内的位置引用，通过书签名直接定位，不用扫描全文文本匹配占位符。
// 模板里预先插入书签：ProjectName、FactoryName、InspectDate、Conclusion void FillBookmark(DocumentPtr pDoc, const wchar_t* bkName, const wchar_t* value) { _bstr_t bstrBk(bkName); BookmarkPtr pBk = pDoc->GetBookmarks()->GetItem(bstrBk); if (pBk != NULL) { _bstr_t bstrVal(value); pBk->GetRange()->Put_Text(bstrVal); // 注意：写入文本后书签会被自动删除，同一模板再次运行时需重新添加到书签集合 RangePtr pRng = pDoc->GetBookmarks()->GetLast()->GetRange(); pDoc->GetBookmarks()->Add(bstrBk, pRng); } }注意最后三行：书签写入文本后，Word 会把原来的书签吞掉，如果循环里还要重复使用同名书签，必须用Bookmarks->Add把它加回来。Add的第二个参数是Range，我取了书签写入后两个字符的范围，目的是让书签重新存在，下次循环还能定位到。这个技巧花了我小半天才折腾明白，所以特意写在这里。
批量生成时还有两个性能相关的实践。第一个是单实例复用：循环里不要每次都CreateInstance新建 Word 进程，而是启动一次Application，在循环里反复Open -> 填充 -> SaveAs2 -> Close，最后再Quit。我在模拟项目 X 里生成几百份报告，单实例比每份新建实例快一个量级。第二个是关闭屏幕刷新：pApp->Put_ScreenUpdating(FALSE)，因为后台操作不刷新界面，Word 进程的 CPU 占用会明显下降，大批量场景从半小时缩短到几分钟。
最后说一个真实发生的教训：第一次做批量生成时，我图省事直接在Document上逐段设置字体，几百份文档跑到一半，内存涨到系统卡死。后来改成"所有格式在模板里一次设好，程序只负责填充书签和保存"，内存平稳，时间减半。这个方向后来成了团队里的规范：模板能承载的样式，绝对不放到代码里设置；代码只做动态数据的写入和文件归档。做完这些，再用批量生成的 100 份文档做一次文件名、页数、正文关键字段的抽查，基本就能放心交付。希望这些踩坑经验能帮到你。
本文还有配套的精品资源，点击获取
