开篇：一个没人能回答的问题

想象一下这个场景：

一间会议室，坐满了程序员。有人举手问了一个听起来再简单不过的问题：

“我要开发一个新的 Windows 桌面应用，该用什么框架？”

然后——全场鸦雀无声。

沉默了几秒后，有人试探性地说："WPF？"另一个人摇头说："WinUI 3 吧。"第三个人直接摊牌：“要不咱们用 Electron 算了？”

会议彻底跑偏。那个问题，始终没有答案。

如果你觉得这只是一次普通的技术分歧，那你就低估了这件事的严重性。当一个操作系统平台连"该怎么画界面"都说不清楚的时候，它就已经背叛了它的开发者。 没有任何借口。

而这个荒诞的局面，是微软花了整整三十年，一步一步亲手缔造的。

---

第一幕：黄金年代——一个系统，一本书，一个答案（1988）

故事要从一个叫 Charles Petzold（佩措尔德）的人说起。

1988年，他写了一本书叫《Programming Windows》（Windows 程序设计），厚达852页，用的是C语言和 Win16 API。这本书虽然又厚又硬核，但它代表了一个极其珍贵的东西：

一个唯一的、清晰的、权威的标准答案。

后来的 Win32 更庞大了，但核心逻辑没变——消息循环、窗口过程、GDI绘图。思维模型虽然有点奇怪，但它只有一个。Petzold 把它解释清楚了，你学会了，你就能干活，你就能成功。

这就像牛顿力学的 F=ma。简洁、有力、普适。

一个操作系统，一套API，一门语言，一本书。

没有人在那里争论"要不要用托管代码"，没有人纠结"用哪个框架"。只有 Win32 和 Petzold，就这么简单，就这么好用。

这是"物理学"式的优雅——一条公式走天下。而不是"化学"式的混乱——这个方案只在特定温度下有效，那个方案只对元素周期表的某一列管用，还得看木星是不是在第七宫。

接下来发生的事情，堪称一部教科书级的史诗：一家拥有最聪明大脑和最雄厚资源的公司，如何用三十年时间，把一切搞得一塌糊涂。

用原文作者的话说：Brilliant people doing stupid things.（聪明人干蠢事。）

---

第二幕：面向对象的狂热——开始造轮子了（1992–2000）

Win32 确实有局限性。它太底层了，写个按钮都要几十行代码。微软需要改进它。

但微软的改进方式很"微软"：不是给你一个更好的答案，而是一口气给你扔出七八个半成品，让你自己去拼。

• MFC（1992）：用C++把 Win32 包了一层。如果说 Win32 本来就不优雅，那MFC就像是给一个邋遢汉套上了一件由其他西装拼接而成的西装——更丑了。
• 接着是 OLE、COM、ActiveX。这些东西严格说来都不是GUI框架，而是组件架构。但它们像病毒一样感染了Windows开发的每一个角落，引入了一种让人头皮发麻的认知复杂度。

原作者回忆：九十年代末他在一场技术会议上，花了整整一小时试图搞清楚"OLE文档"、"COM对象"和"ActiveX控件"三者的区别。他看演讲者的眼神，就像在看一个嘴角挂着老鼠尾巴的人。

微软在干什么？ 它不是在给开发者讲一个连贯的故事，而是把一堆技术零件倒在桌上说：“自己拼去吧。”

为什么会这样？因为微软的高管们发现了一件事：在每年的开发者大会上吹一个酷炫的新概念，比踏踏实实帮开发者解决问题，更能彰显自己的技术领导力。

这就是"发布会驱动开发"的起源。KPI不是"开发者成功了"，而是"台上的VP看起来很牛逼"。

---

第三幕：一个绝世好饼，和它引发的内战（2003–2006）

2003年，微软画了一张真正惊艳的蓝图。

在那年的PDC开发者大会上，微软发布了代号 Longhorn 的下一代Windows愿景，包含三大支柱：

• WinFS——一个革命性的关系型文件系统
• Indigo——统一通信框架（后来的WCF）
• Avalon——GPU加速的、基于矢量的全新UI引擎，用一种叫 XAML 的声明式语言驱动（后来改名叫 WPF）

开发者看完Demo，全场疯了。这是对的方向！这才是未来！

然而。

2004年1月，微软高管 Jim Allchin 在一封内部备忘录里用了一个词来形容 Longhorn 的现状：

“a pig.”（一头猪。）

整个项目臃肿不堪，性能灾难级别。到2004年8月，微软宣布：全部推倒重来。 从 Server 2003 的代码库重新开始。

而在这次惨痛的重启之后，Windows 部门的领导层发出了一道非正式但铁一般的指令：

“Windows里面绝对不准再用他妈的托管代码（managed code）。所有新代码，一律用C++。”

