小村軟體有限公司
日本語 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 32bit / 64bit 的門檻

Office 有 32bit 與 64bit 兩種，Office 2019 與 Microsoft 365 預設為 64bit。7

因此舊的 VBA 程式，尤其是 用 Declare 呼叫 Windows API 的程式，在 64bit 環境下往往無法直接跑。 Microsoft 也指出要透過 PtrSafe、LongPtr、LongLong 等吸收 32bit / 64bit 差異。7

棘手的是，不只程式碼，下列相依也會一起出問題：

  • 老的 COM / ActiveX / OCX
  • 以 32bit 為前提的外部 DLL
  • 需要登錄檔註冊的元件
  • Office 的參考設定偏差

所以 VBA 的遷移常常不是 語言改寫，而是 Office bitness 與外部相依的清查。

4.4 不適合無人執行／伺服器執行

這一段相當重要。 Microsoft 明言 不建議也不支援 Office 應用的伺服器端自動化。Office 是以互動桌面與使用者設定檔為前提設計，無人環境下可能不穩或死鎖。6

所以下列組合偏危險：

  • 從 Windows 服務啟動 Excel
  • 從 ASP.NET 或 DCOM 自動化 Office
  • 在工作排程器上跑看不到的 Excel
  • 把報表產生全部丟給伺服器上的 Excel

「偶爾能跑」可能存在。 但 「能跑」與「架構可被支援」是兩回事。

真正需要無人執行時，先該質疑的不是 VBA，而是 把 Excel 本身當成引擎在驅動 這件事。

4.5 可維護性、可測試性、差異管理不利

VBA 容易把程式碼封在活頁簿或 Access 檔裡。 這會造成：

  • 不清楚哪個檔才是正本
  • 表單、工作表、標準模組的職責分散
  • 參考設定或 ActiveX 相依因環境而異
  • 難做 code review、難做差異比對
  • 難寫單元測試
  • Excel 的儲存格位址變成規格

這不是語言本身的問題，是 「把業務邏輯放進 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 中，把 RegExp 類別預設納入 VBA 作為對策。10

重點是：VBScript 淘汰≠VBA 終止。 實際上是 需要整理 VBA 下游那些外部相依，而不是 VBA 本身要消失。

5. VBA 以後會不會不能用

結論：並不是「明天全部都不能用」，但也 「不再是想放哪就放哪」的時代。

從 Microsoft 官方資訊能明顯看出的方向是：

  • 桌面 Office 擴充意義上的 VBA 會繼續存在1
  • Web / 跨平台那端，改走 Office Scripts 或 Office Add-ins459
  • 巨集派送的安全性比以往更嚴格3
  • VBScript 這類周邊元件會受未來政策影響10

關於 Office Scripts，Microsoft 也明確說：VBA 以桌面為中心，Office Scripts 則是安全、跨平台、面向雲端的方案； 並同時指出 目前在桌面用戶端的 Excel 功能覆蓋面上，VBA 仍比較廣。4

把這兩句擺在一起，實務觀感很清楚：

  • 桌面 Excel 的深度操作，仍是 VBA 強項
  • 瀏覽器 / M365 / 共享工作流，偏 Office Scripts 或 Add-ins
  • 所以 「全部換成 Office Scripts」與「永遠把 VBA 放在中心」都不對

總之，VBA 的未來更像是 「邊界被講清楚」，而不是消失。

6. 該取代 / 不必取代 的判斷

先放一張粗但實用的判斷表。

情境 判斷基準 理由
使用者自己電腦開 Excel / Access 用的小規模自動化 直接保留，或做點整理 完全對應 VBA 的強項
Excel 只想留 UI 與報表，但邏輯變重 做成混合型 VBA 留薄殼，重的往 .NET 或獨立行程外移比較好維護
希望瀏覽器、Mac、iPad 也能用 VBA 不要當主角 VBA 以桌面為前提，Office Add-ins 才是跨平台5
想以 M365 工作流處理 OneDrive／SharePoint 上的活頁簿 考慮 Office Scripts + Power Automate Office Scripts 是跨平台／雲端自動化導向411
要夜間批次、伺服器、服務上無人執行 別自動化 Excel Microsoft 不建議也不支援 Office 的伺服器端自動化6
已經有複雜業務流程、權限、稽核、DB 整合 考慮產品化／系統化 Office 檔內邏輯容易達到上限

