企业官网建设流程全解析

1. 先把这件事想明白：为什么值得花时间批量转 .doc

如果你手头有一堆历史遗留的 .doc 文件，同时还被要求"统一成新格式归档"，那你多半已经意识到，一个个双击打开、另存为、关掉、再打开下一个，是纯粹的体力活。我需要处理的场景很典型：一个归档目录里躺着几千个 .doc，混杂着子文件夹、扫描件转录稿、带修订记录的合同、几份加了密码的老报表，还有一堆~$开头的临时文件。把这些文件批量转成 .docx，就是这篇内容要聊的核心。

先给结论：用 Microsoft Word 自带的对象模型批量另存，是这些方案里兼容性最好、排版损失最小的一条路。它不需要装额外的转换引擎，不需要联网，不需要上传任何文件到第三方服务，转换结果和手工"另存为"完全一致。代价是速度慢——单个文件从几百毫秒到几秒不等，取决于文件大小和机器性能。这个代价我认为完全值得，因为一旦遇到复杂表格、文本框、老式公式对象、页眉页脚里的域代码，只有 Word 自己最懂 Word 自己的格式。

这篇内容适合三类人看：一是要把成百上千份档案统一格式的文档管理员；二是需要在系统升级前做一次格式迁移的技术支持；三是单纯被 .doc 折磨过、想学一套干净利落批处理办法的普通办公用户。全文从原理讲到代码，从代码讲到踩坑，你可以直接抄。

1.1 .doc 和 .docx 到底差在哪，为什么不能直接改扩展名

这是我必须最先说的一件事，因为每年都有人问：能不能用ren *.doc *.docx批量改名搞定？

绝对不能。这两种格式的区别不在文件名，而在文件内部结构。

.doc 是 Word 97-2003 使用的二进制格式，本质上是一个复合文档容器，把正文、样式表、字体表、图片流分别存在不同的"流"里，结构由一串复杂的偏移量指针串联。你用十六进制编辑器打开，文件头是D0 CF 11 E0 A1 B1 1A E1这八个字节。

.docx 走的是完全不同的路线，它是 Office Open XML 格式，本质上是一个 ZIP 压缩包，里面装着document.xml、styles.xml、numbering.xml、media/等一堆独立部件，用 XML 描述内容，用关系文件描述部件之间的引用。文件头是50 4B 03 04，也就是 ZIP 的标志。

所以你把 .doc 改名成 .docx，只是把一个二进制复合文档贴上了 ZIP 的标签，Word 打开时会检测到内部结构不匹配，大概率弹出"文件已损坏"或者提示格式不符。就算侥幸打开了，内容也未必正常。

我实测过一个 300 多份文件的目录，用改名法处理后，Word 能正常打开的比例不到两成，其余全部报错。后来老老实实重跑一遍真正的格式转换才解决。这个教训值得写进任何一份操作手册的第一行。

改名不等于转码，格式转换必须走"打开—解析—重新序列化"的完整流程，也就是 Word 的"另存为"。

1.2 转换能带来哪些实际收益

抛开"领导要求统一格式"这种理由不谈，转换本身是有技术收益的。

体积会明显缩小。二进制格式的历史包袱很重，同样的内容，.doc 常常比 .docx 大 30% 到 60%。我统计过一批纯文本类文档，平均压缩比接近 45%。几千份文件放在一起，节省的空间是实打实的。

容错性更好。ZIP 结构天然支持 CRC 校验，文件局部损坏时 .docx 的恢复能力比 .doc 强。二进制格式一旦中间的指针链断裂，后半部分内容往往整体丢失。

可被现代工具解析。这是最关键的一条。python-docx、docx4j、Open XML SDK 这一整类库只能处理 OOXML，也就是 .docx 体系，对 .doc 二进制格式基本无能为力。如果后续要做全文检索、内容抽取、批量正则替换、文档自动生成，格式不转成 .docx，后面所有自动化都无从谈起。

协作和审阅更稳定。修订记录、批注、比较文档这些功能在 .docx 上的行为更可预测，尤其是在多人来回传阅的场景里，.doc 的修订信息偶尔会出现错乱。

反过来也要说清楚：如果这批文档将来只在老版本 Office 环境里打开，或者里面有大量老式 ActiveX 控件、宏、嵌入式 OLE 对象，转换反而可能引入麻烦。这部分我在第 1.3 节详细展开。

1.3 转换会牵动哪些环节，影响范围拆解

很多人把格式转换当成一个孤立动作，实际上它会向外波及好几个层面，提前想清楚能省掉大量返工。