WPF 最终随 Vista 一起发布了，但 Windows 系统自己的界面（shell）拒绝使用 WPF。

这里埋下了灾难的种子。Windows 团队对 .NET 的怨恨，从此再也没有愈合。 在他们看来，正是 .NET 团队那帮人搞的托管代码实验，导致了微软历史上最丢脸的一次失败。

这种怨恨，演变成了一场长达 13年 的机构内战：Windows 团队 vs .NET 团队。两拨人不在同一栋楼，不汇报给同一个VP，路线图完全不同。

这场内战的后果：WPF 沦为孤儿，Silverlight 惨遭杀害，UWP 胎死腹中，最终给我们留下了今天这个群魔乱舞的烂摊子。

---

第四幕：Silverlight——一套始乱终弃的经典剧本（2007–2010）

WPF 在2006年底发布，技术上其实非常出色——XAML声明式UI、硬件加速渲染、强大的数据绑定。如果微软咬定WPF不放，全力投入，故事可能完全不一样。

但微软没有。

2007年，微软推出了 Silverlight：一个轻量级的浏览器插件，用来对标 Adobe Flash。它跨平台、优雅、性能好，后来还成了 Windows Phone 的开发基础。到2010年前后，Silverlight 看起来就是富客户端应用的未来。

大量开发者押上了身家——公司项目用Silverlight重写，团队花几个月学习新技术栈，客户合同绑定了Silverlight方案。

然后，在2010年的 MIX 大会上，一位微软高管在问答环节随口说了一句：

“Silverlight 不是跨平台战略，它是给 Windows Phone 用的。我们现在的方向是 HTML5。”

Silverlight 团队自己事先都不知道这个消息。 那些把整个业务线押在 Silverlight 上的开发者，是从一场发布会的Q&A环节里得知自己被抛弃的。

Silverlight 不是被技术打败的。技术本身没问题。它是被一个商业决策杀死的，而开发者是全宇宙最后知道的人。

记住这个剧本。因为它会反复上演。

---

第五幕：平板恐慌与内战总爆发（2012）

苹果卖了2亿台iPhone。iPad正在蚕食PC市场。微软慌了。

微软的回应是 Windows 8 和它的触屏界面 Metro，底层是一套叫 WinRT 的全新运行时。

注意：WinRT 故意没有建立在 .NET 之上。 还记得 Windows 团队对 .NET 的深仇大恨吗？这里就是总爆发。WinRT 是纯 C++ 原生运行时，跟 WPF、WinForms、以及开发者在 .NET 上十年的积累彻底切割。

此时微软内部实际上有两个完全矛盾的声音在同时喊话：

• Windows 团队在推 WinRT
• .NET 团队还在宣传 WPF

不同的大楼，不同的VP，不同的路线图。

开发者在 2012 年的 //Build 大会上听到的是这样的信息：

“未来是 WinRT！HTML+JS也是一等公民！.NET还能用！C++回来了！你应该写Metro应用！你的WPF代码也没问题！”

这不是战略。这是饥饿游戏的竞技场，六支队伍在台上争抢你的注意力。

企业开发者看了一眼 UWP 的沙盒限制、强制商店部署、以及大量缺失的Win32 API，头也不回地走了。这个本该把他们引入现代化的框架，结果被设计成了一个为平板应用商店服务的玩具——而那个应用商店从来没有真正繁荣过。

---

第六幕：永远在"下一个版本会修好"（2015–至今）

Windows 10 带来了 UWP（通用Windows平台）——号称一次编写，PC、手机、Xbox、HoloLens 全部运行。纸面上很美。

但现实很骨感：

• Windows Phone 已经奄奄一息
• 微软自己的旗舰产品——Office、Visual Studio、Windows的Shell——全都没用UWP

连亲爹都不用，你让外人怎么信？

UWP 凉了之后，微软的官方回答变成了令人绝望的 “看情况”（it depends）：

新应用用UWP，老应用继续用WPF，想要现代API就用XAML Islands桥接，WinUI 3快来了再等等，但WinUI 2是给UWP专用的别搞混了，Project Reunion会统一一切的，哦我们改名叫Windows App SDK了，但它还是不能完全替代UWP……

技术版的布朗运动——无规则、无方向、无意义地来回震荡。

有个开发者在2024年写道：

“我这些年一直在追微软的变化：UAP、UWP、C++/CX被C++/WinRT替代但没有工具支持、XAML Islands、XAML Direct、Project Reunion、WinAppSDK重启、WinUI 2.0和3.0之间的混乱切换……”

十四年。十四次急转弯。 这个人值得一枚勋章和一个道歉，而且先给勋章。

