小村软件有限公司
日本語 English 한국어 繁體中文 简体中文 العربية
联系我们
菜单

什么是 VBA——局限性、未来走向、该替换的场景与现实的迁移方式

· · VBA, Excel, Office, 存量资产利用与迁移, Windows 开发

在关于 VBA 的咨询中，经常会混杂着这样一些问题。

  • VBA 到底是什么
  • 都说宏很危险，是不是不该再用了
  • 今后会不会变得不能用
  • 是不是应该全部转移到 Office Scripts 或 Power Automate
  • 现有的 .xlsm 或 Access 资产该保留还是该舍弃
  • 能不能把 Excel 放到夜间批处理或服务器上运行

这些问题不是靠一个答案就能干净解决的主题。 首先应该看的，与其说是 新还是旧，不如说是 在哪里运行、谁在使用、Excel / Access 本身是不是 UI、是否为无人值守执行。

本文将按照这样的顺序整理：VBA 是什么、局限性在哪里、今后会不会变得不能用、哪些场景该替换、如何现实地分阶段迁移。 另外，本文内容以 截至 2026 年 3 月 可确认的 Microsoft 官方信息为前提。12345

1. 先说结论

先把结论列出来。

  • VBA 是 用于扩展 Office 桌面应用程序的事件驱动语言。它是一种以在 Excel、Word、PowerPoint、Access 等程序内部运行为前提的技术。1
  • 至少截至 2026 年 3 月，作为 Microsoft 的官方信息，尚未能确认有 「VBA 本身将在近期终止」 的明确公告。目前发生的与其说是「突然的全面废止」，不如说是 可用场景与前提条件正在变得清晰 这样的变化。1234
  • 具体来说，Excel for the web 无法创建、运行或编辑 VBA。此外，来自互联网的文件中的宏默认会被阻止运行。23
  • 因此，当下的焦点问题不是「是否要把 VBA 全部舍弃」，而是 哪些领域留在 VBA 中，哪些领域移出去。
  • 特别是，需要 无人值守执行、服务器端执行、多人协同运维、浏览器支持、集中分发、严格审计 的处理，不宜完全交给 VBA 来承担。Microsoft 自身也不推荐也不支持 Office 的服务器端自动化。6
  • 替代方案不止一种。 如果保留 Excel，就把处理逻辑移到 .NET DLL 或独立进程、如果是 Microsoft 365 上的业务流程，就用 Office Scripts + Power Automate、如果需要跨平台扩展，就用 Office Add-ins、如果 Excel 本身已经不再是 UI，就转向 Windows 应用或 Web 应用，这样的划分才是现实的做法。456

总而言之，VBA 不是「即将消亡的技术」，而是「适材适所已经明确的技术」，这样理解才符合实务。

2. 什么是 VBA

VBA 是 Visual Basic for Applications 的缩写，是随 Microsoft Office 附带的一种 Visual Basic。Microsoft 的官方文档也把它描述为 用于扩展 Office 应用程序的事件驱动型编程语言。17

这里重要的是，与把 VBA 看作 通用的应用开发平台 相比，把它看作 嵌入到 Office 应用内部的扩展语言，更贴近实际情况。

以 Excel 为例，VBA 是在与以下这些对象很接近的位置运行的。

  • Workbook
  • Worksheet
  • Range
  • 按钮与表单
  • 打开工作簿、保存工作簿、单元格发生变化时的事件

也就是说，VBA 的优势在于 与 Excel、Access 的界面、报表、工作簿结构非常贴近。 用户在桌面打开 Office，点击按钮，处理本地文件或共享文件夹中的数据，然后直接输出报表——对于这种 「在用户手边就能完成的自动化」，VBA 至今仍具有优势。1

反过来说，VBA 原本的适用范围，从一开始就不是 服务器、浏览器、移动端、多租户 Web 系统。

3. 为什么现在仍然在用

VBA 至今仍留在现场的理由，并不只是「因为老旧才靠惯性留下来」这么简单。

首先，Excel 和 Access 中容易混入的不只是数据，还有 业务流程本身。

  • 报表的外观
  • 打印设置
  • 输入校验
  • 月度处理的顺序
  • 各部门的例外规则
  • 现场长期习惯的操作流程

这些内容迁移到其他系统时，光靠「代码移植」是不够的。 外观、操作、例外、运维 已经融为一体，所以 VBA 资产背后隐含的规格，往往比表面看起来更多。