这张表不是吓唬人，是我在实际项目里一条条踩出来的。最典型的一次是：某批文档里嵌了几十个公式对象，转换完发现公式全变成了不可编辑的图片，后来只能从原始录入文件重新生成。如果事先做一次抽样检查，这个坑完全可以避开。

2. 四条路线摆上桌：方案选型到底怎么选

动手写代码之前，先把可选的路子列全。我按"是否依赖本地安装 Word"这条主线分了四类，各有各的适用边界。

2.1 四种主流方案横向对比

表格里"排版保真度"这一列是核心。第三方办公套件的转换引擎对复杂排版的还原能力确实不如 Word 自己，尤其是多级编号的表格、艺术字、文本框环绕、分栏页眉这些，我见过转换后文字整体错位的案例。如果你的文档以纯文字和简单表格为主，第三方方案完全够用，而且速度快得多；如果里面有大量精排版内容，还是老老实实让 Word 出手。

2.2 我为什么最终押注 VBA 宏

理由有三个，按权重排序。

第一，控制粒度够细。宏里可以拿到每一个 Document 对象的属性，判断它有没有 VBA 工程、有没有密码、当前兼容模式是什么、保存时要不要更新域、要不要嵌入字体。这些决策点用命令行工具几乎无法干预，用 PowerShell 能做但写起来啰嗦。

第二，异常处理可以做得比较体面。一批几千个文件里必然有几个坏的、加密的、被别人占用的。宏里用On Error逐个捕获，记录到日志里继续跑，不会因为第 37 个文件打不开就整批中断。

第三，部署成本极低。一个 .bas 文件导入，或者直接把代码贴进 VBA 编辑器，就能跑。不用装任何东西，不用配环境变量，不用管权限，对非技术同事也友好——他们只需要按一个按钮。

PowerShell 那条路我也写过，优势在于可以和外部的文件扫描、日志采集、任务调度串起来，适合放进运维流水线。但如果只是"把这批文件转一下"，宏的投入产出比更高。

2.3 两个容易被高估和被低估的点

被高估的是"速度"。很多人以为批量处理就是几秒钟的事，实际上 Word 打开一个文件要加载渲染引擎、解析样式、做后台分页，单份耗时通常在小几秒量级。我用一台普通办公机测过，一份 200KB 左右、十几页的文档，平均耗时 1.2 秒左右，加上保存和关闭，单份接近 2 秒。两千份就是将近一个小时。这个心理预期要提前建立，别让操作的人以为卡死了。

被低估的是"准备工作"。真正花时间的不是写那几十行代码，而是转换之前的文件清点、临时文件剔除、只读属性清理、备份策略确定。我做过统计，一个中等规模的转换任务，准备和验证阶段占了总工时的七成以上。后面几个章节我会把这块讲透。

3. 动手之前：环境和文件清单必须先收拾干净

跳过这一章直接写代码的人，通常会在第 200 个文件那里翻车。这不是危言耸听。

3.1 Word 选项里必须先改的几处设置

打开 Word，进"文件—选项"，有几处需要提前处理。

信任中心里的宏设置。如果你打算把宏放在一个独立的 .docm 模板里运行，需要把这个模板所在目录加入"受信任位置"，否则每次打开都会被安全提示拦住。这个设置路径是"信任中心—信任中心设置—受信任位置—添加新位置"，勾选"同时信任此位置的子文件夹"。

关闭"打开时更新链接"。这个藏在"选项—高级—常规"里，叫"打开时更新自动链接"。批量转换时如果开着，Word 会尝试去连邮件合并的数据源、外部图片引用，每个文件都要等超时，速度会慢到无法接受。我的做法是在宏里直接用Application.Options.UpdateLinksAtOpen = False临时关掉，跑完再恢复。

取消"键入时检查拼写和语法"。大批量打开文档时，拼写检查会消耗相当可观的时间，尤其是长文档。同样可以在宏里用Application.Options.CheckSpellingAsYouType = False临时处理。

屏幕刷新关掉。这是提速最明显的一招，Application.ScreenUpdating = False能让后面的处理快 30% 以上。原因是 Word 不需要为每个文档重绘界面。代价是你看不到处理过程，所以一定要配合进度提示或者日志。

3.2 文件清点：先把脏数据挑出去

对着一个几万文件的目录直接开跑，是最容易出事的方式。我习惯先做一次清单体检，把不干净的东西挡在门外。

必须清理的目标清单：

