WinForms。WPF。UWP。WinUI 3。MAUI。Blazor Hybrid。WebView2。亲爱的微软，这可真是一团乱麻。
如果按不同方式统计，在 Windows 上构建桌面 UI 的框架至少有七种。它们诞生于不同的时代，体现了不同的设计理念，也面向不同类型的应用。但它们之间又存在足够多的重叠，以至于很多人都不太清楚该在什么情况下使用哪一个。
在本文中，我们将尝试梳理这些技术，并把每一种选择放到更大的背景中来理解。
选择从不缺少
大多数操作系统都会提供一套官方 UI 工具包。通常来说，这意味着有一两个适用于新项目的现代框架，以及一个仍然受到支持但已经不再流行的旧框架。当然，您也可以选择第三方框架，不过它们通常无法像官方框架那样与系统深度集成。
在 iOS 上，您通常会在 UIKit 和 SwiftUI 之间选择；在 Android 上，则是 View 系统和 Jetpack Compose；在 macOS 上，是 AppKit 和 SwiftUI。Linux 在细节上要复杂一些，但主流发行版基本围绕两大工具包：GTK 和 Qt。
但 Windows 的情况不同。如果您想使用 .NET 构建桌面应用，仅微软官方就提供了多达六种选择：WinForms、WPF、WinUI、MAUI、基于 Web 的 Blazor Hybrid，以及作为独立方案的 WebView2。
要理解微软为何积累了如此多样的选项，让我们回顾一下它的发展历程。
工具包简史
WinForms
在 1990 年代末到 2000 年代初，Windows 桌面应用通常基于 Win32/USER32 技术栈开发。那是当时且至今仍是 Windows 内置的标准库。因此，它是大多数应用程序开发者的默认选择。它提供了一套通用的控件，并使您的应用程序在视觉上与其他应用以及操作系统本身保持一致。
来自 Win32 API 的原始 Windows 控件。
2002 年，微软发布了 .NET，同时推出了 WinForms —— 一个用于在 .NET 中构建 Windows 桌面应用的 UI 库。WinForms 将同样的 USER32 标准控件封装在一个更加符合 .NET 风格、面向对象的 API 之下。开发者不再需要围绕句柄和消息循环编写代码，而是通过控件、属性和事件来构建界面。WinForms 还提供了一些更高层级的复合控件，用于实现常见的 UI 模式。
一个 WinForms 应用，其控件基本与 Win32 相同。
在相当长的一段时间里，WinForms 是在 .NET 中构建 Windows 桌面 UI 的唯一方式。
WPF
2006 年，微软在 .NET Framework 3.0 中推出了 WPF。与 WinForms 不同，WPF 并不是对 USER32 控件的封装，而是一个独立的 UI 框架，拥有自己的控件、布局系统和渲染管线。界面通常使用 XAML 定义，而应用逻辑则写在代码中。
WPF 引入了更加现代的布局和渲染理念。开发者不再通过固定坐标摆放控件，而是通过布局系统根据可用空间自动调整界面。WPF 还包含了一个图形系统，内置支持可缩放图形、变换和动画。
在 WPF 应用中，更容易创建高度自定义的界面。
曾经有一段时间，人们认为 WPF 最终会取代 WinForms，但这件事并没有发生。
Windows 8、Metro 和 UWP
大约在 2010 年，微软推出了 Windows Phone，这是一款新的移动操作系统，并带来了全新的设计语言 Metro。当时它看起来与 iOS 和 Android 完全不同，而且很多人都很喜欢它，我自己也是。
两年后，Windows 8 将 Metro 带到了桌面。为了表明他们的决心，微软甚至移除了 Windows 一切开始的地方——开始菜单。取而代之的是一个全屏的磁贴界面，被视为未来的新界面。
Windows 8 中取代开始菜单的 Metro 风格开始屏幕。 来源。
Windows 8 用开始屏幕取代了开始菜单。
Metro 不仅仅是一种新的 UI 风格，它还规定了应用的行为方式和分发方式。这些规则在移动平台上很常见，但在桌面平台上却是新的：例如从应用商店安装、针对触控设计，以及围绕全屏页面和类似移动应用的导航方式来构建应用。
为了开发这类应用，微软推出了一套新的技术栈，雄心勃勃地命名为 Universal Windows Platform（通用 Windows 平台），简称 UWP。它成为这类新型应用的官方框架，而 WinForms 和 WPF 则继续留在经典桌面 UI 领域。
遗憾的是，Metro 并没有持续太久：开始菜单重新回归任务栏，Windows Phone 逐渐消失，但 UWP 仍然存在，并演变成了新的形态。
WinUI 3
2017 年，微软推出了 Fluent 设计系统，也就是你如今在 Windows 11 中看到的那套设计语言。这一次，它并不是新的应用模型，而是一套设计语言和控件集合。
微软并没有把这些新控件加入到 WPF 中，而是推出了另一项技术，专门用于构建符合 Fluent 设计语言的桌面应用，它就是 WinUI 3，并且建立在 UWP 的基础之上。
WinUI 3 应用程序中的 Fluent 控件。
随着 WinUI 3 的推出，如今确实有三个官方支持的桌面框架可供选择。
MAUI
在 2010 年代初期，Xamarin 将 .NET 移植到了 iOS 和 Android，并推出了一套可以同时运行在两个平台上的 UI 工具包。您只需编写一次 UI，就可以在两个平台上发布应用。在底层，它仍然使用各平台的原生工具包：iOS 上是 UIKit，Android 上是 Android Views。
微软在 2016 年收购了 Xamarin，并最终将其发展为 Multi-platform App UI（多平台应用 UI），也就是 MAUI。核心理念仍然相同：封装各个平台的原生 UI 工具包，用一套代码支持多个平台。随后 MAUI 也扩展到了桌面平台。
在桌面端，MAUI 只支持 Windows 和 macOS。它沿用了与移动端相同的架构：为每个平台封装原生工具包。在 Windows 上使用 WinUI 3，在 macOS 上使用 Mac Catalyst。
这样一来，Windows 桌面领域就有了四种框架：WinForms、WPF、WinUI 3 和 MAUI。它们在某种程度上既相互竞争，又相互补充。
Web 技术席卷而来
当我们还在讨论原生 UI 工具包时，也许等到真正选定一个的时候，它就已经过时了。每当我下载一个新应用时，我都会玩一个小游戏：它是原生应用还是 Chromium？如今很多应用其实都是“伪装成桌面应用的浏览器”。无论是游戏启动器还是某个小工具，很可能您看到的界面其实是 HTML 和 CSS，而不是 WPF。
很多开发者不喜欢这种应用，因为它们为了完成相对简单的任务却消耗了大量内存和 CPU。顺便说一句，在写这篇文章的时候，内存的价格甚至比黄金还贵。
但现实是很难与 Web 竞争，因为经济规律非常直接：Web 开发的速度实在太快了。您拥有成千上万成熟的组件库，界面定制成本更低，而且 AI 对 Web 技术的理解也远远更好。
于是微软没有试图对抗这种趋势，而是选择加入其中。
Blazor Hybrid
Blazor Hybrid 是微软最直接、最官方的使用 Web UI 构建桌面应用的方式。
Blazor Hybrid 允许您使用 C#，留在 .NET 生态系统内，并使用 Blazor 构建界面。Blazor 最初是一项服务器端技术。
Blazor Hybrid 嵌入了一个 Blazor 渲染引擎，用于在常规桌面窗口中显示页面。在底层，这通常是一个托管了 WebView2 控件的 MAUI 桌面应用，因此 UI 本质上仍然是由 Chromium 渲染的 HTML 和 CSS。
Blazor Hybrid 应用：Web 界面在 WebView2 中渲染。
WebView2
WebView2 是一个基于 Edge 的 WebView 控件，用于 Windows 桌面应用。它是早期基于 Internet Explorer 的 WebView 的继任者。您可以把它嵌入到 WinForms、WPF、WinUI 3 或 MAUI 应用中，并让它加载网页内容。
即使在较老的应用中也能看到它：登录界面和仪表盘通常就是网页。一旦您开始将部分 UI 实现为网页，那么整个应用被吸入 Web 视图可能就只是时间问题了。
公平地说，WebView2 在这篇文章中算是个异类。它不是一个框架，但我认为值得一提，因为它扮演了赋能者的角色。这个组件使得 .NET 开发者以及微软自己能够选择 Web UI，并在合适的时候有选择地使用它。
Electron
Electron 可以说是使用 Web UI 构建桌面应用的代表技术。它几乎开启了整个类别，以至于很多人会把类似应用都称为“Electron 应用”，即使它们实际上使用的是其他技术。
它允许你使用与 Web 应用完全相同的技术栈来构建桌面应用：前端是运行在 Chromium 中的 HTML、CSS 和 JavaScript，而后端同样使用 JavaScript，但运行在独立的 Node.js 线程中，可以访问文件、进程以及操作系统集成等功能。
当然，Electron 并不是微软的技术。虽然它最初诞生于 GitHub，而 GitHub 后来被微软收购，但这个项目并不属于微软，也不由微软管理。
之所以在这里提到它，是因为这种技术的规模和影响力非常大，而且微软自己也大量使用 Electron。
务实胜过教条
WinForms 是 .NET 最早的桌面 UI 库。如果您在 2000 年代初期用托管代码开发 Windows 应用，这是唯一的官方选择。
WPF 引入了更加现代的 UI 模型：基于布局的设计、矢量渲染、模板机制以及 XAML，它明显超越了 WinForms 的限制。
UWP 是微软试图将手机和桌面统一到同一设计语言和应用模型之下的尝试。Metro 定义了视觉方向，而 UWP 则是实现它的平台。
WinUI 3 延续了 Fluent 设计语言，用于构建桌面应用，同时不再依赖原始的 UWP 平台，它将现代 Windows 控件从旧的应用模型中解耦出来。
MAUI 面向跨平台开发，提供统一的 UI 抽象，使 Windows 成为多个支持平台之一，而不再是唯一中心。
Blazor Hybrid 和 WebView2 则承认一个现实：Web 技术已经主导了 UI 开发。它们提供了一种官方支持的方式，让开发者可以在桌面应用中使用 HTML 和 CSS，而不是与这种趋势对抗。
简而言之，这其实并不是一团混乱。实际上，这是微软在做务实的选择，并且在尽量避免破坏已经运行良好的技术。当环境发生变化时，他们会推出新的技术来适应变化，同时继续维护旧技术，因为向后兼容非常重要。
事实上，微软在自己的应用中也采用了同样务实的做法：新版 Teams 客户端是在 WebView2 中运行的 React，Azure Data Studio 使用的是 Electron，甚至有人发现开始菜单中使用了 React Native。
所以，不要寻找那个唯一被青睐的框架。从您的约束条件出发，选择匹配的工具，然后继续前进。微软务实的好处是，您也可以同样务实。
发送中。。。
您的个人 DotNetBrowser 试用密钥和快速入门指南将在几分钟内发送至您的电子邮箱。