自 2002 年 WinForms 推出以來，微軟發布的每一個 UI 框架都被宣傳為其後繼者。WPF、Silverlight、UWP、MAUI、Blazor desktop。二十四年後，WinForms 依然存在，運行於現代 .NET 上，其設計工具的介面是任何 VB6 開發者一眼就能辨識的。Alan Cooper 和 Geary 在 1987 年設計的表單設計架構，在 2026 年仍然是開發企業級應用程式的「最少阻力」路徑，這並非偶然。

1987 年，一位建築師轉型的開發者 Alan Cooper 在加州構思了一個專為非程式設計師準備的程式設計環境。將控制項拖曳到表單上，雙擊它，然後編寫點擊按鈕時執行的程式碼。他將這個結果命名為 Tripod，於 1988 年賣給了微軟，之後它被重新命名為 Ruby，然後是 Visual Basic，並在 2002 年被移植到一個名為 WinForms 的東西上。之後，微軟花了二十年試圖用其他東西取代 WinForms。

Visual Studio 2026 仍然搭載著相同的設計工具。Cooper 和 Geary 的表單設計工具是微軟擁有過的壽命最長的生產力 UI 工具。微軟主要透過在淘汰它的鬥爭中失敗而使其得以延續。

我在 2026 年的 .NET 10 上，使用 Visual Studio 2026 編寫 WinForms 程式碼。其生產力足以讓該平台感覺起來是現代的，而非遺留的。「WinForms 已死」的慣性說法是錯誤的，而且至少在六年前就已經是錯誤的。這篇文章將從技術堆疊內部，解釋它為何錯誤的架構原因。

Cooper 的 Tripod (1987)、VB1 (1991)、VB6 (1998)，以及運行於 .NET 10 的 Visual Studio 2026 中的 WinForms，在概念上有哪些相同之處：

一位 VB6 開發者進入目前的 Visual Studio 中的 WinForms 設計工具，可以在十五分鐘內上手。這並非因為微軟很懶惰。而是因為他們找不到更好的東西，而客戶也不願意轉移到那些不夠好的東西上。

這就是當人們稱 WinForms 為遺留系統時，沒有人提及的架構現實。WinForms 不是一個框架。它是一個對 Win32 API 的受控封裝。每一個 Form 都是一個 HWND。每一個 Button 都是一個封裝 USER32 BUTTON 視窗類別的 HWND。每一個 TextBox 都封裝了 EDIT。每一個 ListBox 都封裝了 LISTBOX。整個控制項庫只是在 1993 年 Windows NT 3.1 以來 Notepad 和 Explorer 一直使用的相同 C 語言 API 上，覆蓋了一層薄薄的、結構良好的、CLR 型別的塗層。

要看清其妝容，就得卸下它。以下是直接從 C# 在 .NET 10 上調用 Win32 所需的成本，沒有 WinForms 的介入，將一個空的視窗顯示在螢幕上：

大約八十行程式碼。兩個結構和十個 P/Invoke 簽章。您需要手動管理委派的生命週期，以防止它在 USER32 仍持有其函式指標時被垃圾回收。您得到的是螢幕上一個單獨的空灰色矩形。沒有按鈕。沒有文字方塊。沒有選單。要添加一個按鈕，您需要使用 CreateWindowExW 和 BUTTON 類別分配另一個 HWND，將父視窗的控制代碼傳遞給它，在 WndProc 中切換 WM_COMMAND 以路由點擊事件，並為每個控制項編寫該程式碼。

現在，這是同一視窗在 C# 中使用 WinForms，運行於相同的 .NET 10 運行時：

在相同的 .NET 10 運行時，在相同的 Visual Studio 中，使用 VB.NET 實現的相同視窗：

三行程式碼。相同的視窗。相同的 HWND，相同的 Win32 訊息佇列，底層運行著相同的 USER32 視窗類別。運行時只是為您註冊了它並連接了 WndProc。

這也是 WinForms 即使在跨平台 .NET 上仍然是 Windows 專用的結構性原因。Linux 和 macOS 沒有 USER32。沒有 HWND 可以封裝。Wine 為原生的 Win32 二進位檔實現了一個兼容 USER32 的層，.NET Foundation 也曾週期性地考慮過類似的東西，但官方立場是 WinForms 目標是 Windows，並且將保持下去。 .NET 的跨平台部分（運行時、BCL、JIT、GC、工具）都在 Linux 和 macOS 上運行。WinForms 套件是 Windows 特定的尾巴。

這也是該模型如此持久的結構性原因。WPF 做了相反的選擇。它拋棄了 USER32 控制項，並在 DirectX 上建立了自己的保留模式渲染管線，具有框架而非作業系統擁有的組合、動畫和資料綁定。在某些方面更好：動畫、向量圖形、設計師-開發者分離。在它最需要擅長的事情上卻更糟，那就是在微軟自身的框架變動中生存下來。WPF 的技術堆疊沒有 Win32 三十年相容性保證的對等物，因為從未提供過這樣的保證。WinForms 免費繼承了 Win32 的相容性保證。

您不是建立在 WinForms 之上。您是建立在 USER32 之上，使用一種不會讓您手動編寫函式指標的語言。