另外，由于 VBA 与 Office 的对象模型非常接近，在「操作用户眼前的 Excel 本身并返回结果」这类用途上，所需的步骤很少。 这种贴近性在考虑后继方案时也很关键，单纯改写成新技术并不一定就能收尾。

在实务中，比较自然的思路是这样的。

  • 如果 Excel 会继续充当 UI，保留部分 VBA 是有价值的
  • 如果 Excel 只需要负责输入输出，内部逻辑就比较容易移出去
  • 如果 Excel 本身已经不再是真正的 UI，就成为重新构建的候选对象

4. VBA 的主要局限性

4.1 以桌面为前提

最大的局限性就是这一点。 VBA 基本上是一种 在桌面版 Office 内部 运行的技术。

根据 Microsoft 的官方信息，Excel for the web 无法创建、运行或编辑 VBA；虽然可以打开并编辑包含宏的工作簿，但无法运行其中的 VBA。28

这一点决定了它与以下需求的兼容性较差。

  • 希望完全在浏览器中完成
  • 希望在 Mac / iPad / Web 之间使用同一套扩展
  • 希望由管理员集中分发
  • 不想依赖本地的 Excel 桌面应用程序

Microsoft 自身也在 VBA 文档中指出，如果要构建面向多个平台的扩展，应该参考 Office Add-ins。95

4.2 安全性与分发上的摩擦较大

VBA 之所以容易被误解为「已经不能用了」，很大一部分原因其实在于 安全性的强化。

Microsoft 现在默认 阻止运行来自互联网的文件中所含的 VBA 宏。即便打开邮件附件或下载得到的 .xlsm，也不会像过去那样简单地就直接运行了。3

从安全性的角度来说，这是正确的方向。 但从运维的角度来看，会增加这样一些摩擦。

  • 通过附件分发后无法运行
  • 从外部网站下载的模板无法运行
  • 通过 OneDrive / SharePoint / 网络路径的处理方式不易理解
  • 「请启用宏」这类提示，反而成为运维上的薄弱环节

也就是说，VBA 的问题不仅出现在「语言功能」上，也会出现在 分发与信任的设计 上。

4.3 存在 32 位 / 64 位的壁垄

Office 有 32 位版本与 64 位版本，在 Office 2019 与 Microsoft 365 中，默认是 64 位。7

因此，在旧的 VBA 代码中，尤其是 通过 Declare 调用 Windows API 的代码，在 64 位环境下可能无法直接运行。 Microsoft 也建议使用 PtrSafe、LongPtr、LongLong 等来消化 32 位与 64 位之间的差异。7

麻烦的地方在于，不只是代码本身，这类依赖也常常一起变成问题。

  • 旧的 COM / ActiveX / OCX
  • 以 32 位为前提的外部 DLL
  • 以注册表注册为前提的组件
  • Office 引用设置的偏差

也就是说，VBA 的迁移与其说是 语言层面的改写，更多情况下其实是 整理 Office 位数与外部依赖 的过程。

4.4 不适合无人值守 / 服务器端执行

这一点相当重要。 Microsoft 明确表示 不推荐也不支持对 Office 应用程序进行服务器端自动化。Office 的设计前提是交互式的桌面环境与用户配置文件，在无人值守的环境中可能出现不稳定甚至死锁。6

因此，下面这类配置偏向危险。

  • 从 Windows 服务启动 Excel
  • 通过 ASP.NET 或 DCOM 自动化 Office
  • 在任务计划程序中让不可见的 Excel 持续运行
  • 把报表生成完全交给服务器上的 Excel 来处理

「偶尔能跑起来」这种情况是有可能的。 但 能跑起来，和这是一种可持续支撑的架构，是两件不同的事。

如果确实需要无人值守执行，首先应该怀疑的不是 VBA 本身，而是 驱动 Excel 应用程序这件事本身。

4.5 在可维护性、可测试性、差异管理上容易处于劣势

VBA 代码很容易被封闭在工作簿或 Access 文件内部。 其结果是，容易出现这样一些问题。

  • 哪个文件是权威版本变得模糊不清
  • 职责分散在表单、工作表、标准模块之间
  • 引用设置与 ActiveX 依赖在不同环境之间产生偏差
  • 代码审查与差异比对变得困难
  • 难以编写单元测试
  • Excel 的单元格地址本身逐渐变成了规格