顺便说一句，Project Reunion / WinUI 3 确实代表了真正的进步。但你有没有想过，为什么这个问题会存在？ UWP的控件被绑定在操作系统上，因为它属于Windows团队管。.NET团队管不着。开发工具团队也管不着。Project Reunion 本质上是一个组织架构问题的技术补丁——把部门墙的问题伪装成了一次框架升级。

---

第七幕：一座没有管理员的动物园

来，我们数一数，现在 Windows 上到底有多少种GUI技术在同时运行：

微软自家的原生框架（6个）

技术	诞生年份	现状
Win32	1985	还活着。还在用。Petzold那本书居然还适用
MFC	1992	C++封装Win32。维护模式。苟延残喘于企业和CAD领域
WinForms	2002	.NET封装Win32。“可用但不推荐”。但做数据录入表单它最快
WPF	2006	XAML + DirectX渲染。已开源。但微软不再投入资源
WinUI 3	2021	所谓的"现代答案"。路线图模糊
MAUI	2022	跨平台方案。.NET团队的最新赌注。Bug多到让人心碎

微软的Web混合方案（2个）

• Blazor Hybrid —— .NET组件塞进原生WebView
• WebView2 —— 在传统应用里嵌入Chromium浏览器内核

第三方框架（9个）

技术	说明
Electron	Chromium + Node.js。VS Code、Slack、Discord都在用。目前Windows上部署最广泛的桌面GUI技术——跟微软没有半毛钱关系
Flutter	Google出品，Dart语言，自绘渲染引擎
Tauri	Rust后端，轻量级Electron替代品
Qt	C++/Python/JS。真正严肃的跨平台选择
React Native for Windows	微软投资的，但技术是Facebook的
Avalonia	开源WPF精神续作。JetBrains、GitHub都在用——这些开发者已经等不及微软了
Uno Platform	把WinUI API搬到所有平台。比微软自己还认真地在推WinUI
Delphi / RAD Studio	还活着。还很快。在垂直行业软件里坚挺
Java Swing / JavaFX	是的，还在生产环境跑着。企业从不遗忘

17种方案。5种编程语言。3种渲染哲学。

这不是一个"平台生态"。这是一座没有管理员的动物园。

---

第八幕：破局——别等微软了，自己选边站

先说一个残酷的现实

读完前面七幕，你可能会有一种期待：“微软迟早会收拾好这个烂摊子的吧？”

别等了。

回顾这三十年，微软每一次说"这次我们会统一一切"的时候，结果都是在动物园里又多关了一只新动物。WinUI 3 可能是好的，MAUI 可能会成熟，但你作为开发者，你的项目不能赌在"可能"上面。你的客户不会因为"微软还在迭代路线图"就同意延期交付。

所以，与其继续在微软的框架迷宫里转圈，不如退后一步，问一个更本质的问题：

我的软件到底跑在哪里？

答案无非两种：桌面端，或者浏览器里。

选定了战场，答案就清晰了。

---

桌面端：拥抱 Qt

为什么是 Qt？

在前面那张"动物园"清单里，17种技术里只有一个选项同时满足以下所有条件：

需求	Qt 的表现
跨平台	Windows、macOS、Linux、嵌入式、移动端，一套代码全覆盖
成熟度	1995年诞生，快30年了。比微软的任何GUI框架都长寿（Win32除外）
稳定性	从没被"战略转型"杀死过。因为它不属于任何操作系统厂商
性能	原生编译，C++核心，不吃浏览器内核的内存（对比Electron）
生态	KDE桌面环境、Autodesk Maya、VLC、WPS Office、达芬奇（DaVinci Resolve）、特斯拉车机界面
语言灵活性	C++ 原生，Python 绑定（PySide/PyQt），还有 QML（声明式UI语言）
企业背书	背后是 The Qt Company（上市公司），双许可证模式（LGPL开源 + 商业授权）

把 Qt 和微软的框架们放在一起对比，最大的区别不是技术细节，而是一个字：稳。

Qt 5 到 Qt 6 的迁移确实有阵痛，但那是一次有序的大版本升级，有明确的迁移路径和时间表。而微软那边呢？WinForms → WPF → Silverlight → UWP → WinUI 3 → MAUI，每一次都是推倒重来，每一次都告诉你"之前学的不算了"。

选 Qt，你学的东西五年后还能用。选微软的框架，你学的东西可能在下一场 Build 大会后就成了遗产代码。

Qt 的短板，也要说清楚

短板	说明
学习曲线	C++ 本身就劝退一大批人。虽然有 Python 绑定和 QML，但核心生态还是 C++ 的
许可证费用	商业项目如果不想开源，需要购买商业许可证，不便宜
界面审美	默认控件风格在 macOS 上看起来不够"原生"，需要额外打磨
包体积	静态编译后体积偏大，但比 Electron 小得多
社区热度	不如前端社区那么"网红"，Stack Overflow 上的问答密度低于 React/Vue