• 以~$开头的文件：这是 Word 的锁文件残留，本身不是文档，打开会报错。批量处理时必须跳过。
• 扩展名是 .doc 但实际不是 Word 文档的文件：有些系统导出的文件会借用 .doc 后缀，实际内容可能是 RTF、HTML 甚至纯文本。Word 打开时能靠格式探测自动识别，但会弹确认框。要在宏里设置ConfirmConversions:=False强制按默认处理。
• 零字节文件：几乎必然是传输中断的产物，直接记录到失败清单。
• 只读属性的文件：不影响打开，但会影响某些保存路径的处理。建议在转换前统一去掉只读位。
• 被其他进程占用的文件：放在共享盘或者云同步目录里的文件，经常会被同步进程锁定。转换时打开会失败，这种情况要单独列出来，等同步完成再补跑。
• 超过系统路径长度限制的文件：完整路径超过 260 个字符的文件，很多 API 调用会直接失败。转换前要先做路径长度筛查。

清点不需要写代码，用资源管理器的搜索框配合按大小排序就能筛出一部分。如果要更彻底，可以用一段脚本把所有 .doc 的相对路径、大小、修改时间导出成表格，肉眼扫一遍，异常项一目了然。

3.3 备份策略：不做备份就是给自己挖坑

我要把这句话说重一点：批量转换是不可逆的破坏性操作，没有备份就别按运行键。

原因有两个。一是转换过程中如果程序中断，某个文件可能处于"已打开未保存"的状态，源文件被锁定且内容可能已经变更。二是即使转换成功，转换后的文件在排版上也可能与原件有差异，一旦发现某批文档转坏了又没了原件，就只能重来。

我推荐的备份方式很朴素：把整个源目录复制一份到另一个物理位置，复制完做一次文件数量和总大小的比对，确认一致再动手。如果有条件，把源目录整体打包成一个压缩包并存两份，压缩包不要放在同一个磁盘上。

另外还有一个常被忽略的点：转换输出的目标目录不要和源目录混在一起。我见过有人在源目录里原地另存，结果脚本跑第二遍时把已经转换好的 .docx 又处理了一遍，虽然不会出错，但会浪费大量时间，而且文件命名混乱后很难追溯。正确做法是建一个镜像结构的目标目录，源目录里的子文件夹层级原样复制过去。

4. 核心实现一：用 VBA 宏完成整目录批量转换

这是整篇内容的重点章节，我把完整代码拆成几块讲，你可以拼起来直接用。

4.1 主流程骨架与关键参数

先看整体流程：设定源目录和目标目录，关掉一批会拖慢速度的选项，遍历目录树，逐个文件打开、另存、关闭，最后统一写日志、恢复设置。

Option Explicit Private mSrcRoot As String Private mDstRoot As String Private mOkCount As Long Private mFailCount As Long Private mSkipCount As Long Private mLogLines As Collection Public Sub BatchConvertDocToDocx() Dim fso As Object Dim oldAlerts As Long Dim oldScreen As Boolean Dim oldUpdateLinks As Boolean Dim oldSpell As Boolean Dim startTime As Double ' 1. 目录设定，结尾必须带反斜杠 mSrcRoot = "D:\Archive\Legacy\" mDstRoot = "D:\Archive\Converted\" Set fso = CreateObject("Scripting.FileSystemObject") If Not fso.FolderExists(mSrcRoot) Then MsgBox "源目录不存在，请检查路径：" & vbCrLf & mSrcRoot, vbCritical Exit Sub End If If Not fso.FolderExists(mDstRoot) Then fso.CreateFolder mDstRoot If MsgBox("即将处理 " & mSrcRoot & vbCrLf & "输出到 " & mDstRoot & vbCrLf & "确认继续？", _ vbYesNo + vbQuestion) <> vbYes Then Exit Sub ' 2. 保存并临时关闭影响性能的选项 oldAlerts = Application.DisplayAlerts oldScreen = Application.ScreenUpdating oldUpdateLinks = Application.Options.UpdateLinksAtOpen oldSpell = Application.Options.CheckSpellingAsYouType Application.DisplayAlerts = wdAlertsNone Application.ScreenUpdating = False Application.Options.UpdateLinksAtOpen = False Application.Options.CheckSpellingAsYouType = False Application.Options.UpdateFieldsAtPrint = False mOkCount = 0: mFailCount = 0: mSkipCount = 0 Set mLogLines = New Collection startTime = Timer ' 3. 递归处理 ProcessFolder fso, fso.GetFolder(mSrcRoot) ' 4. 恢复现场，这一步千万别漏 Application.DisplayAlerts = oldAlerts Application.ScreenUpdating = oldScreen Application.Options.UpdateLinksAtOpen = oldUpdateLinks Application.Options.CheckSpellingAsYouType = oldSpell Application.Options.UpdateFieldsAtPrint = True ' 5. 落盘日志 WriteLogFile fso, mDstRoot & "_convert_log.txt" MsgBox "处理完毕" & vbCrLf & _ "成功：" & mOkCount & vbCrLf & _ "失败：" & mFailCount & vbCrLf & _ "跳过：" & mSkipCount & vbCrLf & _ "耗时：" & Format$(Timer - startTime, "0.0") & " 秒", vbInformation End Sub