这不仅是 VBA 这一语言本身的问题，而是 「把业务逻辑保存在 Office 文件内部」这种结构本身的问题。 在小规模自动化中不会造成大问题，但一旦发展成业务系统，就会突然显现出来。

4.6 若依赖 VBScript，需要另外留意

2025 年，Microsoft 365 Developer Blog 曾公布，Windows 上 VBScript 的分阶段淘汰，也可能影响到 VBA 项目。 尤其是 执行外部 .vbs 的情况，以及 依赖 VBScript.RegExp 引用的情况，会受到影响。10

另一方面，Microsoft 也在推进相应的应对措施，从 Microsoft 365 Version 2508（Build 19127.20154）起，Windows 版 Office 会默认在 VBA 中包含 RegExp 类。10

这里重要的是，VBScript 的淘汰与 VBA 的淘汰并不是同一件事。 更准确的理解不是 VBA 本身即将消失，而是 需要重新审视挂在 VBA 之下的部分外部依赖。

5. VBA 今后会不能用吗

首先，这并不是「明天起就全部不能用了」这样的事。 但同时，也不再是 「无论何处、任何场景都能用」的时代。

至少从 Microsoft 官方信息的解读来看，目前呈现出的是这样的方向。

  • 作为桌面 Office 扩展的 VBA 会继续存在1
  • 在 Web / 跨平台方面，会区分使用 Office Scripts 与 Office Add-ins459
  • 宏分发的安全性会比以前处理得更严格3
  • 像 VBScript 依赖这类周边组件，未来可能会受到影响10

此外，Microsoft 对 Office Scripts 的说明也很明确：VBA 以桌面为中心，Office Scripts 则面向安全、跨平台的云端解决方案。 同时也说明，就桌面客户端可用的 Excel 功能覆盖范围而言，目前 VBA 仍然更广。4

把这两点并列起来看，就会得到相当实用的判断。

  • 在 深度操作桌面 Excel 方面，VBA 的适用范围目前仍然更广
  • 在 浏览器 / M365 / 共享工作流 方面，Office Scripts 或 Add-ins 更为自然
  • 因此，既不是「全部换成 Office Scripts 就好」，也不是「永远把 VBA 放在中心就好」

VBA 的未来，与其说是消亡，不如理解为 边界正在明确化，这样更贴近实际情况。

6. 该替换的场景 / 不需要替换的场景

先给出一张粗略但有用的判断表。

情况 判断的大致标准 理由
用户在自己的 PC 上打开 Excel / Access 使用的小规模自动化 保持原样，或稍加整理 相当符合 VBA 的适用范围
希望 Excel 只保留 UI 与报表，但逻辑已经变得沉重 走向混合架构 VBA 保持轻薄，把繁重的处理移到 .NET 或独立进程，会更易于维护
也希望能在浏览器、Mac、iPad 上使用 不要以 VBA 为中心 VBA 以桌面为前提，而 Office Add-ins 是跨平台的5
希望在 OneDrive / SharePoint 上的工作簿中，通过 M365 工作流来运行 考虑 Office Scripts + Power Automate Office Scripts 面向跨平台 / 云端侧的自动化411
希望在夜间批处理、服务器、服务中无人值守执行 停止对 Excel 进行自动化 Microsoft 不推荐也不支持 Office 的服务器端自动化6
复杂的业务流程、权限管理、审计、数据库集成已成为核心 考虑 应用化 / 系统化 Office 文件内部的逻辑很容易触及极限

这张表里重要的是，判断的依据不是「因为 VBA 老旧」。 真正应该关注的是 执行环境、运维、分发、依赖、审计、可扩展性。

7. 现实的替代方案

7.1 保留 Excel，只把内部逻辑移到 .NET 或独立进程

最现实、最不容易失败的方案就是这一种。

  • 界面与报表的入口仍是 Excel / Access
  • 按钮与输入表单暂时保持不变
  • 但是业务逻辑、HTTP、加密、CSV / JSON、繁重的计算、文件处理都移出去
  • VBA 只承担「桥接」与「UI 操作」

这种架构的优点是 不容易破坏用户的界面与操作方式。 比起全面替换，可以先从 减轻职责 这个方向推进。

相关文章：

「不要一开始就全部重写，先把繁重的部分移出去」，是相当务实的一种思路。

7.2 无人值守执行与报表生成，应转向直接生成文件，而不是自动化 Office 应用

