xlsx与xlsm格式差异、宏检测、转换及WPS批量修复

经常有朋友甩过来一个文件，说"我这表明明存的是 xlsx，怎么发出去后缀变成 xlsm 了，对方打开还弹宏警告"，或者反过来，自己明明想存成带宏的文件，结果存成了 xlsx，宏全丢了。这个问题看着小，真处理起来坑不少：直接改后缀，Excel 会报"文件格式与扩展名不匹配"；用在线转换工具，公式和格式可能面目全非；文件一多，一个一个另存根本干不完。这篇就把 xlsx 与 xlsm 的格式差异、宏检测的几种可靠方法、单文件转换的三条路线，以及 WPS 环境下批量修复的完整脚本串起来讲清楚。不管你是天天处理报表的运营、做数据交付的分析岗，还是被同事当成"Excel 技术支持"的那个人，看完都能直接上手。

1. 先弄明白：xlsx 和 xlsm 差的到底是什么

1.1 一个后缀，两种"身份"：从文件容器说起

很多人以为 xlsx 和 xlsm 是两种完全不同的文件，其实它俩的底层结构一模一样，都是 ZIP 压缩包，里面装着一堆 XML。你把任意一个 xlsx 或 xlsm 的后缀改成 .zip，解压出来看到的目录结构几乎一致：[Content_Types].xml在根目录，xl/下面有workbook.xml、worksheets/sheet1.xml、styles.xml、sharedStrings.xml这些东西。

真正的差别只有两处。第一处是[Content_Types].xml里对xl/workbook.xml这个部件的类型声明：xlsx 声明成application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml，xlsm 声明成application/vnd.ms-excel.sheet.macroEnabled.main+xml。第二处是 xlsm 里面多了一个xl/vbaProject.bin，这是 VBA 工程编译后的二进制容器，你的所有宏代码、窗体、模块、类模块都在这里面。

打个比方，xlsx 和 xlsm 就像同一个型号的收纳箱，标签贴的不一样，xlsm 那个箱子里多塞了一个装工具的内胆包。Excel 打开文件时，第一眼看的是标签（Content Types），标签写着"启用宏"，它才会去箱子里找内胆包并加载。所以后缀名本身其实只是个提示，真正的"身份"藏在压缩包内部。理解了这一点，后面所有的转换和检测手段就都说得通了。

补充一个容易混淆的点：还有 xlsb（二进制工作簿）和 xltm（启用宏的模板）。xlsb 是把 XML 换成了二进制存储，读写更快、体积更小，但兼容性差一些；xltm 是模板，双击新建文件而不是打开模板本身。这几个格式在另存为对话框里挨得很近，手滑选错是很常见的误操作来源。

1.2 为什么会"莫名其妙"变成 xlsm：五种高频成因

文件后缀自己变了，听起来玄乎，实际上原因就那么几类，我在实际处理中反复遇到的是下面五种。

第一种，文件里确实有宏残留。这种情况最隐蔽：某张表以前被人写过一段宏做自动编号或者打印设置，后来宏不用了，但 VBA 工程没删干净。你在 Excel 里点"另存为"，它检测到工作簿里有 VBA 工程，默认格式会自动跳到 xlsm，很多人没注意就直接点了保存。

第二种，从带宏的模板派生。某些单位的报表模板本身就是 xltm 或者 xlsm，新建文件时继承了宏工程，哪怕你一行代码没写，文件天生就是宏文件。

第三种，复制粘贴的传染。整张工作表从带宏的文件复制到新工作簿，通常不会把宏带过来，但如果你是把整个文件"另存为"新名字再改内容，宏就跟着走了。还有一种情况是用"移动或复制工作表"时勾选了建立副本，源工作簿的某些定义名称和宏引用会被带过去。

第四种，第三方系统导出。一些业务系统、报表工具、打印插件在导出 Excel 时，为了保证打印格式或者自动填表，内部模板带了宏，导出结果自然就是 xlsm。用户拿到手一看后缀，第一反应是"我没写过宏啊"。