實作已經跨越了三十八年。模型沒有改變。

強型別。不再有 Variant。不再預設晚期綁定。編譯器捕捉了運行時曾經會引發的 Object Doesn't Support This Property Or Method (Error 438) 錯誤。我曾交付過大約一百個 VB3、VB4、VB5 和 VB6 的企業級系統，其中相當一部分錯誤是 Variant 類型轉換錯誤。強型別消除了這類錯誤。

非同步和 await。VB6 開發者過去透過 DoEvents 迴圈和 Timer 控制項來解決的問題，現在在結構上得到了支援。表單在長時間運行時不會鎖定。整個「我的 UI 在存取資料庫時凍結」的錯誤類別，現在是一個語法決定，而不是架構問題。

NuGet 取代了「是否已註冊正確的 OCX？」。OCX 和 DLL Hell 是一場噩夢。安裝在同一台 Windows 電腦上的兩個應用程式可能會爭奪同一個 MSVBVM60.DLL 版本，而失敗者會默默地損壞。NuGet 透過專案本地安裝、傳遞性依賴解析和從 packages.lock.json 可重現的還原，是最被低估的結構性改進之一。

跨平台 .NET，自 2019 年 9 月的 .NET Core 3.0 以來。這是讓「WinForms 是遺留系統」的說法在事實上錯誤的轉折點。WinForms 遷移到了與 Blazor、MAUI、ASP.NET Core 和其他生態系統相同的現代運行時。相同的 CLR、相同的垃圾回收器、相同的 JIT、相同的來源產生器、相同的診斷工具。WinForms 在平台層是 Windows 專用的，因為 Win32 是 Windows 專用的，但託管它的運行時是目前活躍開發的、開源的 .NET。沒有哪個版本的「現代 .NET」不包含 WinForms。

高 DPI、暗模式、現代輔助功能。微軟透過 .NET 6、7、8、9 和 10 積極投資於 WinForms。每顯示器 v2 DPI 感知作為預設行為，暗模式標題列和內建控制項，現代 UIA 輔助功能，來源產生的設計工具輸出，運行時方面的原生 AOT 相關工作。這是功能性工作，而非維護。

IDE 本身。Visual Studio 2026 比 1998 年的 Visual Studio 6.0 領先了數光年。更好的偵錯工具。更好的重構。更好的 IntelliSense。更好的原始碼控制整合。更好的導航。AI 輔助程式碼審查（當您需要時）。Cooper 和 Geary 的設計工具現在坐落在一個比以前好得多的房子裡。

平台變得更好了。模型沒有改變。VB6 的肌肉記憶在經歷了世代技術轉型後，大部分保持完整。

微軟曾多次嘗試取代 WinForms。每一次嘗試都是一個故事。

Windows Presentation Foundation (WPF)，2006 年。基於 XAML，在 DirectX 上進行保留模式渲染，向量圖形，將資料綁定作為架構，將設計師-開發者分離作為一等公民。被宣傳為 Windows UI 的未來。在動畫、視覺潤飾和樣式化方面有真正的優勢。也有真正的劣勢，特別是陡峭的學習曲線以及缺乏 Win32 的相容性保證。在微軟轉向 Silverlight，然後是 Windows 8 / WinRT 後失去了動力。仍在發布，仍有使用者，但遠不及 WinForms 的安裝基礎。

Silverlight，2007 年至 2013 年。那個將成為網頁上跨平台 .NET 的瀏覽器外掛程式運行時。被 HTML5 和微軟自身的 WinRT 內部轉向所扼殺。於 2021 年 10 月正式棄用。不是繼承者。而是犧牲品。

WinRT、Windows Store 應用程式、UWP，2012 年至今。Windows 8 時代。沙盒應用程式、受限 API、僅限 Microsoft Store 的分發，並大力推動「不再有桌面應用程式」。客戶拒絕了。WinForms（以及總體上的 Win32）的桌面應用程式生存，回顧來看，主要是客戶對微軟 WinRT 賭注的反彈。微軟最終吞下了損失；UWP 最多處於維護模式。

Xamarin Forms 在 2014 年，然後是 .NET MAUI 在 2022 年。跨平台行動優先 UI 框架。其優勢是真實的。iOS、Android、Mac、Windows 上使用相同的 XAML。跨平台推廣從未觸及桌面 LOB 開發者的心智模型。工具歷史上一直很慢，佈局系統很複雜，對於 WinForms 擅長的特定類型的應用程式，其生產力模型不如 WinForms 的拖放雙擊直接。

Blazor，2018 年至今，包括 Blazor Hybrid 和 Blazor Desktop。無處不在的網頁技術，伺服器端有真正的動力。桌面外殼變體也未能取代 WinForms。對於 kiosk 應用程式或部門資料輸入工具來說，運行一個 Chromium 引擎來託管一個按鈕，並不像調用 CreateWindowExW 那樣明顯是更好的選擇。

Project Reunion，然後是 Windows App SDK 和 WinUI 3，2020 年至今。微軟最新的嘗試，旨在將 Win32、WinForms、UWP 和 WinUI 的工具故事統一在一個傘下。品牌重塑本身就承認了之前的嘗試並未成功。

