小村軟體有限公司
聯絡我們
選單

Windows 應用程式該不該 Web 化 ── 判斷表與「拆分」這個現實解方

· · Windows開發, Web遷移, 現代化改造, 業務應用, 判斷表, 設計, 技術諮詢

「公司內部使用的 Windows 應用程式，差不多該 Web 化了」──這樣的諮詢一年比一年多。雖然動機通常合情合理，但深入了解之後，經常會發現對方正打算把一個 Web 化之後反而更難用、更花錢的應用程式，做全面 Web 化。

先聲明一下，這篇文章並不是要說「不要 Web 化」。多據點使用、減少終端管理負擔等情境下，Web 化明顯是正確答案的情況其實很多。問題在於把不適合 Web 化性質的應用程式，也一律套用「現代化＝Web 化」這個公式。本文整理我們在 Windows 委外開發現場實際用來判斷「不適合 Web 化」情況的方法，以及不把選擇侷限在全面 Web 化或全面維持 Windows 這兩個極端、而是採取拆分架構這個現實解方。

1. 先講結論(判斷表)

重點是不要以應用程式整體來判斷，而是依應用程式擁有的每個功能、每種性質分別判斷。

應用程式的性質 與 Web 化的契合度 理由
多據點、公司外部需要檢視相同資料 ◎ 適合 只要有瀏覽器就能使用，不需要在終端安裝
以檢視、搜尋、彙總、報表為主 ◎ 適合 瀏覽器的標準功能就足以實現，是 Web UI 的強項
終端設備更換、增減頻繁 ○ 適合 不需要用戶端發布，減少建置作業
直接與序列埠、USB 設備、量測儀器、生產設備通訊 × 不適合 瀏覽器的沙盒機制會限制對本機資源的存取1
監控本機檔案、批次處理，或與其他應用程式(Excel 等)進行行程間連動 × 不適合 瀏覽器無法自由存取檔案、啟動其他行程
用於網路不穩定、不容中斷的現場業務 × 不適合 Web 應用程式在離線狀態下功能會受到大幅限制2
以鍵盤為主的高速、大量輸入是業務核心 △ 需留意 每次操作的回應延遲、重現桌面級表格元件的成本容易成為問題
除了「技術老舊」以外沒有其他 Web 化動機 △ 需留意 Web 化是接近重新開發的投資。如果動機只是技術新舊，應與維持 Windows 應用程式型態的現代化方案做比較

先講結論。

  • 「想 Web 化」的需求背後，通常混雜著三個不同的問題。 發布的麻煩、使用地點的限制、技術的過時。三者的解決方案各不相同，其中只有一部分是非 Web 化不可解決的(第 2 章)。
  • 有設備連動、本機檔案處理、離線運作需求的應用程式，這些部分不 Web 化會比較安全。 瀏覽器基於安全考量刻意限制對本機資源的存取，這不是 Web 的缺陷，而是設計理念本身1。雖然有變通方法，但會帶來另一種成本，例如受支援瀏覽器的限制、營運複雜化(第 3～5 章)。
  • Web 化不是「移植」，而是「重新開發」。 既有的畫面資產無法直接沿用，完成後還會新增伺服器維運這項持續性成本。若估算前提沒有建立在這一點上，計畫中途就會崩潰(第 7 章)。
  • 現實解方是拆分。 把檢視、彙總、報表搬到 Web，設備連動、現場輸入維持在 Windows，兩者透過共用的 API 與資料庫連接。相較全面 Web 化能以更小規模起步，也能從效益最大的部分依序推進(第 8 章)。

2. 拆解「想 Web 化」的真正內容

接到 Web 化的諮詢時，我們最先做的是拆解需求。「想 Web 化」這句話背後，通常隱藏著以下三者之一(或多者並存)。

(1) 想省去發布、更新的麻煩。「每次升級版本都要跑遍所有終端安裝」是常見的困擾。Web 化的確能解決這個問題，但不 Web 化也能解決。只要改用 ClickOnce 或 MSIX 這類具備自動更新機制的發布方式，即使維持 Windows 應用程式的型態，也幾乎能把發布作業歸零。詳情請參考「Windows 應用發布方式怎麼選」。如果動機只是發布的麻煩，Web 化就是過度投資。