第五种，另存为对话框的格式记忆。Excel 和 WPS 都会记住你上一次选择的保存类型，下次另存为时默认还是那个。有人为了存一次带宏的文件选了 xlsm，之后所有文件都默认存成 xlsm，自己完全没意识到。

注意：判断成因不能只看后缀，一定要打开文件确认里面到底有没有vbaProject.bin。有宏的文件和无宏的文件，处理方式完全不同，搞错了要么白忙一场，要么把别人的宏弄丢了。

1.3 直接改后缀行不行：一次实测对比

这是问得最多的问题，答案很明确：改后缀不等于改格式，而且分两种情况。

把 xlsm 的后缀手工改成 .xlsx，双击打开时 Excel 会先对比扩展名和内部声明，发现不一致，弹一个"文件格式与文件扩展名不匹配"的提示。你点"是"，它按内部真实格式（宏启用）打开，宏照样在，只是文件名骗了人；你点"否"，直接报错打不开。也就是说，改后缀既没去掉宏，还可能让接收方以为是普通表格，实际打开时被安全策略拦下来。

反过来，把 xlsx 改成 .xlsm，Excel 能打开，但里面根本没有 VBA 工程，打开后"开发工具"里的宏列表是空的。这种文件发给别人，对方看到 xlsm 后缀会紧张，实际却没有宏，属于纯纯的自我麻烦。

还有一种更糟的情况：某些工具生成的 xlsx 里违规塞了vbaProject.bin，但 Content Types 声明的是普通工作簿。这种畸形文件用 Excel 打开会提示"发现不可读取的内容"，点修复之后宏被剥离，文件能开但内容可能已经受损。

所以结论是，后缀只是给操作系统和用户看的标签，真正的格式转换必须让软件重写内部的 Content Types 声明和部件关系。这一点决定了后面所有正规做法都必须走"另存为"或者"重新打包"这两条路，而不是资源管理器里按 F2。

2. 转换前必做：宏检测与文件体检

2.1 三分钟判断文件里到底有没有宏

动手转换之前，先搞清楚手上这个文件是什么货色。最省事的三招，按从快到慢排。

第一招看标题栏。用 Excel 或 WPS 打开文件，窗口标题栏如果显示"文件名 - Excel 启用宏的工作簿"，那就实锤有宏。如果只显示"文件名 - Excel"，一般是普通工作簿，但这一招不绝对，某些版本对宏文件的标题显示不明显。

第二招看开发工具。打开"开发工具"选项卡，点"宏"，如果弹出的列表里有一堆宏名，说明 VBA 工程存在；列表空白也不代表一定没有，可能只是所有过程都是 Private 的或者放在工作表模块里。更准的是按 Alt+F11 打开 VBA 编辑器，左侧工程资源管理器里能看到 VBAProject 节点，展开后有模块、工作表对象、ThisWorkbook，这才算真正有工程。

第三招，也是最硬的一招：把文件后缀临时改成 .zip，用解压软件打开（不要解压出来，直接在里面看），找xl/vbaProject.bin。有就是有，没有就是没有，一秒钟出结果。同时看一眼[Content_Types].xml，搜索macroEnabled这个关键词，能搜到说明内部声明也是宏工作簿。

这三招各有适用场景：标题栏适合快速扫一眼，开发工具适合确认宏的具体内容，解压看包适合在不确定文件来源、不敢直接打开的情况下做静态检查。我一般建议对来源不明的文件先用第三招，确认干净了再打开，心理上踏实。

2.2 用脚本批量扫描：给一堆文件做体检

文件少的时候手工看没问题，一旦是几十上百个文件，就得靠脚本了。Python 标准库里的 zipfile 就够用，不需要装任何第三方包。