这些短板是真实的。但跟微软三十年来反复让你重学一套新框架的成本比起来，这些都是可控的、可预期的代价。

什么时候选 Qt？

• 你的应用需要高性能（CAD、音视频编辑、工业控制、科学可视化）
• 你需要真正的跨平台（不是"write once, debug everywhere"那种）
• 你的项目生命周期是 5年以上，不能承受框架被砍的风险
• 你的团队有 C++ 能力，或者愿意用 Python + PySide 做快速开发

---

网页端：拥抱 JavaScript（但先别高兴太早）

另一个动物园

如果你以为只有微软的桌面端是群魔乱舞，那你大概还没有见识过前端框架的混乱程度。

来，深呼吸，我们来数一数 JavaScript 前端框架的"历史翻车现场"：

2010  Backbone.js    ← 曾经的王者，现在没人提了
2010  Angular.js     ← Google出品，然后Google自己把它杀了
2013  React          ← Facebook出品，目前的霸主
2014  Vue.js         ← 尤雨溪个人项目起步，现在是三巨头之一
2016  Angular 2+     ← Google重写了Angular，跟1.x完全不兼容，开发者疯了
2016  Svelte         ← 编译时框架，理念激进
2019  SolidJS        ← 长得像React但原理完全不同
2020  Qwik           ← 又一个"革命性"方案
2023  Htmx           ← 反潮流，回归服务端渲染
2024  React Server   ← React自己都在革自己的命
      Components

看出来了吗？JavaScript 前端生态的混乱程度，跟微软的桌面端如出一辙。

区别在于：微软的混乱是一家公司的内部战争造成的，而前端的混乱是整个开源社区的自由竞争造成的。前者是一个人格分裂的独裁者，后者是一个吵翻天的民主广场。

结果都一样：开发者累得半死，每两年就要学一套新东西。

但是——JavaScript 至少有一个"宪法"

尽管框架层面混乱如麻，JavaScript 生态有一个微软桌面端永远没有的东西：

浏览器本身就是那个稳定的底层平台。

不管你用 React、Vue、Svelte 还是原生 Web Components，最终它们都编译/运行在同一个东西上：浏览器引擎（V8、SpiderMonkey、WebKit）。HTML、CSS、JavaScript 这三件套，二十多年没有被推翻过。

这就像 Win32 时代的 Petzold 定律：底层是稳的，上层随便折腾，你总能落地。

而微软桌面端的问题在于：连底层都在反复推翻。Win32 → WPF → WinRT → UWP → WinUI，每一次都是换地基。

一个灵魂建议

不管你选什么框架，先把原生 JavaScript（ES6+）、HTML5、CSS3 学扎实。

框架会变，但语言和浏览器标准不会。这就是你的"Petzold底层"。React 可能十年后不在了，但 document.querySelector 和 fetch() 大概率还在。

---

桌面端 vs 网页端：怎么选？

最后一个问题：我的项目到底该做桌面端还是网页端？

                    你的应用需要...
                         │
            ┌────────────┼────────────┐
            ▼                         ▼
     离线运行？硬件访问？         随时随地访问？
     高性能计算？本地文件？       多端同步？快速迭代？
            │                         │
            ▼                         ▼
       桌面端 → Qt                网页端 → JS框架
            │                         │
            ▼                         ▼
    C++ (性能优先)              React (稳妥)
    Python+PySide (效率优先)    Vue (简洁)
    QML (现代UI优先)            Svelte (极致)

如果两者都要？那就做Web应用，用 Tauri 打包成桌面端。 别用 Electron——一个聊天软件吃 800MB 内存不是正常现象。

---

终章：教训

回头看这三十年的每一次GUI翻车，根源永远不是技术问题。恰恰相反，技术往往是好的——WPF 是好技术，Silverlight 是好技术，XAML 是好技术。

真正的病因只有三个：

1. 内部派系斗争（Windows团队 vs .NET团队，十三年冷战）
2. 发布会驱动的早产儿（Metro、UWP——为了大会上有东西吹，就仓促推出不成熟的平台赌注）
3. 商业战略急转弯，开发者最后一个知道（Silverlight——技术没问题，死于一句话）

每一次失败，都是组织失败，不是工程失败。

你要么有一个覆盖完整生命周期的可信成功路径——从采用、投入、维护到迁移都想清楚了——要么你就只有一场漂亮的发布会演讲。

前者叫战略。后者叫三十年的闹剧。

---

尾声

Charles Petzold 为了跟上微软每一次"又双叒叕发布新东西"的节奏，前后写了六个版本的《Windows程序设计》。

第六版写的是 Windows 8 的 WinRT。那是2012年。

然后他就不写了。

说实话——他被气哭了。