(2) 想在任何地方、任何終端都能使用。 多據點使用、外出洽談或在家中存取、平板上檢視──這正是 Web 化真正發揮價值的地方。不過即使在這種情況下，也要分清楚是「想在任何地方使用全部功能」，還是「只是想在任何地方檢視資料」。實務上後者的情況居多，此時只把檢視、彙總部分搬上 Web 的拆分架構(第 8 章)就已足夠。

(3) 想擺脫老舊技術。「開發者已離職」「還在用 .NET Framework 讓人不安」是常見的動機。這是正當的問題意識，但解決方案未必是 Web 化。既然都要重新開發，若業務性質適合桌面，也可以選擇用最新版 .NET 重新開發成 Windows 應用程式(WinForms、WPF、WinUI 該選哪個 - 判斷表)。此外，也必須認清改用 Web 並不代表就能擺脫技術過時的問題。以 IE 專用方式打造的公司內部 Web 系統，在 IE 終止支援後失去去處的案例仍記憶猶新(「擺脫 IE 模式依賴系統的實務指南」)。Web 應用程式同樣需要跟隨框架與瀏覽器變化進行維護，「Web 化＝從維護中解放」並不成立。

經過這樣的拆解，就能看清哪些問題「只有 Web 化才能解決」、哪些「Web 化以外的方式也能解決」、哪些「即使 Web 化也解決不了」。接著再確認應用程式是否有符合以下「不適合 Web 化」的功能。

3. 情況一：與設備、周邊裝置直接相連

與生產設備通訊、從量測儀器或檢驗機擷取資料、透過序列埠(RS-232C)連接的秤重機或條碼掃描器、特殊印表機的精細控制──擁有直接與硬體對話功能的應用程式，就結構而言不適合把這部分 Web 化。

理由很單純：瀏覽器上執行的程式碼運作於一個叫做沙盒(sandbox)的隔離環境中。如果單純打開一個網頁就能任意操作終端內的檔案或設備，那會是很大的問題，因此瀏覽器刻意阻擋了對本機資源的存取。這並非 Web 的缺陷，而是安全性設計本身。舉例來說，即使是能用 C# 撰寫 Web 用戶端的 Blazor WebAssembly，其程式碼也在瀏覽器的安全沙盒內執行，存取檔案系統或開啟任意網路連線都會擲出 PlatformNotSupportedException1。能做的事僅限於瀏覽器本身支援的範圍內2。

也許有人會反駁「用 Web Serial API 或 WebUSB，瀏覽器不是也能做序列通訊嗎」。這確實存在，但支援的瀏覽器有限。Web Serial API 除了 Chrome、Edge 等 Chromium 系瀏覽器外，2026 年 5 月發布的 Firefox 151 也讓桌面版 Firefox 開始支援，但Safari 仍未支援(行動裝置方面，Android 版 Chrome 也僅部分支援透過藍牙的序列通訊)，而 WebUSB 至今仍僅限 Chromium 系瀏覽器3。這等於是在 Web 化最大的優勢「不挑瀏覽器都能用」上加了限制，而且連接設備時(至少初次使用或每次新增設備時)使用者都必須透過瀏覽器的對話框選擇並授權設備，作為業務系統的設備連動手段，實務上往往划不來。

另外，也有人會用「Web 應用程式＋在每台終端常駐一個連動代理程式(agent)」的架構來變通，但這其實是一種結果上仍需要發布、更新的 Windows 程式留存下來的做法。這本身並非壞事，反而可以視為第 8 章拆分架構的一種形式，但必須在規劃階段就先說清楚，這和「Web 化之後終端就什麼都不用裝了」的原始期待並不相同。

設備連動部分的設計也請參考「外部設備狀態檢查與顯示的最佳實務」。

4. 情況二：與本機檔案、其他應用程式深度連動