import zipfile from xml.etree import ElementTree as ET NS = '{http://schemas.openxmlformats.org/package/2006/content-types}' def inspect(path): result = { 'file': path, 'ext': path.rsplit('.', 1)[-1].lower(), 'workbook_type': None, 'has_vba_bin': False, 'has_vba_signature': False, 'verdict': '' } try: with zipfile.ZipFile(path) as z: names = set(z.namelist()) ct_xml = z.read('[Content_Types].xml') except (zipfile.BadZipFile, KeyError): result['verdict'] = '不是有效的 OOXML 文件' return result root = ET.fromstring(ct_xml) for ov in root.findall(f'{NS}Override'): if ov.get('PartName') == '/xl/workbook.xml': result['workbook_type'] = ov.get('ContentType') result['has_vba_bin'] = 'xl/vbaProject.bin' in names result['has_vba_signature'] = 'xl/vbaProjectSignature.bin' in names wt = result['workbook_type'] or '' if 'macroEnabled' in wt and result['has_vba_bin']: result['verdict'] = '真宏文件' elif 'macroEnabled' in wt and not result['has_vba_bin']: result['verdict'] = '声明是宏文件但无工程，可能是空壳' elif 'macroEnabled' not in wt and result['has_vba_bin']: result['verdict'] = '畸形文件，扩展名与内容不符' else: result['verdict'] = '普通工作簿' return result

把它套一个os.walk就能递归扫目录：

import os, csv rows = [] for root, _, files in os.walk(r'D:\待处理报表'): for f in files: if f.lower().endswith(('.xlsx', '.xlsm', '.xltm', '.xlsb')): rows.append(inspect(os.path.join(root, f))) with open('scan_result.csv', 'w', newline='', encoding='utf-8-sig') as fp: w = csv.DictWriter(fp, fieldnames=rows[0].keys()) w.writeheader() w.writerows(rows)

跑完得到一个 CSV，哪些是真宏文件、哪些是畸形文件、哪些是普通表格，一目了然。这一步的价值在于，你可以按检测结果分批处理，而不是无差别地把所有文件都转一遍，避免误伤那些本来就有宏、业务上确实需要的文件。

2.3 检测结果怎么读：几种常见状态的处理策略

脚本跑出来的verdict字段有五种取值，每种对应不同的处理动作，我整理成下面这张表，实际用的时候直接对照就行。

特别说一下最后的"非有效 OOXML"。加密的 xlsx 其实是一个 OLE 复合文档，外面套了一层密码壳，用 zipfile 打不开是正常的。这类文件必须先解除密码保护才能转换，脚本里可以捕获BadZipFile之后单独列出来人工处理。还有一种是把 .xls 文件手工改名成 .xlsx，BIFF8 格式根本不是 ZIP，同样会解压失败，这种要按老格式的处理路径走。

提示：批量扫描之前务必先做一份完整备份。脚本虽然是只读的，但后续的转换步骤是写入操作，一旦中途出错，有备份能省掉大量返工时间。

3. 单文件转换：三条路线怎么选

3.1 路线一：Excel/WPS 原生另存法（最稳）

这是最稳妥、兼容性最好的做法，没有之一。操作路径是：打开文件，点"文件 - 另存为"，在保存类型下拉里选"Excel 工作簿 (*.xlsx)"，保存。

关键在于保存过程中软件会做一次检查。Excel 发现工作簿里有 VBA 工程，会弹一个对话框，大意是"以下功能无法保存到无宏工作簿：VB 项目"，给你两个选项：继续保存为 xlsx（宏被剥离），或者返回改成 xlsm。选择继续，宏就被干净地剥离了，同时 Content Types 声明会重写成普通工作簿类型。

这个方法的优势在于，剥离宏这件事是由软件自己完成的，它知道哪些部件该删、哪些关系该断，不会留下悬空的引用。代价是速度慢，一个文件几十秒，上百个文件不现实。