每一個繼承者都將 WinForms 定位為遺留系統。每一個繼承者要麼徹底失敗，要麼市場地位比現在的 WinForms 小，要麼需要比舊程式碼的失敗模式所證明的值更大的重寫成本。該平台之所以得以生存，不是因為微軟愛它，而是因為客戶拒絕離開它，建立在一個真正有效的生產力模型之上，建立在一個微軟無法棄用而不損壞 Windows 其他部分的作業系統 API 之上。

首先是生產力論點。對於一類非常大的應用程式（企業內部工具、管理控制台、kiosk、銷售點、部門工具、政府工作流程應用程式），WinForms 比其任何繼承者都更快地交付一個可工作的應用程式。拖曳、雙擊、交付。二十年的 Stack Overflow 回答依然存在。過去二十五年來，每一位資深的 Windows 開發者都擁有這種肌肉記憶。

「足夠好」的陷阱，對 WinForms 有利。大多數 LOB 應用程式不需要向量圖形、動畫、保留模式渲染、網頁技術 UI 或跨平台部署。它們需要渲染一個表單，捕獲資料，存取資料庫，列印報告。WinForms 在這方面的程式碼行數和抽象層級比微軟自那時以來發布的任何東西都少。

不願轉移的客戶群。政府、金融、醫療保健、製造業。擁有二十年歷史的內部應用程式的行業，這些應用程式仍然在運行，而在這些堆疊中，用最新的框架重寫它們從來都不是最高優先級的預算項目。微軟最終意識到，與這些客戶爭鬥的成本比支持他們更高。

.NET Core 3.0 的轉變，在 2019 年 9 月。微軟停止將 WinForms 視為遺留遷移目標，而是將其視為現代 .NET 的一等公民的那一刻。這個單一的決定鞏固了該平台的未來。我每天都在使用 .NET 10，昨天我還在編寫 WinForms 程式碼，該平台感覺很現代。

誠實的實踐者觀點：當需要為 Windows 發布一個需要正常工作、外觀合理且架構設計不需一個月時間的產品時，WinForms 是大多數工作開發者首先會選擇的。WPF 用於優雅。MAUI 用於跨平台。Blazor 用於網頁技術。WinForms 用於完成。

如果您是從 VB3、VB4、VB5 或 VB6 過來的，並且被告知（由微軟、行業媒體、2002 年至 2010 年間的每一個 Stack Overflow 回答）您的技能已經過時，那麼請聽我直接的話。

您的肌肉記憶仍然有效。表單設計工具、事件模型、拖放控制項、雙擊、編寫程式碼的反射動作。所有這些在目前的 Visual Studio 中都有效。

您需要學習一門新語言（VB.NET 或 C#）和一個新運行時（.NET 10 而非 VB6 運行時）。這是實實在在的工作。但模型是相同的。

.NET Foundation 維護著 VB.NET。它不再處於活躍的語言演進中；微軟大約在 2020 年停止為其添加新的語言功能。但它仍然是一種受支援的一等 .NET 語言，包含在目前的 Visual Studio 中，運行於 .NET 10 上，並提供與 VB6 在概念上完全相同的 WinForms 設計工具體驗。

大多數轉型的 VB6 開發者現在都在編寫 C#。這是一個工具和語言熟悉度的問題，而不是模型問題。VB6 到 C# WinForms 的轉變主要是語法上的。概念框架得以保留。

三十八年的連續性得以保持。Tripod (1987)、Ruby (1990)、VB1 (1991)、VB6 (1998)、VB.NET / WinForms (2002)、.NET Core 3.0 / WinForms (2019)、.NET 10 / WinForms (2025)，以及 Visual Studio 2026。相同的設計工具。相同的事件模型。相同的流程。它在微軟三十八年試圖取代它的過程中得以倖存。

這篇文章與我正在撰寫的關於 Visual Basic 系列產品及其開發者的一個更長的歷史專案並列。Tripod 到 VB6 的演變，盡可能從原始參與者處獲取來源。與本文論點相呼應的書本章節正在研究中；本文是針對那些在此堆疊上進行過開發的開發者的實踐者級版本，而不是針對純粹對歷史感興趣的讀者。如果歷史線索讓您感興趣，該系列正在公開組建中。

媒體自 2006 年以來就稱 WinForms 為遺留系統。WinForms 仍然存在，運行於現代 .NET 上，在目前的 Visual Studio 中，搭載著 Alan Cooper 在 1987 年設計的設計工具，以及一個建立在 Win32 API 之上的受控封裝。那些稱它為遺留系統的框架本身已經被棄用、邊緣化，或者其市場地位遠不及現在的 WinForms。Cooper 最初為非程式設計師設計的工具，三十八年後，仍然是 2026 年開發企業級應用程式的「最少阻力」路徑。微軟為取代它而開發的任何東西，都沒有足夠的優勢來證明轉移的價值。最後站立的框架，是 VB6 開發者一眼就能認出的那個，它建立在一個微軟無法棄用而不損壞 Windows 其他部分的作業系統 API 之上。