其次常見的是終端內的檔案或與其他應用程式的連動構成業務核心的情況。

  • 監控共用資料夾或本機資料夾，自動處理放入其中的檔案
  • 對數百、數千個檔案進行批次轉換、重新命名、分類
  • 啟動 Excel、透過 COM 組裝報表，或與既有的 Excel 巨集連動
  • 透過檔案或行程間通訊，與其他業務應用程式交換資料

瀏覽器存取檔案的原則是僅限於「使用者每次透過對話框選取的檔案」。無法在沒有使用者操作的情況下進行批次存取，也無法做到即使關閉瀏覽器仍持續運作的常駐式監控。近年出現的 File System Access API 可以存取使用者選取的整個資料夾，甚至有一個仍屬實驗性質的 API(FileSystemObserver)能在頁面開啟期間監控選取資料夾內的變動，但這些都僅限於 Chromium 系瀏覽器4，同樣有著「綁定特定瀏覽器」的問題，與設備連動如出一轍。至於從瀏覽器啟動並操作 Excel 等本機其他行程，則根本沒有這種手段。

若要把這類功能 Web 化，就需要把業務流程改為「請使用者將檔案上傳，由伺服器端處理」。如果這種方式在業務上行得通，倒也是個選項；但如果有日常處理 GB 級別的大型檔案、資料無法外流因此需在本機完成處理、與 Excel 資產緊密耦合等情況，把這部分維持為 Windows 應用程式(若是資料夾監控、批次處理這類無人值守的作業，則可做成 Windows 服務)，對開發方和使用方來說都會更順理成章。不過與 Excel 的 COM 連動這一點需要特別留意放置的位置。由於 Microsoft 不建議也不支援從服務等無人值守、非互動式環境自動化操作 Office5，因此自動操作 Excel 的處理應放在使用者登入操作的桌面應用程式端，或改用不啟動 Office 的 Open XML 系函式庫進行讀寫。Excel 連動的做法請參考「Excel 報表輸出該怎麼做」，資料夾監控則請參考「FileSystemWatcher 的使用方法與注意事項」。

5. 情況三：用於網路不穩定、不容中斷的現場業務

就結構而言，Web 應用程式以網路連線正常為前提。這不僅適用於伺服器端渲染型的 Web 應用程式，就連 C# 陣營中很受歡迎的 Blazor Server 也是如此──由於所有 UI 操作都透過與伺服器的常時連線處理，一旦連線中斷，應用程式就會停止運作。官方文件明確指出這種架構沒有離線支援2。

以下環境容易出現這類問題。

  • 工廠、倉庫、戶外現場：Wi-Fi 訊號被金屬層架或機械阻擋，瞬斷是家常便飯
  • 不容中斷的產線：記錄或指示畫面只要停擺數分鐘，就會影響生產或出貨
  • 網路細窄、不穩定的據點：仰賴行動網路的臨時辦公室、船上、山區等

原生的 Windows 應用程式可以很自然地做到將資料保存在本機，即使離線也能持續運作，等連線恢復後再同步。離線運作正是 Microsoft 自己提出的選擇原生應用程式的理由之一6。透過 PWA(Service Worker)或讓資料保留在用戶端的設計，技術上也能讓 Web 應用程式支援離線，但連同同步、衝突處理都一併做出來，需要相當程度的額外投資，反而與「Web 化能省成本」的原始期待背道而馳。

判斷的重點在於：「如果網路斷線 30 分鐘，這項業務等得起嗎？」 如果等不起，至少負責這項業務的畫面應該做成能在本機運作的形式。

6. 情況四：以鍵盤為主的高速、大量輸入是業務核心

單據輸入、驗貨與出貨登記、客服中心的應對畫面──整天面對這個畫面、以鍵盤為主大量輸入資料的業務類型。這是桌面 UI 完成度極高、Web 化後體感品質容易下降的領域。

  • 回應延遲：像 Blazor Server 這種伺服器連線型架構，每一次使用者操作都需要往返網路，導致 UI 延遲提高2。即使每次操作只多出數十毫秒，在一天數千次操作的輸入業務中，也一定會被感受為「卡卡的」。
  • 重現鍵盤操作：以 Enter 鍵移動欄位、功能鍵指派、輸入過程中的即時驗證，這些「輸入業務的理所當然」，都必須在與瀏覽器預設行為(Enter 送出表單、F1 開啟說明等)衝突的情況下硬做出來。並非做不到，而是需要額外花費成本，才能追上桌面框架與表格元件原本就內建的品質。
  • 大量資料的表格：要在 Web 上實現能以虛擬捲動流暢顯示數萬列資料、支援儲存格編輯、欄位凍結、複製貼上等桌面級表格，需要採用功能強大的商用元件，並投入相應的調校成本。