WPS 的流程基本一致，但有个细节要注意：WPS 的另存为对话框里，"Excel 文件(.xlsx)"和"Excel 启用宏的文件(.xlsm)"是分开的两项，而且部分版本会记住上次的选择。保存完一定要回头确认一下后缀，我见过好几次"以为存成 xlsx 了，结果还是 xlsm"的情况，就是下拉框没改。

还有一个容易被忽略的选项：另存为对话框底部的"工具"按钮里，可以设置"常规选项"加密码、"压缩图片"减体积、"Web 选项"。如果原文件图片特别多，转完之后体积没降反升，可以先压缩一次图片再存。

3.2 路线二：脚本化重建（适合格式干净的表）

如果文件只是纯数据表，没有图表、图片、透视表、切片器这些东西，用 Python 的 openpyxl 重建是效率最高的办法。

import openpyxl from openpyxl import load_workbook src = r'D:\报表\月度汇总.xlsm' dst = r'D:\报表\月度汇总.xlsx' wb = load_workbook(src, data_only=False) wb.save(dst)

data_only=False表示保留公式本身而不是公式的计算结果。如果原文件的公式结果没有缓存（比如从没在 Excel 里打开计算过），读出来可能是 None，这时候要反过来用data_only=True取缓存值，但那样就变成静态数值了，公式丢失。这个参数的选择取决于你的目标文件是要继续计算还是要归档。

openpyxl 的坑在于它的能力边界。它不支持保存图表（chart 会丢）、图片（image 会丢）、数据透视表（pivot table 会丢）、ActiveX 控件、切片器、部分条件格式规则、部分数据验证。它支持单元格值、公式、大部分样式、列宽行高、合并单元格、冻结窗格、打印设置、超链接。

所以这条路线的适用判断很清晰：用前面第 2 节的检测脚本看一眼文件，再用 openpyxl 打开遍历一下ws._charts、ws._images，如果是空的，放心用；如果有内容，老老实实走路线一。

wb = load_workbook(src) for ws in wb.worksheets: if ws._charts or ws._images: print(f'{ws.title}: 含图表或图片，不要用 openpyxl 转换')

这个方法的好处是能跑批、能上服务器、能在没有装 Office 的环境里做。缺点是它本质上是"读进来再写出去"，不是真正的格式转换，样式细节会有损耗。字体、边框、填充一般没问题，但一些复杂的条件格式、自定义数字格式的边角情况，可能还原得不完美。

3.3 路线三：压缩包手术法（慎用，但有场景）

这条路是把 xlsm 当 ZIP 拆开，手工删掉宏相关部件，改掉声明，再重新打包。听起来暴力，但在两种场景下确实有用：一是文件大到 Excel 打不开（几万行加一堆格式，内存直接爆），二是需要在 Linux 服务器上处理，根本没有 Office 环境。

具体要改三个地方。第一，删掉xl/vbaProject.bin；如果有xl/vbaProjectSignature.bin（数字签名）也一并删掉。第二，打开[Content_Types].xml，找到PartName="/xl/workbook.xml"那一行，把ContentType的值从application/vnd.ms-excel.sheet.macroEnabled.main+xml改成application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml。第三，打开xl/_rels/workbook.xml.rels，删掉Type属性里带vbaProject的那条 Relationship。

import zipfile, shutil, re def strip_macro(src, dst): shutil.copy(src, dst + '.bak') with zipfile.ZipFile(src) as zin: names = zin.namelist() with zipfile.ZipFile(dst, 'w', zipfile.ZIP_DEFLATED) as zout: for item in names: if item in ('xl/vbaProject.bin', 'xl/vbaProjectSignature.bin'): continue data = zin.read(item) if item == '[Content_Types].xml': data = data.replace( b'application/vnd.ms-excel.sheet.macroEnabled.main+xml', b'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml' ) if item == 'xl/_rels/workbook.xml.rels': text = data.decode('utf-8') text = re.sub( r'<Relationship[^>]*vbaProject[^>]*/>', '', text ) data = text.encode('utf-8') zout.writestr(item, data)

