如果现在要做一个新的 Windows 桌面应用，应该选什么框架？

在一次技术选型讨论中，我们试图回答一个简单的问题：

“如果现在从零做一个 Windows 桌面应用，选什么框架？”

没人能干脆回答。

• WPF 成熟，但不再演进；

• WinUI 3 面向未来，但还不稳定；

• Electron 高效，却不够“安心”；

• 而 MFC，看似过时，却依然稳稳运行在大量工业软件里。

每个选择都合理，但没有一个让人毫不犹豫。这个结果本身，比任何答案都更说明问题。

一、一个平台是否成熟，看它有没有“默认路径”

对于开发者来说，有一个非常实际的判断标准：

如果一个平台无法在很短时间内给出“推荐做法”，那么它在工程层面就是不成熟的。

Windows 在 GUI 开发上，正处于这样一种状态。

但它并不是一开始就这样。

二、1988：Windows 曾经有一个统一模型

1988 年，Charles Petzold 出版《Programming Windows》。

这本书的意义不在于厚度（800+ 页），而在于它定义了一个完整且自洽的开发范式：

• • 使用 C 语言
• • 调用 Win16（后来的 Win32）API
• • 基于消息驱动模型构建 UI

核心抽象非常明确：

• • Message Loop（消息循环）
• • Window Procedure（窗口过程）
• • GDI（图形绘制）

这个模型有明显缺点（冗长、易出错），但它具备一个更重要的特性：

一致性（coherence）

开发者只需要理解一套机制，就可以构建完整应用。

可以把它类比为物理学中的基本定律：

学习成本高，但一旦掌握，适用范围清晰且稳定。

三、1992–2000：面向对象与组件化的复杂化

随着 Win32 的普及，其局限性开始显现。微软的应对方式是不断叠加抽象层。

1. MFC（1992）

• • 本质：Win32 的 C++ 封装
• • 目标：引入面向对象模型

问题在于：

它并没有替代 Win32，而是叠加在其之上。

开发者仍然需要理解底层机制，同时还要处理 MFC 的类体系。

2. COM / OLE / ActiveX

这些技术并非 GUI 框架，而是组件模型，但它们深度影响了 UI 开发：

• • COM：二进制组件接口标准
• • OLE：对象嵌入与链接
• • ActiveX：可嵌入控件

它们带来的问题主要是：

• • 生命周期管理复杂（引用计数）
• • 接口定义抽象（IDL）
• • 调试困难

更重要的是：

这些技术没有形成统一的开发叙事。

微软开始从“提供解决方案”转向“提供技术能力”。

四、2003：Avalon / WPF——最接近统一答案的一次

在 PDC 2003 上，微软发布 Longhorn 架构：

三大组成：

• • WinFS（文件系统）
• • Indigo（通信框架，后为 WCF）
• • Avalon（UI 系统，即 WPF）

其中 Avalon（WPF）具有几个关键创新：

• • XAML：声明式 UI 描述语言
• • 基于 DirectX 的渲染系统
• • 数据绑定与模板机制

从架构角度看，这是一次完整重构：

从“过程式 UI” → “声明式 UI + 渲染引擎”

但随后发生了关键转折

2004 年，Longhorn 项目被全面重置：

• • 回退到 Windows Server 2003 代码基
• • 放弃部分新架构

同时出现一个重要内部决策：

Windows 核心组件不再依赖 .NET 托管代码

这直接导致：

• • WPF 成为“附加层”，而非系统基础
• • Windows Shell 仍使用原生技术

五、组织结构的影响：Windows vs .NET

从这一时期开始，微软内部形成两条路线：

这不仅是技术选择，更是组织分工的体现。

后果是：

• • 技术路线不统一
• • 投入资源分散
• • 缺乏长期一致性

六、2007–2010：Silverlight 与战略转向

Silverlight 的定位是：

• • 浏览器插件
• • 跨平台 UI 框架
• • WPF 的子集

在 2010 年前，它被广泛认为是富客户端的未来。

转折点：MIX 2010

在一次公开问答中，微软明确表示：

HTML5 是未来方向，Silverlight 不再作为跨平台战略。