如果想在夜间批处理或服务中批量生成 Excel 报表，首先应该怀疑的不是「VBA 是否老旧」，而是 正在启动 Excel 应用程序这件事本身。

Microsoft 不推荐在服务器端进行 Office Automation。 相反，官方推荐 使用 Open XML 等格式，直接处理 Office 文件。6

也就是说，如果需求是

  • 想生成 .xlsx
  • 想批量输出定型报表
  • 想转换成 PDF
  • 想在夜间批处理中运行

那么应该选择的判断轴不是 是否驱动 Excel，而是 是否直接组装 Excel 文件。

相关文章：

7.3 如果是 Microsoft 365 上的业务流程，选择 Office Scripts + Power Automate

如果业务已经依托于 OneDrive / SharePoint / Teams / Outlook / Forms，Office Scripts 就相当值得考虑。

Microsoft 说明 Office Scripts 面向安全、跨平台的云端解决方案。 再配合 Power Automate，可以用邮件、表单或计划任务作为触发条件来自动化 Excel 处理。411

不过，这也并非万能。

  • Office Scripts 不支持 Excel 级别的事件
  • 执行方式基本是 手动启动 或 由 Power Automate 调用4
  • 与 Power Automate 集成需要 Microsoft 365 商业许可证11
  • Run script 操作存在诸如 每位用户每天 1,600 次、同步处理 120 秒 等限制12

也就是说，与其把 Office Scripts 视为「VBA 的替代品」，更准确的理解是把它看作 M365 上的自动化组件。

7.4 如果需要跨平台扩展，选择 Office Add-ins

如果想在 Windows / Mac / iPad / 浏览器 上扩展 Word、Excel、Outlook 等，Office Add-ins 是首选方案。

Microsoft 的官方文档也说明，Office Add-ins 可以用 HTML / CSS / JavaScript 构建，能在多个平台上运行，也适合集中分发。5

这适合以下这类需求。

  • 希望把 Office 与企业内部门户或核心系统连接起来
  • 希望在 Outlook / Excel / Word 上呈现相同的 UI 与命令
  • 不想按每台 PC 分发宏，而是希望由管理员统一分发
  • 想脱离本地的 .xlsm 分发模式

这与 VBA 处于不同的赛道，因此和 在 Excel 内部写代码 的感觉相当不同。 但作为交换，运维与分发会变得更容易整理。

7.5 如果 Excel / Access 本身已经不再是真正的 UI，就转向 Windows 应用或 Web 应用

如果已经走到这种状态，那么与延长 VBA 的寿命相比，重新构建为应用程序 更为自然。

  • 界面跳转与权限控制已经变得过于繁多
  • 核心已经变成了数据库、审计日志、审批流程、用户管理
  • 存在外部设备联动或长时间运行的处理
  • Excel 的单元格或表单已经代替了业务规格书
  • 关闭工作簿就会丢失状态管理，这件事本身已经变得难以忍受

在这种情况下，如果是以 Windows 为前提的业务工具，用 C# / .NET 桌面应用；如果用户或终端范围较广，用 Web 应用，结构都会更加顺畅。

8. 分阶段迁移的推进方法

替换 VBA 时最危险的是 一开始就想把所有内容都压到某一种新技术上。在实务中，按照下面这样的顺序分阶段推进，基本上更加安全。

8.1 先建立资产清单

首先应该梳理的，不是代码量本身，而是 依赖关系。

  • 有哪些 .xlsm / .xlam / .accdb / .mdb
  • 哪些是实际运维的入口
  • 引用设置中包含了什么
  • 有哪些 Declare、外部 DLL、COM / ActiveX / OCX
  • 32 位 / 64 位的前提是怎样的
  • 哪个宏在被谁、在什么流程中使用
  • 输出物是什么（Excel、CSV、PDF、打印、邮件发送等）

如果在这一步含糊不清就直接替换，之后就会发生「原以为没人用的宏，居然只在月末才会活跃」这类事故。

8.2 按职责拆分代码

接下来要做的，不是按文件拆分，而是按 职责单位 拆分。

  • Excel / Access 的 UI 操作
  • 工作表输入输出
  • 报表布局
  • 业务规则
  • 外部 API / 文件 / 数据库 I/O
  • 批处理
  • 打印 / 分发

经过这样的拆分，哪些该保留、哪些该精简、哪些该移出去，就会变得容易看清。

8.3 按职责分别确定迁移目标