必须提醒的是，这个方法的失败率不低。ZIP 打包时[Content_Types].xml必须存在且格式正确，某些部件之间有严格的顺序和关系约束，删多删少都会导致 Excel 打开时提示"发现不可读取的内容"。而且它只处理了 vbaProject 这一个部件，如果原文件还有 vbaData.xml、自定义 UI 扩展（customUI）、ActiveX 的xl/activeX/目录，这些和宏相关的部分是否要一起清理，得看具体情况，处理不干净照样报错。

我个人的建议是：这条路只作为抢救手段，不作为日常方案。用它转出来的文件，一定要在 Excel 里完整打开一遍、点一次"另存为"、再保存一次，让软件自己把内部结构重新规范化，才敢正式交付。

4. WPS 环境下的批量修复实操

4.1 批量另存：WPS 自带的批量能力能覆盖多少

先泼一盆冷水：WPS 目前没有原生的"批量另存为其他格式"功能。它的"批量处理"相关入口主要做的是批量打印、批量合并、批量重命名文件名这类操作，格式转换不在其中。

所以实际操作里，WPS 环境下的批量转换只有两条路可走：一条是靠宏脚本在 WPS 内部循环处理，另一条是通过 COM 接口从外部驱动 WPS 表格。两条路的前提都一样——你的 WPS 版本要支持宏。

这里有个现实问题需要说清楚。WPS 对 VBA 的支持分版本：部分版本内置了 VBA 引擎，能直接运行 .bas 里的代码；部分版本需要用 JSA（JavaScript for Applications）写宏；还有一些版本默认不带 VBA，需要在设置里单独安装宏插件。开工之前先确认自己的环境：打开 WPS 表格，看"开发工具"选项卡里"宏"按钮是否可用，点进去能不能新建模块。不能的话，直接走 COM 那条路更省事。

另外要提醒的是，批量处理之前先做两件事：把整个待处理目录复制一份到别处做备份；把目录里那些业务上确实需要保留宏的文件先挑出去。批量脚本是无差别处理的，不挑食。

4.2 用宏批量转换：一段可复用的 VBA 代码

如果 WPS 环境支持 VBA，下面这段代码可以直接用。它的逻辑是弹窗让你选一个文件夹，然后把这个文件夹下所有 .xlsm 文件逐个打开、另存为 .xlsx、关闭。

Sub BatchXlsmToXlsx() Dim fd As FileDialog Dim folderPath As String Dim fileName As String Dim wb As Workbook Dim newPath As String Dim okCount As Long, failCount As Long Set fd = Application.FileDialog(msoFileDialogFolderPicker) fd.Title = "选择包含 xlsm 文件的文件夹" If fd.Show <> -1 Then Exit Sub folderPath = fd.SelectedItems(1) Application.ScreenUpdating = False Application.DisplayAlerts = False Application.EnableEvents = False fileName = Dir(folderPath & "\*.xlsm") Do While fileName <> "" newPath = folderPath & "\" & Left(fileName, Len(fileName) - 5) & ".xlsx" On Error Resume Next Set wb = Workbooks.Open(folderPath & "\" & fileName, UpdateLinks:=0) If Err.Number = 0 Then wb.SaveAs fileName:=newPath, FileFormat:=xlOpenXMLWorkbook If Err.Number = 0 Then okCount = okCount + 1 Else failCount = failCount + 1 End If wb.Close SaveChanges:=False Else failCount = failCount + 1 Err.Clear End If On Error GoTo 0 fileName = Dir Loop Application.EnableEvents = True Application.DisplayAlerts = True Application.ScreenUpdating = True MsgBox "完成。成功 " & okCount & " 个，失败 " & failCount & " 个。" End Sub