這張表的重點是：判斷依據不是「VBA 太舊」。 真正要看的是 執行環境、運維、派送、相依、稽核、擴充性。

7. 務實的替代目標

7.1 留下 Excel，只把內部搬到 .NET 或另一個行程

最務實、失敗率最低的做法。

  • 畫面與報表入口仍用 Excel / Access
  • 按鈕、輸入表單也暫時保留
  • 但業務邏輯、HTTP、加解密、CSV/JSON、重計算、檔案處理都外移
  • VBA 只留「橋接」與「UI 操作」

優勢是 不容易打亂使用者的外觀與操作。 比起一次全改，不如先從 減輕 VBA 職責 做起。

相關文章：

「重寫之前先把重的部分移走」是實務上很好的切入。

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 或命令
  • 以系統管理員方式派送，而非每個使用者各自配巨集
  • 脫離「本機 .xlsm」的派送模式

它跟 VBA 的做法並不同，所以 「在 Excel 裡寫程式」的感覺會改變。 換來的是運維與派送更好整理。

7.5 若 Excel / Access 已不再是本來的 UI，改寫成 Windows 應用或 Web 應用

若出現下列狀況，延命 VBA 比不上 做成應用：

  • 頁面切換、權限控管膨脹
  • 重心變成 DB、稽核日誌、簽核流程、使用者管理
  • 有外部設備整合或長時間處理
  • Excel 的儲存格或表單竟成了業務規格書
  • 關閉活頁簿就失去狀態，本身就很痛苦

此時要是 Windows 工具就選 C# / .NET 桌面應用；面向廣泛使用者或終端多樣，就選 Web 應用，結構會更自然。

8. 階段性遷移的做法

VBA 取代最危險的做法，是 一開始就把全部往單一新技術上搬。 實務上，建議下列順序：

8.1 先做資產盤點

一開始要列的，是 相依關係，而不是程式碼量：

  • 有哪些 .xlsm / .xlam / .accdb / .mdb
  • 哪些是實際運維入口
  • 參考設定中有什麼
  • 用到哪些 Declare、外部 DLL、COM / ActiveX / OCX
  • 32bit / 64bit 的前提
  • 哪個巨集被誰、在什麼流程下使用
  • 產出是什麼（Excel、CSV、PDF、列印、寄信 等）

不釐清就動手，很容易遇到「以為沒人碰的巨集，其實每月月底都在跑」這類事故。

8.2 按職責拆分程式碼

接著按 職責 而不是檔案拆：

  • Excel / Access 的 UI 操作
  • 表單的輸入輸出
  • 報表版型
  • 業務規則
  • 外部 API / 檔案 / DB 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 畫面、報表、業務規則一次全改

真正可怕的不是程式碼轉寫，而是 規格的遺漏。 Excel 的工作表、Access 的表單裡，埋了很多沒寫進程式的運維規則。

一次全改，就會出現「看起來很像，但每月月底不一樣」這類狀況。

9.4 32bit / 64bit 與外部參考拖到最後

遷移專案中，常常是

  • Declare
  • 外部 DLL
  • COM / ActiveX / OCX
  • Office bitness
  • 參考設定

這些先爆。 留到最後處理，尾段會突然很痛苦。7

9.5 把 VBScript 的話和 VBA 的話混在一起

VBScript 的逐步淘汰對 VBA 而言，是 清理部分相依， 不等於 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 預設為 64bit，部分程式碼需以 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) language reference. 若要做跨平台擴充，指引是查看 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 整合的自動化與所需授權。 ↩ ↩2 ↩3

  12. Microsoft Learn, Platform limits, requirements, and error messages for Office Scripts. Power Automate 整合的呼叫次數與逾時限制。 ↩

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