几个参数的选择理由值得说清楚。

Application.DisplayAlerts = wdAlertsNone是为了屏蔽两类弹窗：一类是"文件格式与扩展名不匹配，是否仍要打开"，另一类是"保存时同名文件已存在"。前者如果不去掉，脚本每遇到一个伪装扩展名的文件就停一次；后者如果不去掉，批量跑的时候会一直等你点确认。但这也意味着它会静默覆盖同名目标文件，所以一定要在跑之前确认目标目录是空的，或者你的脚本做了重名避让。

Application.ScreenUpdating = False是纯性能考虑。Word 在界面可见时会为每个文档做重绘，批量场景下这个开销完全可以省掉。

UpdateLinksAtOpen = False之前解释过，主要是为了避免外部链接超时等待。

4.2 递归遍历与路径镜像

递归的写法很朴素，处理当前文件夹里的文件，然后对每个子文件夹递归调用自己。

Private Sub ProcessFolder(ByVal fso As Object, ByVal folder As Object) Dim f As Object Dim subFolder As Object For Each f In folder.Files If LCase$(fso.GetExtensionName(f.Name)) = "doc" Then ConvertOneFile fso, f End If Next f For Each subFolder In folder.SubFolders ProcessFolder fso, subFolder Next subFolder End Sub

注意这里只匹配扩展名为doc的文件，docm、docx、dot、dotx都不在范围内。有人图省事写成Left(ext, 3) = "doc"，结果把已经转好的 .docx 又跑了一遍，白费几个小时。

路径镜像的逻辑是：把源文件的完整路径去掉源根目录前缀，得到相对路径，再拼到目标根目录后面。

Private Function BuildTargetPath(ByVal fso As Object, ByVal srcFile As Object) As String Dim relPath As String Dim relDir As String Dim dstDir As String Dim baseName As String relPath = Mid$(srcFile.Path, Len(mSrcRoot) + 1) relDir = fso.GetParentFolderName(relPath) baseName = fso.GetBaseName(srcFile.Name) If Len(relDir) > 0 Then dstDir = mDstRoot & relDir & "\" Else dstDir = mDstRoot End If If Not fso.FolderExists(dstDir) Then fso.CreateFolder dstDir End If BuildTargetPath = dstDir & baseName End Function

这里有个细节：fso.CreateFolder不能一次创建多级目录。如果源目录里有三层嵌套，直接创建第三层会报"路径不存在"错误。上面的写法之所以能用，是因为递归是从上往下走的，父目录一定先于子目录被创建。这个顺序不能改，改成先遍历文件再建目录就会出问题。

4.3 单个文件的转换与保存格式常量的选择

核心的一步来了，也是最容易出岔子的地方。