几个参数和写法要解释一下。FileFormat:=xlOpenXMLWorkbook对应常量值 51，是 xlsx 的格式代码；如果反过来要把 xlsx 转成 xlsm，用的是xlOpenXMLWorkbookMacroEnabled，值 52。UpdateLinks:=0表示打开时不更新外部链接，避免因为链接失效卡住或者弹一堆提示。Application.DisplayAlerts = False是关键，它会自动跳过"是否保留宏"的确认框，默认选择不带宏保存。

Dir函数的用法也有讲究：第一次带路径和通配符调用，之后不带参数连续调用，直到返回空字符串。这个循环里绝对不能在里面再嵌套另一个Dir调用，否则遍历会乱掉。失败的技术原因通常是文件被占用（有人正开着）、文件加密、文件损坏，这几种在On Error Resume Next之后靠Err.Number计数，不影响后续文件继续处理。

如果环境支持的是 JSA 而不是 VBA，逻辑一样，语法要换。核心 API 是Application.Workbooks.Open和wb.SaveAs(path, 51)，循环遍历目录用Dir或者 JSA 的文件系统对象。JSA 的报错处理和 VBA 略有差异，用 try-catch 包住单个文件的处理，别让一个失败中断整批。

4.3 从外部驱动 WPS 表格：COM 脚本方案

如果 WPS 没装 VBA，或者你更习惯用 Python 管流程，走 COM 接口是最灵活的。WPS 表格注册的 COM ProgID 是KET.Application，注意不是Excel.Application——虽然后者有时候也能用（取决于安装时的关联设置），但显式指定KET.Application更稳。

import os import win32com.client as win32 SRC_DIR = r'D:\待处理报表' XL_XLSX = 51 app = win32.Dispatch('KET.Application') app.Visible = False app.DisplayAlerts = False ok, fail = 0, 0 for name in os.listdir(SRC_DIR): if not name.lower().endswith('.xlsm'): continue src = os.path.join(SRC_DIR, name) dst = os.path.join(SRC_DIR, os.path.splitext(name)[0] + '.xlsx') if os.path.exists(dst): print(f'跳过已存在：{dst}') continue try: wb = app.Workbooks.Open(src, UpdateLinks=0, ReadOnly=True) wb.SaveAs(dst, XL_XLSX) wb.Close(False) ok += 1 print(f'成功：{name}') except Exception as e: fail += 1 print(f'失败：{name} -> {e}') app.Quit() print(f'处理完毕，成功 {ok}，失败 {fail}')

这段代码里有几个细节值得说。ReadOnly=True打开源文件，是为了避免多个进程同时占用同一个文件；SaveAs不受只读影响，它写的是新路径。os.path.exists(dst)那个判断是给中断重跑准备的——批量处理最怕跑到一半崩了，重跑时把已经转好的再转一遍，浪费时间还可能覆盖。加上这个判断，脚本可以反复执行直到全部完成。

app.Quit()一定要放在 finally 块里或者确保能执行到，否则后台会残留一堆看不见的进程，下次再跑就报"无法创建对象"。更稳妥的写法是用 try-finally：

app = win32.Dispatch('KET.Application') try: app.Visible = False app.DisplayAlerts = False # ... 循环处理 ... finally: app.Quit()

如果处理过程中某个文件触发了弹窗（比如加密文件要求输密码），DisplayAlerts=False压不住这种模态框，脚本会卡死在那里。所以我一般会在跑批之前，先用第 2 节的检测脚本把加密文件和损坏文件筛掉，只把干净的文件交给 COM 处理。

4.4 转换后的验收清单：别只看后缀对不对

批量跑完，后缀全变成 .xlsx 了，这事儿只能算完成了一半。真正的验收要做内容比对，我一般按下面这个清单走一遍。

第一步，数量核对。源目录的 .xlsm 文件数，和目标目录的 .xlsx 文件数应该完全一致，少了的说明有失败被吞掉了，回去看日志。

第二步，工作表结构比对。用 openpyxl 分别打开源文件和目标文件，比较工作表名称列表、每张表的max_row和max_column。这一步能抓出大部分结构性问题：