如果只是檢視、核准、偶爾登記，Web 表單就已足夠。但對於輸入速度本身直接關係到業務生產力的畫面，請冷靜確認是否真的能享受到 Web 化的效益(隨處可用)──那個畫面終究是不是只會在辦公室固定座位使用而已。如果使用地點是固定的，Web 化就只有損失，沒有收穫。

7. 情況五：用「移植」的估算方式，做出了「重新開發」

前面談的是功能與使用型態，最後要談的是成本結構的問題。Web 化計畫中途崩潰的典型模式，就是用「把現有的東西搬到 Web」這種移植的想像去估算，事後才發現其實是重新開發。

  • 畫面資產無法沿用。 沒有現實可行的方式能把 WinForms 或 WPF 的畫面定義、畫面邏輯自動轉換到 Web，UI 必須把所有畫面重新設計、重新開發。畫面數量乘以複雜度，就直接等於工時。
  • 必須先盤點業務邏輯。 長年運作的應用程式中，規格書上沒有記載、只存在於程式碼裡的業務規則並不罕見。Web 化的工作包含把這些全部挖出來重新實作。這一點正好對應「VB6、Access 業務應用程式的延命與遷移」中提到的「不要貿然全面重寫」原則。
  • 完成後的維運成本會結構性地增加。 桌面應用程式的維運工作是照顧終端設備，但 Web 應用程式則會產生伺服器(或雲端)建置、監控、備份、憑證與安全性更新等持續性工作。如果公司內部沒有這樣的體制，就得每月支付外包費用。Web 化的成本比較，必須把這項營運成本也算進去，而不能只看初期開發費用。
  • 安全性的前提會改變。 原本只在公司內部網路運作的應用程式一旦 Web 化並開放外部存取，驗證、授權、通訊加密、攻擊防範的要求水準都會提升一個層級。這也是「Web 化成本」的一部分。

再次強調，這些並不是否定 Web 化的材料，而是用來正確估算的材料。就算把重新開發與營運成本都算進去，Web 化的效益仍然更大，那就應該推進。如果不划算，就應該先檢討維持 Windows 應用程式型態的現代化(升級到最新 .NET、改善發布方式、翻新 UI)這種投資更小的方案，是否就能滿足大部分的動機。

8. 現實解方：不要把選項侷限在全面 Web 化或全面維持 Windows

把前面的判斷落實到實務上，多數情況下答案既不是「全面 Web 化」也不是「維持現狀」，而是拆分。

想法很單純，就是把第 1 章的判斷表不套用在整個應用程式上，而是逐一套用在每個功能上。

  • 搬到 Web 的部分：多據點、多人需要檢視的資料檢視、搜尋、彙總，報表下載、核准等輕量操作。主檔維護通常也屬於這一類。
  • 留在 Windows 的部分：與設備、周邊裝置的連動，本機檔案的監控、批次處理，即使離線也不容中斷的現場業務，高速輸入畫面。
  • 共用的部分：資料庫與業務邏輯。將資料集中管理，讓 Web 應用程式與 Windows 應用程式都參照同一組 API(或資料庫)。只要把這部分共用化，就能實現「現場用 Windows 應用程式輸入，總公司用瀏覽器即時確認」這種能滿足大部分 Web 化動機的架構。

這種架構有著全面 Web 化所沒有的實務優點：一次要重做的範圍較小、能從效益最大的部分(檢視類)開始逐步推進，以及不會犧牲現場的操作體驗。反過來說，這也代表需要建立同時維護 Windows 應用程式與 Web 應用程式兩套系統的體制，因此如果目標應用程式規模較小、功能又以檢視為主，乾脆全面 Web 化也未必不是更好的選擇。這裡同樣不是二選一，而是程度的問題。

