桌面应用 UI 框架怎么选
约 1345 字大约 4 分钟...
做桌面应用，第一件让人纠结的事往往不是写什么功能，而是用什么框架搭界面。同样是聊天软件，Telegram 用 Qt、Discord 用 Electron；同样是微软自家工具，Visual Studio 是 WPF、PowerToys 却混用了 WinUI 3。这些差异背后，其实是不同的技术栈与约束在起作用。
桌面 UI 框架大致分三大阵营：Web 套壳（用网页技术套一层桌面壳）、Windows 原生（微软自家的 C#/C++ UI 栈）、跨平台原生（一套原生代码多端跑）。选型的关键不是"哪个最好"，而是"哪个最匹配你的处境"。
决策图：先问你会什么，再用约束收窄
选型别从框架列表开始挑，先问自己一个问题：你和团队已经会哪门技术栈？ 顺着已有能力走，开发成本最低；选出候选后，再用体积、性能、跨平台、移动端这几条约束去收窄。
框架地图
| 阵营 | 框架 | 语言 | 平台 | 特点 |
|---|---|---|---|---|
| Web 套壳 | Electron | JS/TS | 全平台 | 内嵌 Chromium，生态最成熟，安装包 80–150MB |
| Web 套壳 | Tauri | JS/TS + Rust | 全平台 + 移动 | 系统 WebView，安装包仅几 MB，需 Rust |
| Windows 原生 | WinUI 3 | C#/XAML | 仅 Windows | 微软最新 Fluent 原生 UI，随 Windows App SDK 发布 |
| Windows 原生 | WPF | C#/XAML | 仅 Windows | 成熟稳定，Windows 桌面业务主力，已开源 |
| Windows 原生 | Win32 / WinForms | C++/C# | 仅 Windows | 老牌轻量，最稳但界面偏陈旧 |
| 跨平台原生 | Qt | C++/QML | 全平台 | 老牌高性能，商业/开源双授权 |
| 跨平台原生 | Avalonia | C#/XAML | 全平台 | 自绘引擎，WPF 开发者易上手 |
| 跨平台原生 | .NET MAUI | C# | 桌面 + 移动 | 微软官方，一套代码多端，Xamarin 后继 |
| 跨平台原生 | Flutter Desktop | Dart | 全平台 | Google 自绘引擎，与移动端共享一套代码 |
体积和性能这一栏值得单独说一句：Electron 因为每个应用都带一份完整 Chromium，安装包和内存占用都偏大；Tauri 复用系统 WebView，"Hello World" 级应用能压到几 MB，差距可达一二十倍。而真正吃性能或已有大量 C++ 代码的场景，Qt 这类原生框架仍是更稳的选择。
从知名应用反推选型逻辑
把上面的逻辑对照真实产品，会更有体感：
- Electron：VS Code、Slack、Discord、Obsidian。它们都要跨 Windows/macOS/Linux，且团队本就深耕 Web、需要丰富的插件生态——用 Web 技术一套通吃最划算，体积换来的是开发效率。
- Qt：Telegram Desktop、OBS Studio。以 C++ 为主、对性能和跨平台都有硬要求，Qt 的成熟度和原生表现更契合。
- WPF：Visual Studio 的主体外壳。作为一个重度 Windows 桌面 IDE，成熟稳定的 WPF 比追新更重要（其内部也整合了 WinForms 等更早的组件）。
- WinUI 3：微软正推动 File Explorer、照片、Phone Link 等 Windows 11 系统应用采用它，作为主打 Fluent Design 的新一代原生 UI。
- 混用是常态：PowerToys 就不是单一框架——性能敏感模块用原生 DLL（FancyZones、Color Picker），现代 UI 用 WinUI 3，遗留复杂界面仍用 WPF，并在持续把 WPF 迁往 WinUI 3。可见大型应用完全可以按模块分别选型，而非全局二选一。
顺带一提：常被当作"WinUI 3 标杆"的 Microsoft Store，各方报道其实并不一致，部分仍将其归为较早的 UWP 技术栈——所以别把"某某应用 = 某框架"当成铁律，具体到模块往往更复杂。
进一步了解
Web 套壳这条路最容易上手，两篇实操教程可直接下钻：
原生阵营则建议直接查官方文档：WinUI 3 · WPF · Qt · Avalonia · .NET MAUI · Flutter Desktop。