from openpyxl import load_workbook def snapshot(path): wb = load_workbook(path, data_only=False) info = {} for ws in wb.worksheets: formulas = 0 for row in ws.iter_rows(): for c in row: if isinstance(c.value, str) and c.value.startswith('='): formulas += 1 info[ws.title] = (ws.max_row, ws.max_column, formulas) return info a = snapshot(r'D:\待处理报表\月度汇总.xlsm') b = snapshot(r'D:\待处理报表\月度汇总.xlsx') for k in a: if a[k] != b.get(k): print(f'差异：{k} 源={a[k]} 目标={b.get(k)}')

max_row和max_column不一致，通常是空行空列被裁掉了，或者合并单元格的处理有差异；公式数量不一致，可能是某些公式被转成了静态值。

第三步，肉眼抽查。挑几个关键文件打开，重点看图表还在不在、数据透视表要不要刷新、条件格式的红绿标记还对不对、下拉列表还能不能选。这一步没法完全自动化，但抽样比例不用太高，十个里看一两个就够发现问题。

第四步，打开无报错。所有转换后的文件快速双击一遍，确认没有"发现不可读取的内容"的修复提示。有提示的，说明转换过程有部件损坏，需要从备份重新走一遍原生另存法。

注意：验收阶段不要在原目录直接操作，用一份副本打开检查。有些问题（比如打开时自动重算公式）会改变文件内容，在原文件上检查容易污染结果。

5. 踩坑记录：转换中最容易丢的东西

5.1 图表、条件格式与数据验证的丢失

用 openpyxl 转换最容易出事的就是这三样。图表全丢是最常见的，因为它压根不在 openpyxl 的写入支持范围内，读的时候ws._charts有内容，存的时候直接忽略，文件打开后图表位置空空如也。图片同理，ws._images里的东西一个都保不住。

条件格式的情况更微妙。简单的单元格高亮、色阶、数据条一般能保留，但基于公式的复杂规则、跨工作表的引用规则，openpyxl 保存后可能失效或者变成了静态填充色。数据验证（下拉列表）大部分能保留，但如果下拉选项来源是一个定义名称或者另一张表的区域，转换后可能变成空列表，点了没反应。

还有一个不太被注意的是打印区域和分页符。这个问题在报表交付场景里影响很大：本来设置好了一页打印完，转换后变成两页，多出来的那一页只有一行。原因通常是列宽被轻微改变，导致原本刚好塞下的内容溢出了。WPS 和 Excel 对列宽的换算系数略有差异（一个是字符宽度，一个是像素），跨软件转换时这点差异会被放大。

我的应对办法是：对有图表和复杂格式的文件，坚决不用脚本重建，一律走原生另存。转换完成之后，专门打开"页面布局 - 打印预览"看一眼分页，有问题的重新拖一下分页符。这一步花不了多少时间，但能避免交付后被退回来。

5.2 外部链接、定义名称与公式兼容

外部链接的处理是个隐蔽的雷。原文件如果引用了另一个工作簿的数据（比如=[预算表.xlsx]Sheet1!$A$1），转换时那个被引用的文件正好没打开，Excel 会弹窗问"是否更新链接"，选不更新的话，依赖这些链接的公式会显示上一次的缓存值；选更新但源文件路径变了，公式会变成#REF!。

批量转换时这个问题尤其麻烦，因为脚本里设了UpdateLinks:=0，所有链接都不更新，公式值停留在旧数据上。如果这份表要拿去汇报，数字就是错的。处理办法是在跑批之前，把所有被引用的源文件放到同一个目录下，跑批时用UpdateLinks:=3（表示总是更新），让 Excel 自己去找。

定义名称（Name Manager 里的那些）也容易出问题。跨工作簿引用的名称、带 OFFSET/INDIRECT 的动态名称，在 xlsm 转 xlsx 后可能报错或者失效。转换后建议打开"公式 - 名称管理器"扫一眼，有#REF!的逐条修。