另外，如果需求是「畫面想用 Web 技術打造，但又想碰觸本機資源」，Electron 或 Blazor Hybrid(WebView2)這類混合型方案也是一個選項。它們可以在不受瀏覽器沙盒限制的情況下使用 Web 技術打造的 UI，但請留意這終究是需要發布的桌面應用程式，無法回應「只想靠瀏覽器使用」的需求。

9. 決定 Web 化之前的檢查清單

在請廠商報價或提交公司內部簽核之前，先確認以下項目，可以減少後續的返工。

  1. 拆解動機：發布的麻煩、使用地點、技術過時，究竟哪一項才是真正的課題？如果只是發布問題，改變發布方式是否就足夠？
  2. 是否有硬體連動：是否有直接與序列埠、USB、量測儀器、特殊印表機通訊的功能？如果有，先決定這部分該如何處理(維持在 Windows／代理程式架構)。
  3. 對本機資源的依賴程度：是否有資料夾監控、檔案批次處理、與 Excel 等的行程連動？業務流程能否改為伺服器處理型？
  4. 離線需求：如果網路斷線 30 分鐘，這項業務等得起嗎？
  5. 輸入業務的比重：是否有整天用鍵盤輸入的畫面？那個畫面真的需要「隨處可用」嗎？
  6. 使用者與使用地點的實際情況：誰、從哪裡、想檢視或輸入什麼？是「所有人都要在公司外使用全部功能」，還是「總公司只是想看資料」？
  7. 營運體制：伺服器的建置、監控、安全性更新由誰負責？每月費用大約多少？
  8. 業務邏輯的所在位置：規格書與程式碼是否一致？盤點所需的時間是否已納入估算？

如果第 2 到第 5 項中有符合的項目，建議以拆分架構為主軸來檢討，而非全面 Web 化。發包前的整體整理，也請參考「委外・委託開發 Windows 應用程式前該整理的事項」。

結語

Web 化是工具，不是目的。它對多據點使用、減少終端管理負擔的效果十分明確，但設備連動、本機檔案處理受限於瀏覽器的安全性設計，很難靠框架選擇或工程投入來克服；離線運作、高速輸入雖然技術上可以應對，但打造與維運的成本，往往與「Web 化會變輕鬆」的原始目的背道而馳。而且 Web 化不是移植而是重新開發，完成後還會新增伺服器維運這項持續性成本。

正因如此，實務上的判斷不是「要不要 Web 化」，而是「哪些功能搬到 Web、哪些功能留在 Windows、哪些部分要共用」這樣的設計課題。從既有應用程式的盤點，到 Web 化可行性的判斷、拆分架構的設計，通常都需要根據程式碼與營運的實際狀況來判斷，如果拿不定主意，歡迎與我們洽詢。

相關文章

相關諮詢領域

合同會社小村軟體(KomuraSoft LLC)提供既有 Windows 應用程式是否該 Web 化的判斷、Web 與 Windows 拆分架構的設計、包含設備連動與本機處理的業務應用程式開發與改版等技術諮詢服務。