Private Sub ConvertOneFile(ByVal fso As Object, ByVal srcFile As Object) Dim doc As Document Dim dstBase As String Dim dstPath As String Dim saveFmt As Long Dim t As Double Dim errMsg As String Dim hint As String t = Timer dstBase = BuildTargetPath(fso, srcFile) On Error GoTo Fail ' 去掉只读属性，避免某些保存路径下的异常 If (srcFile.Attributes And 1) = 1 Then srcFile.Attributes = srcFile.Attributes - 1 End If hint = "以只读方式打开，不做格式确认，不加入最近使用" Set doc = Documents.Open(FileName:=srcFile.Path, _ ConfirmConversions:=False, _ ReadOnly:=True, _ AddToRecentFiles:=False, _ Revert:=False, _ Visible:=False, _ OpenAndRepair:=False, _ Format:=wdOpenFormatAuto) ' 含 VBA 工程的文档，必须存成 docm，否则宏被丢弃 If doc.HasVBProject Then saveFmt = wdFormatXMLDocumentMacroEnabled dstPath = dstBase & ".docm" Else saveFmt = wdFormatXMLDocument dstPath = dstBase & ".docx" End If ' 提升兼容模式，让文档使用新版排版规则 On Error Resume Next doc.CompatibilityMode = wdCompatibilityModeWord2013 On Error GoTo Fail ' 更新一次域，目录页码类内容才会正确 On Error Resume Next doc.Fields.Update On Error GoTo Fail hint = "另存为 " & dstPath doc.SaveAs2 FileName:=dstPath, _ FileFormat:=saveFmt, _ LockComments:=False, _ AddToRecentFiles:=False, _ EmbedTrueTypeFonts:=False, _ SaveNativePictureFormat:=True doc.Close SaveChanges:=wdDoNotSaveChanges Set doc = Nothing mOkCount = mOkCount + 1 mLogLines.Add "OK|" & srcFile.Path & "|" & dstPath & "|" & Format$(Timer - t, "0.00") & "s" Exit Sub Fail: errMsg = Err.Description If Not doc Is Nothing Then On Error Resume Next doc.Close SaveChanges:=wdDoNotSaveChanges Set doc = Nothing End If mFailCount = mFailCount + 1 mLogLines.Add "FAIL|" & srcFile.Path & "|" & hint & "|" & errMsg End Sub

保存格式常量的选择是这段代码里最需要讲清楚的部分。Word 里跟这个问题相关的主要常量有四个：

我默认用wdFormatXMLDocument（12），而不是wdFormatDocumentDefault（16）。原因很实际：12 这个常量从 Word 2007 就存在，跨版本兼容性最好；16 是后来引入的，在极老的版本上可能不识别。虽然现在基本不会再遇到 2003 级环境，但既然效果一样，选稳的那个总没错。

HasVBProject这个判断非常关键。.doc 格式是可以携带 VBA 宏的，如果你把它另存为 .docx，Word 会弹出一个"保存为不支持宏的格式"的警告，在DisplayAlerts = wdAlertsNone状态下，这个警告会被静默吞掉，然后宏就被无声无息地丢掉了。等发现的时候已经无法追溯。所以正确做法是先用属性判断，含宏的直接走 .docm。

提醒：如果原文档里的宏是依赖 .doc 环境的老代码，即使存成 .docm 也未必能跑。转换出来的 .docm 建议单独做一次功能抽测。

4.4 日志写入与进度提示

日志的意义在于事后可追溯。几千个文件跑完，一定有失败的，没有日志就只能全量重跑。

Private Sub WriteLogFile(ByVal fso As Object, ByVal logPath As String) Dim ts As Object Dim i As Long Set ts = fso.CreateTextFile(logPath, True, True) ts.WriteLine "批次开始时间：" & Format$(Now, "yyyy-mm-dd hh:nn:ss") ts.WriteLine "源目录：" & mSrcRoot ts.WriteLine "目标目录：" & mDstRoot ts.WriteLine "成功 " & mOkCount & " / 失败 " & mFailCount & " / 跳过 " & mSkipCount ts.WriteLine String(60, "-") For i = 1 To mLogLines.Count ts.WriteLine mLogLines(i) Next i ts.Close End Sub

日志格式我用管道符分隔，这样可以直接导入表格软件做透视分析。失败行的最后一段是错误描述，正常行是耗时，筛一下就能看出哪些文件特别慢。

如果你要处理的数量特别大，比如上万份，建议加一个轻量的进度提示。最简单的方式是每隔 200 个文件用Application.StatusBar更新一次，这样不会打断处理流程，又能让人知道进度。

5. 核心实现二：命令行与 PowerShell 驱动 Word

宏的问题在于必须有人坐在电脑前点一下。如果要放进自动化流程，或者要在处理过程中和其他脚本串起来，PowerShell 调 COM 对象这条路更合适。

5.1 用 PowerShell 直接驱动 Word 对象

代码不长，但有几个参数传递的细节需要注意。