公式兼容性方面，xlsm 支持的函数和 xlsx 完全一样（格式不影响函数），所以不存在"转格式导致函数不支持"的问题。真正的风险来自版本差异：用了新版本才有的函数（比如 XLOOKUP、FILTER、LET），在老版本 Excel 或者旧版 WPS 里打开会显示#NAME?。这跟格式转换无关，但用户往往会把两件事混在一起归因，排查的时候要分清楚。

5.3 文件体积异常与打开报错的应对

转完之后体积不减反增，是另一个高频困惑。正常情况下去掉vbaProject.bin应该变小，变大了通常是两个原因。

一是样式冗余。原文件在长期编辑过程中积累了大量没用的单元格样式（打开"单元格样式"能看到一堆"样式 1""样式 2"），转换时这些样式被完整保留甚至重复写入，体积就上去了。处理办法是用 Excel 打开，另存为时选"工具 - 压缩图片"，或者用专门的清理工具删掉未使用的样式。

二是残留的打印区域和空白格式。如果一张表曾经有十万行数据，后来删到只剩一千行，但格式还附着在原来的区域上，文件体积会虚高。选中下方所有空行整行删除、右侧空列整列删除，再保存，体积往往能降一半。

打开报错的情况分几种。"发现不可读取的内容，是否恢复"一般意味着某个 XML 部件格式不合法，多半是压缩包手术法留下的后遗症，或者 openpyxl 写入时遇到了它不认识的扩展。"文件已损坏，无法打开"更严重，可能是 ZIP 打包时用了不支持的压缩算法（比如某些工具默认用 ZIP64）。"文件格式与扩展名不匹配"则是 Content Types 没改干净。

遇到报错不要慌，先看提示里说的具体是哪个部件出错，Excel 的修复日志会写在xl/repairLog.xml里。实在打不开的，用 LibreOffice 或者 WPS 试着打开另存一次，这两个的容错能力有时候比 Excel 强，能把结构重新规范化。

6. 常见问题速查表

下面这张表是我在实际处理中反复遇到的场景，按现象归类，遇到问题可以直接对照着找方向。

表里最后一条值得单独说。用 VBA 写批量脚本时，On Error Resume Next用起来很爽，但它是双刃剑——它会把所有错误都静默跳过，包括那些你其实想知道原因的。我的习惯是在On Error Resume Next之后立刻检查Err.Number，把失败的文件名和错误号写进一个文本文件或者另一张工作表，跑完再回头分析。

If Err.Number <> 0 Then Open folderPath & "\convert_error.log" For Append As #1 Print #1, fileName & " | " & Err.Number & " | " & Err.Description Close #1 Err.Clear End If

这段小代码加进去，批量处理就从"黑盒"变成了"有账可查"，出了问题不用靠猜。

还有一个经验是，批量转换一定要分批次做，别一次性丢几百个文件进去。我的做法是先拿五个文件试跑，确认输出没问题、验收通过，再放开全量。中间每隔几十个文件让脚本DoEvents一下或者短暂 sleep，让系统有机会处理其他消息，能显著降低卡死的概率。

我个人在实际操作中的体会是，格式转换这件事，能用软件自带功能解决的，就别用脚本；能用脚本批量处理的，就别手工一个个点。判断标准很简单：文件里有图表、透视表、控件这些"重"内容，老老实实走另存为；文件是纯数据表，脚本一把梭。最忌讳的是图省事去改后缀，或者图快用在线转换网站——前者等于没转，后者把公司的报表数据传到了别人的服务器上，风险不是一点半点。至于 WPS 和 Excel 之间的互转，我的建议是尽量在同一个软件里完成闭环，跨软件转换虽然大多数时候没问题，但列宽、字体、分页这些细节的偏差是实实在在的，尤其是要打印交付的表格，转换完一定要看一眼打印预览。