比较推荐的划分方式如下。

  • UI 与工作表操作：暂时保留在 VBA 中
  • 业务逻辑：移到 .NET DLL、独立进程或服务
  • 无人值守的报表生成：转向 Open XML 或直接生成
  • M365 工作流：Office Scripts + Power Automate
  • 跨平台 UI：Office Add-ins
  • 已经系统化的业务领域：拆分到 Windows / Web 应用

重要的是 不要把迁移目标统一到一种。 VBA 资产的内部，通常混杂着多种职责。

8.4 先确定接口

在开始迁移之前，至少应该先确定以下这些内容。

  • 输入是什么
  • 输出是什么
  • 出错时如何返回
  • 以哪些工作表、哪些命名区域、哪些文件路径作为约定
  • 到什么时点，结果才算最终确定

如果不先确定这些，就会导致 单元格地址本身变成 API，从而变得容易损坏。

8.5 通过并行运行进行比较

尤其是报表与汇总处理，最好不要一下子切换。

  • 让旧的 VBA 版本与新实现版本并行输出
  • 比较输出的 .xlsx / CSV / PDF
  • 检查日期、四舍五入、格式、打印范围上的差异
  • 也测试异常情况与空数据情况

VBA 替换过程中的事故，大多不是「能不能运行」的问题，而是 数字或格式悄悄发生偏差 这种形式出现的。

9. 常见的失败

9.1 一开始就想着「VBA 太旧了，全部转到 Office Scripts」

Office Scripts 确实是有力的选项，但 Microsoft 自己也说明 VBA 覆盖的桌面 Excel 功能范围更广。 而且 Office Scripts 不支持 Excel 级别的事件。4

因此，把深度依赖桌面 Excel 的宏原样横向搬移的想法很危险。

9.2 明明是无人值守执行，却一直启动 Excel 本身

这种情况相当常见。 运行期间看起来很方便，但 Microsoft 并不推荐对 Office 进行服务器端自动化。6

对于夜间批处理或服务，与其 驱动 Excel，更安全的做法是转向 直接组装 Excel 文件。

9.3 同时把界面、报表、业务规则全部改掉

VBA 替换中真正可怕的，与其说是代码转换本身，不如说是 业务规格的遗漏。 Excel 工作表或 Access 表单中，隐藏着相当多没有写在代码里的运维规则。

如果一次性全部改动，就容易发生「外观相似，但只在月末才有差异」这类事故。

9.4 把 32 位 / 64 位与外部引用的问题往后拖延

在迁移项目中，往往不是 VBA 代码本身率先爆出问题，而是

  • Declare
  • 外部 DLL
  • COM / ActiveX / OCX
  • Office 位数
  • 引用设置

这些先出问题的情况相当常见。 如果把这些往后放，就会在实施的后期一下子变得非常吃力。7

9.5 把 VBScript 的问题和 VBA 的问题混为一谈

从 VBA 的角度来看，VBScript 的分阶段淘汰只是 部分依赖需要重新审视 的问题。 它并不等同于 VBA 整体的终止。10

如果把两者混在一起，「听说 VBA 要没了」这类粗糙的内部传言，就很容易自行传播开来。

10. 总结

用一句话概括，VBA 是 紧密贴合 Office 桌面应用程序的扩展语言。 在 Excel、Access 身边，用于自动化用户手边的业务，至今仍相当实用。1

不过，今后实务中重要的是，不要把 VBA 当作万能的核心技术来对待。

  • 想要 浏览器 / 跨平台，就去看 Office Scripts 或 Office Add-ins45
  • 需要 无人值守 / 服务器端处理，就避免 Office Automation6
  • 繁重的逻辑与外部集成，移到 .NET 或独立进程
  • Excel / Access 已经难以胜任 UI，就移到 Windows 应用或 Web 应用

答案既不是「全部替换」，也不是「什么都不改」，而是 「按职责拆分，分阶段逐步精简」。

粗略地看，VBA 资产显得陈旧。 但在实务中，其中往往塞满了 业务规格、运维流程、报表设计、现场积累的习惯。

正因为如此，替换应该作为 整理，而不是 翻译，这样推进才最安全。

11. 相关文章