问题不在于技术选择，而在于信息传递方式：

• • Silverlight 团队事先并不知情
• • 开发者在公开场合才得知

一个模式开始形成

技术生命周期由战略调整决定，而非技术成熟度。

七、2012：Windows 8 与 WinRT 的分裂

Windows 8 引入：

• • Metro UI
• • WinRT（Windows Runtime）

其特点：

• • 基于原生 C++
• • 支持 C++ / C# / JavaScript
• • 强制沙盒模型

同时存在两套叙事

• • Windows 团队：WinRT 是未来
• • .NET 团队：WPF 仍然可用

开发者面对的信息是：

• • 可以用 C++
• • 可以用 .NET
• • 可以用 HTML + JS

结果

没有主线，只有选项。

八、2015：UWP 的理想与现实

UWP 的目标是：统一所有 Windows 设备。

覆盖 PC、手机、Xbox、HoloLens 等平台

现实问题

1. 1. Windows Phone 失败
2. 2. 核心应用（Office、VS）未采用 UWP
3. 3. 企业开发者无法接受沙盒限制

结果

生态未形成闭环

九、2019 之后：WinUI / Windows App SDK

为修复 UWP 的局限，微软推出了：

• • WinUI 2（基于 UWP）
• • WinUI 3（与操作系统解耦）
• • Project Reunion → 后改名 Windows App SDK

目标很清晰：

把 UI 框架从操作系统中剥离出来

但问题仍然存在

• • WinUI 2 与 WinUI 3 并存
• • UWP 与 Win32 共存
• • MAUI 又引入跨平台路径

开发者得到的建议通常只有一句：

“取决于你的需求。”

十、当前生态：多技术并存

今天 Windows 上实际可用的 GUI 技术包括：

微软官方

Web 混合

第三方

一个值得注意的现象

Electron 成为事实上的主流桌面 UI 技术之一

而它：

• • 基于 Chromium
• • 与 Windows 原生体系无关

十一、问题归因

回顾历史，大多数失败并非技术本身，而源于三类深层因素：

1. 组织分裂

• • Windows 与 .NET 长期战略不一致，团队目标分散，技术路线摇摆不定。

2. 发布驱动决策

• • 技术过早亮相开发者大会，推动上市节奏超过了成熟度，导致实际落地困难。

3. 战略转向

• • 从 Silverlight 到 UWP，微软多次调整桌面战略，优化方向频繁变化，让开发者难以形成长期规划。

十二、关键结论：缺少“完整策略”

成功的平台，不只是技术，更要覆盖整个生命周期：

1. 1. 如何起步
2. 2. 是否值得长期投入
3. 3. 如何维护
4. 4. 如何迁移

如果这些问题没有答案，那么：

平台提供的只是技术，而不是可行路径。

结语

Windows 曾经提供过一个明确答案：Win32 + 消息循环模型。

开发者面对的是一个确定的世界：

• • 一个运行时（Windows）
• • 一套 API（Win32）
• • 一个编程模型（消息驱动）

路径清晰，成本可预期。

今天，它提供的是一组技术选项：

• • Win32、WPF、WinUI、MAUI
• • WebView、Blazor、Electron
• • 以及各种跨平台方案

从工程角度看，这意味着：平台从“确定性”走向了“选择性”。

而在高成本领域，这种变化并不总是进步。

选择的增加，往往伴随着：

• • 决策成本上升
• • 技术路径不稳定
• • 长期维护风险不可控

因此，开发者真正需要的，从来不是“更多可能性”，而是：一条可预期、可持续的成功路径。

有趣的是，今天最成功的桌面 UI 技术之一（Electron），反而呈现出一种“路径收敛”的特征：

• • 一个运行时（Chromium）
• • 一个编程模型（HTML / CSS / JavaScript）
• • 一条默认路径（Web 技术栈）

它未必是最优的技术解，但它提供了一个关键特性：一致性。

而这，正是 Windows 在过去三十年中逐渐失去的东西。

引用链接

[1] https://www.jsnover.com/blog/2026/03/13/microsoft-hasnt-had-a-coherent-gui-strategy-since-petzold/