參考資料

  1. Microsoft Learn, Blazor app hosting models (Blazor for ASP.NET Web Forms developers)。關於 Blazor WebAssembly 組件在瀏覽器的安全沙盒內執行，存取檔案系統或開啟任意網路連線會擲出 PlatformNotSupportedException 的內容。 ↩ ↩2 ↩3

  2. Microsoft Learn, ASP.NET Core Blazor hosting models。關於 Blazor WebAssembly 的功能僅限於瀏覽器所支援的範圍、Blazor Server 中每一次使用者操作都伴隨網路往返而導致 UI 延遲提高、連線中斷後應用程式即無法運作且不支援離線等內容。 ↩ ↩2 ↩3 ↩4

  3. MDN Web Docs, Web Serial API 及 USB (WebUSB API)。關於 Web Serial API 支援的瀏覽器僅限於 Chromium 系(Chrome / Edge 等)以及 151 版以後的桌面版 Firefox、Safari 尚未支援、Android 版 Chrome(138 以後)僅部分支援透過藍牙 RFCOMM 的序列通訊、WebUSB 僅限 Chromium 系(各頁面 Browser compatibility 章節)等內容。 ↩

  4. MDN Web Docs, File System API 及 FileSystemObserver。關於 showOpenFilePicker / showDirectoryPicker 等存取本機檔案、資料夾的擴充功能，以及監控使用者選取資料夾變動的 FileSystemObserver(實驗性、尚未標準化)僅支援 Chromium 系瀏覽器、Firefox / Safari 無法使用的內容。 ↩

  5. Microsoft Learn, Considerations for unattended automation of Office 及 Microsoft Support, Considerations for server-side Automation of Office。關於 Microsoft 不建議也不支援從無人值守、非互動式的用戶端(ASP.NET、DCOM、NT 服務等)自動化操作 Office 應用程式，原因是可能導致不穩定與死結，並建議改用 Open XML 檔案格式直接編輯等替代方案的內容。 ↩

  6. Microsoft Learn, Windows App Development Frequently Asked Questions。關於針對 Windows 專屬應用程式選擇原生框架(WinUI / WPF / WinForms)的理由，包含效能、與 Windows API 的深度整合、離線支援等內容。 ↩

相關文章

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

相關主題

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

與本主題相關的服務

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

常見問題

整理諮詢這個主題時常見的問題。

如果反正要更新舊的 Windows 應用程式，順便 Web 化比較好嗎？
我們不建議只因為「太舊」就決定 Web 化。Web 化所需的工時比起移植更接近重新開發，而且 Web 應用程式同樣會面臨技術過時的問題(公司內部系統因為只支援 IE 而被困住的案例就是典型例子)。判斷的關鍵不在於技術的新舊，而在於這個應用程式實際的使用型態。如果是多據點使用、想減少終端管理負擔，Web 化的效益就會顯現；但如果核心是設備連動或本機檔案處理，將 Windows 應用程式升級到最新版 .NET、翻新 UI 等「維持 Windows 應用程式型態的現代化」，往往更符合成本效益。
Web 化之後，發布與安裝的麻煩不就不見了嗎？
用戶端的發布作業確實會消失，但如果動機「只是」想省去發布的麻煩，其實有比 Web 化更輕量的解法。只要改用 ClickOnce 或 MSIX 這類具備自動更新機制的發布方式，即使維持 Windows 應用程式的型態，也幾乎不需要再逐台安裝。而且一旦 Web 化，取而代之的是伺服器(或雲端)建置、監控、安全性更新等新增的持續性維運成本。請同時考量省下來的成本與新增的成本後再做判斷。
可以只把應用程式的一部分 Web 化嗎？
可以，而且在實務上這往往才是現實可行的做法。典型的模式是把資料檢視、彙總統計、報表、跨據點查閱等功能搬到 Web，而設備連動、現場的高速輸入、本機檔案處理則維持為 Windows 應用程式，兩者透過共用的 API 與資料庫連接。相較於全面 Web 化，一次要重做的範圍較小，也能從 Web 化效益最大的部分開始逐步推進。
Electron、PWA、Blazor Hybrid 這類中間選項如何？
這些性質各不相同，需要分開來看。Electron 與 Blazor Hybrid(WebView2)是以桌面應用程式的形式運作，因此不受瀏覽器沙盒限制,可以存取檔案與設備，畫面則能用 Web 技術撰寫。不過它們終究還是需要發布與更新的桌面應用程式，無法回應「希望只靠瀏覽器就能使用」的需求。另一方面，PWA 雖然可以像已安裝的應用程式一樣釘選到工作列，但本質上仍是在瀏覽器中執行的 Web 應用程式，對本機資源的存取限制也與一般 Web 應用程式相同。重要的是先釐清究竟想透過 Web 化解決什麼問題。

作者檔案

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

Go Komura

小村軟體有限公司 代表

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

聯絡我們
回到部落格一覽