$srcRoot = "D:\Archive\Legacy" $dstRoot = "D:\Archive\Converted" $word = $null $count = 0 $fail = 0 try { $word = New-Object -ComObject Word.Application $word.Visible = $false $word.DisplayAlerts = 0 $word.Options.UpdateLinksAtOpen = $false $word.Options.CheckSpellingAsYouType = $false $files = Get-ChildItem -Path $srcRoot -Recurse -Filter *.doc -File | Where-Object { $_.Name -notlike "~`$*" -and $_.Length -gt 0 } foreach ($f in $files) { $count++ $rel = $f.FullName.Substring($srcRoot.Length).TrimStart('\') $relDir = [System.IO.Path]::GetDirectoryName($rel) $base = [System.IO.Path]::GetFileNameWithoutExtension($rel) if ($relDir) { $targetDir = Join-Path $dstRoot $relDir } else { $targetDir = $dstRoot } if (-not (Test-Path $targetDir)) { New-Item -ItemType Directory -Path $targetDir -Force | Out-Null } $target = Join-Path $targetDir ($base + ".docx") $doc = $null try { $doc = $word.Documents.Open($f.FullName, $false, $true, $false) $doc.CompatibilityMode = 15 $doc.SaveAs2($target, 12) $doc.Close(0) Write-Host "[OK] $rel" -ForegroundColor Green } catch { $fail++ Write-Host "[FAIL] $rel -> $($_.Exception.Message)" -ForegroundColor Red if ($doc -ne $null) { $doc.Close(0) } } finally { if ($doc -ne $null) { [System.Runtime.InteropServices.Marshal]::ReleaseComObject($doc) | Out-Null } $doc = $null } # 每处理一批就释放一次，防止内存持续上涨 if ($count % 100 -eq 0) { [System.GC]::Collect() [System.GC]::WaitForPendingFinalizers() } } } finally { if ($word -ne $null) { $word.Quit() [System.Runtime.InteropServices.Marshal]::ReleaseComObject($word) | Out-Null } Write-Host "完成：处理 $count，失败 $fail" }

这段脚本里有两个地方我必须单独强调。

$word.Documents.Open的四个参数分别是真实路径、确认转换、只读、加入最近使用。第三个参数设成$true表示只读打开，这是我们想要的——原文件绝对不能改。第四个参数设成$false，避免污染最近文档列表。

ReleaseComObject和GC.Collect是必需品，不是可选项。Word 的 COM 对象在 .NET 里没有及时释放时，会留下大量悬空引用，表现为内存一直涨，几千个文件之后就卡死或者报"远程过程调用失败"。我最初的脚本没写这段，跑到 400 多个文件时必崩，加上之后稳定了很多。

5.2 什么时候必须重启 Word 进程

即便加了资源释放，超大批量处理时还是会遇到 Word 进程状态劣化的问题。典型表现是：处理到某一步后，每次打开文档都变慢，或者开始随机报错。

我的经验阈值是每 500 到 800 个文件重启一次 Word 进程。实现方式不是在外层脚本里反复起停，而是反过来——把批处理脚本做成"接受一个起始索引和数量"的形式，外层用循环调用它。

# 外层分批驱动 $total = 3200 $chunk = 600 for ($i = 0; $i -lt $total; $i += $chunk) { $start = Get-Date & "D:\Scripts\Convert-Chunk.ps1" -Skip $i -Take $chunk Write-Host "第 $([math]::Floor($i/$chunk) + 1) 批完成，耗时 $((Get-Date) - $start)" Start-Sleep -Seconds 3 }

分片的好处还有一个：中途出错只影响当前分片，前面的成果全部保留。用宏一把梭的方式，跑到一半崩了就前功尽弃。

5.3 两种方式的取舍

宏适合"一次性、有人看着、需要精细判断"的场景，写起来直观，调试也方便，VBA 编辑器里能直接单步跑。

PowerShell 适合"周期性、无人值守、需要和其他系统对接"的场景，日志可以直接写进统一收集器，失败可以触发告警，跑完还能自动发邮件。

我自己的习惯是：第一次跑用宏，边跑边看边调；验证没问题之后，把逻辑移植到 PowerShell 做常规任务。这样两头的好处都能吃到。

6. 转换完不算完：质量校验怎么做

大批量转换最怕的不是报错，而是"静默失败"——文件生成了，大小也正常，但内容缺了一块。这种问题只能靠校验发现。

6.1 三层核对：数量、体积、时间

最基础的一层是数量对账。

$src = (Get-ChildItem "D:\Archive\Legacy" -Recurse -Filter *.doc -File | Where-Object { $_.Name -notlike "~`$*" }).Count $dst = (Get-ChildItem "D:\Archive\Converted" -Recurse -File | Where-Object { $_.Extension -in ".docx", ".docm" }).Count "源文件数：$src" "目标文件数：$dst" "差额：$($src - $dst)"

差额如果不是零，就得查日志，看是哪些文件失败或跳过了。

第二层看体积。转换后 .docx 通常比 .doc 小，但不会小得离谱。如果某个目标文件只有几 KB，而源文件有几百 KB，基本可以判定是转换异常。用一条命令把所有目标文件按大小升序排列，前十几个重点看。

Get-ChildItem "D:\Archive\Converted" -Recurse -File | Where-Object { $_.Length -lt 5KB } | Select-Object FullName, Length | Sort-Object Length | Format-Table -AutoSize

第三层对时间。所有目标文件的修改时间应该集中在转换执行的那个时间段里。如果有文件的时间戳是几年前，说明这个文件根本没被处理，可能是从别处拷过来的残留。

6.2 抽样打开与内容比对

数量、体积、时间都过了，还得抽一批实际打开看。

抽样策略我一般按这个来：随机抽 30 份，另外定向抽 10 份最复杂的（体积最大的、页数最多的、含表格和图片最多的）。打开之后检查这几项：首页排版是否错位、页眉页脚是否保留、目录页码是否更新、表格边框是否完整、图片是否还在原位置、批注和修订记录是否可见。

如果要更客观一点，可以做文本层面的比对。思路是用脚本分别从 .doc 和 .docx 里抽出纯文本，去掉空白字符之后做相似度比较。文本相似度低于 95% 的挑出来人工复核。

这个比对有个前提：抽取 .doc 文本需要 Word 或专门的解析库，而抽取 .docx 文本用 python-docx 就够了。所以实际做法是：先用 Word 把 .doc 另存成一份临时 .txt，再用 python-docx 读 .docx 拼出文本，两边做一次编辑距离计算。

import difflib from docx import Document def docx_text(path): d = Document(path) parts = [p.text for p in d.paragraphs] for t in d.tables: for row in t.rows: for cell in row.cells: parts.append(cell.text) return "".join(parts).replace(" ", "").replace("\n", "") def ratio(a, b): return difflib.SequenceMatcher(None, a, b).ratio()

这个脚本写起来十分钟，但能帮你把几千份文件里那几十份有问题的精准捞出来，性价比极高。

6.3 兼容模式残留的专项检查

有一类问题特别隐蔽：文件确实是 .docx 了，扩展名对，格式也对，但在 Word 标题栏里还显示"兼容模式"。

成因是文档的CompatibilityMode属性沿用了源文件的旧值。兼容模式下的排版引擎会按老规则渲染，行距、表格列宽、段前段后的表现都和新版不同。如果你的目标是"统一到新格式"，光改扩展名不改兼容模式，等于只做了一半。

检查方法：打开任意一份文件，看标题栏有没有"[兼容模式]"字样。批量检查可以用脚本读文档的CompatibilityMode属性，值小于 15 的都列出来。

$word = New-Object -ComObject Word.Application $word.Visible = $false Get-ChildItem "D:\Archive\Converted" -Recurse -Filter *.docx | ForEach-Object { $doc = $word.Documents.Open($_.FullName, $false, $true) $mode = $doc.CompatibilityMode $doc.Close(0) if ($mode -lt 15) { [PSCustomObject]@{ File = $_.FullName; Mode = $mode } } }

我的做法是在转换时就设好doc.CompatibilityMode = wdCompatibilityModeWord2013（值 15），从源头上避免这个问题。但要注意，这个操作会导致部分文档的排版发生变化，因为渲染规则变了。所以提升兼容模式的这批文件，必须纳入抽样检查范围。

提示：如果目标只是"能被新版本打开"，不追求统一渲染规则，可以不动兼容模式。如果目标是"视觉上完全统一"，那就必须提升，并且接受一次人工复核的成本。

7. 踩坑实录：那些文档里不会写的问题

这一章是我最想写的部分。前面所有代码你都能在别处找到相似版本，但这些坑只有真跑过才知道。

7.1 高频问题速查表

7.2 几个特别阴的坑

文件名里的特殊字符。含#、%、&的文件名在命令行调用时会被截断或误解析。宏的方式没有这个问题，因为传的是完整路径字符串。但如果你用命令行批处理调用 Word，一定要给路径加双引号，而且路径里不能再有双引号。更稳妥的做法是先把这类文件改名，转完再改回来。

超长路径。完整路径超过 260 个字符时，Documents.Open会直接失败。这个限制在 Windows 上很顽固，即使系统开了长路径支持，Office 组件也未必认。我的做法是先把这类文件临时复制到短路径的临时目录，转完再挪回去，或者干脆改成短名。

隐藏文件和系统文件。遍历目录时如果没过滤属性，会把某些隐藏的临时文件也扫进来。VBA 的folder.Files会包含隐藏文件，PowerShell 的Get-ChildItem默认不含隐藏项。两边行为不一致，跨方案迁移脚本时容易漏。

同名不同扩展名冲突。某个目录里同时存在报告.doc和报告.docx，转换时会生成两个报告.docx。宏的方式会静默覆盖，让你分不清哪个是转出来的。建议在目标目录里加统一的命名后缀，比如全部输出到子目录converted/，或者文件名加_v2标记。

加密文档让整个流程卡住。有打开密码的文档，在DisplayAlerts = wdAlertsNone状态下，Word 不会弹密码框，而是直接抛出一个错误。这个错误如果没被On Error捕获，整个宏就停在那一行。这就是为什么每个文件处理都要独立 try-catch。

Word 进程残留。脚本异常退出时，WINWORD.EXE可能还挂在后台，占着文件锁。下次跑的时候打开同一批文件就会失败。处理办法是跑之前先检查有没有残留进程，或者在任务管理器里手动清一次。

7.3 性能调优的几个实测结论

我做过几组对照，结论比较明确：

关掉ScreenUpdating，整体速度提升约 32%。这是投入产出比最高的一招，一行代码。

关掉拼写检查，速度提升约 8% 到 12%，取决于文档平均长度。

关掉UpdateLinksAtOpen，在有外部链接的文档集上提升巨大，没有链接的文档集几乎无影响。

Documents.Open时加Visible:=False，速度提升不明显（因为ScreenUpdating已经关了），但能减少界面闪烁，观感更好。

OpenAndRepair:=False是必须的。开着这个选项，Word 会尝试修复每个可疑文件，单份耗时可能从 2 秒涨到 20 秒。除非你的文件确实有损坏需要修复，否则一定关掉。

关于SaveAs2的EmbedTrueTypeFonts参数，我建议设成False。嵌入字体会显著增加文件体积，而且很多情况下根本没起作用。只有在排版对字体极度敏感、且目标环境可能缺字体时才需要打开。

8. 一些延伸想法和几个能立刻用上的小技巧

聊完主干，再补几个我在实际处理中总结出来的零碎经验，都是能马上用上的。

先跑 20 个再放开。不管代码写得多有把握，第一次跑一定先限制数量，跑 20 到 30 个，人工打开检查排版、页眉、表格、图片、目录。确认无问题再全量。这个习惯帮我避开了至少三次灾难级的全量返工。

转换前后各做一次文件清单快照。用一条命令把所有文件的路径、大小、时间导成表格存起来，转完再导一次，两相对比，哪些文件没转、哪些变小得异常，一目了然。这份快照本身也是很好的归档凭证。

源目录的最后修改时间要保住。有些人需要保留文件的原始修改时间用于审计。转换后的新文件天然带的是当天时间戳，如果你的场景需要保留，得在转换后用Set-ItemProperty或者文件属性工具把时间改回去，原始时间从快照表里取。

给转换批次起个有意义的目录名。比如Converted_20240615_batch01，而不是new、output、临时。半年后再回来看，一眼就知道这批是什么时候、第几批、用的哪个脚本版本。

把转换参数写进一个配置文件。源目录、目标目录、是否提升兼容模式、是否保留宏、批次上限，这几个参数写进一个文本文件，脚本读取它。这样下次换目录不用改代码，也方便把参数留档。

遇到转换后体积反而变大的文件，单独看一眼。正常情况下 .docx 应该更小。如果某些文件变大，多半是里面嵌了什么特殊对象在转换过程中被展开存储了，这类文件值得抽查一下内容完整性。

批量任务安排在空闲时段。Word 处理几千个文件时会持续占用 CPU 和磁盘 IO，如果同一台机器上还有别人在用，体验会很差。安排在午休或者下班后跑，既不影响别人，也不会因为别人的操作导致文件被占用。

最后分享一个我觉得最实用的判断标准：转换是否成功的唯一标准，是"打开后看起来和原来一样、用起来和原来一样"。扩展名对了不算，数量对上了不算，只有真正打开、翻几页、点几下，才算。任何自动化校验都只是筛选可疑项的工具，最终确认还得靠人眼。我在处理一个包含复杂表格的档案批次时，就是靠抽检发现了三份文件里跨页表格的边框丢失——数量、体积、时间三项全过，只有打开看才发现问题。

这套流程我前后迭代了四五版，从最开始的改扩展名翻车，到后来的一把梭跑崩，再到现在的分片加日志加校验，每一步都是被实际问题推着走的。如果你手头的量不大，比如就几十份，其实手动点几下更快，不必上脚本。真正值得写代码的，是那种"点一整天也点不完、还得保证不出错"的场景。