12. 参考资料

  1. Microsoft Learn, Office VBA Reference. “Office Visual Basic for Applications (VBA) is an event-driven programming language that enables you to extend Office applications.” ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  2. Microsoft Support, Work with VBA macros in Excel for the web. Excel for the web 无法创建、运行或编辑 VBA。 ↩ ↩2 ↩3 ↩4

  3. Microsoft Learn, Macros from the internet are blocked by default in Office. 来自互联网的文件中的 VBA 宏默认会被阻止运行。 ↩ ↩2 ↩3 ↩4 ↩5

  4. Microsoft Learn, Differences between Office Scripts and VBA macros. 说明 VBA 以桌面为中心，Office Scripts 面向安全、跨平台的云端解决方案，且目前桌面 Excel 功能的覆盖范围仍以 VBA 更广。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  5. Microsoft Learn, Office Add-ins platform overview. Office Add-ins 基于 HTML / CSS / JavaScript，可跨 Windows、Mac、iPad、浏览器运行，也适合集中分发。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  6. Microsoft Support, Considerations for server-side Automation of Office. Microsoft 不推荐也不支持 Office 的服务器端自动化，并建议采用 Open XML 等替代方案。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  7. Microsoft Learn, 64-bit Visual Basic for Applications overview. Office 2019 / Microsoft 365 默认为 64 位，某些情况下需要用 PtrSafe、LongPtr 等进行适配。 ↩ ↩2 ↩3 ↩4

  8. Microsoft Learn, Office for the web service description. Excel for the web 无法创建或运行 VBA 宏，但可以编辑保留有 VBA 的工作簿。 ↩

  9. Microsoft Learn, Visual Basic for Applications (VBA) 语言参考. 文中指出，如果要为多个平台构建扩展，应参考 Office Add-ins。 ↩ ↩2

  10. Microsoft 365 Developer Blog, Prepare your VBA projects for VBScript deprecation in Windows. 关于 VBScript 分阶段淘汰对执行 .vbs 或依赖 VBScript.RegExp 的 VBA 项目的影响，以及 Office Version 2508 以后对 RegExp 的支持。 ↩ ↩2 ↩3 ↩4

  11. Microsoft Learn, Run Office Scripts with Power Automate. 关于结合 Power Automate 与 Office Scripts 的自动化方式，以及所需的许可证。 ↩ ↩2 ↩3

  12. Microsoft Learn, Platform limits, requirements, and error messages for Office Scripts. 关于与 Power Automate 集成时的调用次数与超时等限制。 ↩

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

VBA 今后会不能用吗？
至少截至 2026 年 3 月，从 Microsoft 的官方信息中，尚未能确认有「VBA 本身将在近期终止」的明确公告。目前发生的变化并不是突然的全面废止，而是可用场景与前提条件正在变得清晰。具体来说，Excel for the web 无法创建、运行或编辑 VBA，来自互联网的文件中的宏默认会被阻止运行。与其说 VBA 的未来是消亡，不如说是边界正在明确化，这样理解更贴近实际情况。
VBA 是否应该全部迁移到 Office Scripts？
不建议这样做。Microsoft 自己也说明，就桌面客户端可用的 Excel 功能覆盖范围而言，目前 VBA 仍然更广，而且 Office Scripts 不支持 Excel 级别的事件。与其把 Office Scripts 当作 VBA 的替代品，更准确的理解是：它是配合 Power Automate、在 OneDrive 或 SharePoint 上的工作簿上运行的 M365 自动化组件。现实的做法是按职责分别选择迁移目标。
可以在服务器或夜间批处理中无人值守地运行 Excel 宏吗？
这样做很危险。Microsoft 明确表示不推荐也不支持在服务器端对 Office 应用程序进行自动化。Office 的设计前提是交互式桌面环境和用户配置文件，在无人值守的环境中可能出现不稳定甚至死锁。如果需求是批量生成报表，官方推荐的做法不是启动 Excel 应用程序，而是用 Open XML 等格式直接组装 Excel 文件。
现有的 VBA 资产该如何迁移？
不要一开始就把所有内容都压到某一种新技术上，分阶段迁移更安全。首先建立资产清单，梳理 .xlsm、引用设置、外部 DLL、32 位/64 位前提等信息，并按 UI 操作、业务逻辑、报表、I/O 等职责拆分代码。在此基础上，UI 与工作表操作暂时保留在 VBA 中，业务逻辑迁移到 .NET DLL 或独立进程，无人值守的报表生成迁移到 Open XML，M365 工作流迁移到 Office Scripts，按职责分别确定迁移目标。报表与汇总类处理应先并行运行，比较新旧输出结果后再切换。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。

联系我们
返回博客列表