WinUI 和 WPF 有什么区别？

两者都用 XAML，看起来很像，但底层 API、控件生态、项目结构、部署与打包的思路、和 Windows App SDK 的关系都不一样，把 WinUI 当成「从 WPF 轻松换过去的目标」有点危险。WPF 是表现力强、综合均衡的 Windows 专用 UI 框架，适合中到大规模的业务应用；WinUI 是 Windows App SDK 上的现代 Windows 原生 UI，以 Fluent、高 DPI、最新 Windows 体验为前提，适合全新的 Windows 专属产品。

新项目该选 WinForms、WPF 还是 WinUI？

全新的小到中型企业内部工具，如果以标准控件、录入界面为主并想快速做出来，WinForms 现在依然很能打。全新的中到大型业务应用，界面数量多、想好好利用数据绑定、样式、模板、MVVM 的话，WPF 大多数情况下最省心。全新的 Windows 专属产品，如果现代 Windows UI、Fluent、最新 Windows 体验直接关系到产品价值，WinUI 很有优势。如果存量资产规模大，还是先以延续原有技术路线为基本前提来考虑。

想用 Windows App SDK，就必须换成 WinUI 吗？

不需要。Windows App SDK 和 WinUI 不是一回事：WinUI 是 Windows App SDK 的 UI 框架部分，但 Windows App SDK 本身也可以加到 WPF / WinForms / Win32 的现有应用里。官方 FAQ 也说明了 WPF / MFC / WinForms 应用可以使用与 WinUI 无关的 Windows App SDK API，例如 App Lifecycle、Windowing、Toast 通知这类功能，有时候可以在保持现有 UI 不变的情况下引入。

WPF 和 WinForms 已经过时了吗？

不建议这么简单粗暴地下结论。WinForms 和 WPF 在现行 .NET 上都持续有文档和迁移指引，官方也把它们当作现役的 Windows 桌面 UI 来对待。尤其是业务应用中，存量资产、第三方控件、界面数量、报表或打印、设备联动、发布流程往往比 UI 框架新不新更重要。如果想在现有 WPF / WinForms 应用里分阶段混入 WinUI，官方 FAQ 也提到除非已经准备好彻底迁移 UI 框架，否则往往用不了 WinUI，所以在当成主策略之前最好先做小范围验证。

Windows Forms、WPF、WinUI 该怎么选 - 新建项目、存量资产、发布、UI 表现力判断表

2026年03月18日 01:00 · 小村豪 · WinForms, WPF, WinUI, C#, Windows 开发, UI 设计

用 C# / .NET 开发 Windows 桌面应用时，每次都让人头疼的一个朴素问题是 WinForms、WPF、WinUI 到底该选哪个。

这里危险的是，

因为最新所以选 WinUI
因为最熟悉所以选 WinForms
感觉介于两者之间所以选 WPF

这种模糊的选法。

在实务中，该看的维度更明确一些。

是全新开发，还是延续现有资产
界面是以录入表单为主，还是需要表现力
Windows 风格的现代 UI 本身是不是产品价值所在
发布、更新、企业内部运维怎么落地
团队是 Designer 文化，还是 XAML / MVVM 文化

本文把这些内容整理成一页就能看懂的判断表。另外，本文中所说的 WinUI 主要指 WinUI 3 + Windows App SDK。¹²

另外，这 3 个框架全部是 Windows 专属的。如果 macOS / Linux 也在考虑范围内，问题的前提本身就不一样了。³⁴¹

1. 先说结论（一句话）

先粗略但在实务上好用地说，大致是这样。

如果现有 WinForms 应用规模大，优先考虑继续用 WinForms
如果现有 WPF 应用规模大，优先考虑继续用 WPF
全新的小到中型企业内部工具中，以标准控件为主、以录入界面为主，且想快速做出来的话，WinForms 现在依然很强³⁵
全新的中到大型业务应用中，界面数量多，想好好利用数据绑定、样式、模板、命令、MVVM 的话，WPF 往往是最不容易出问题的选择⁴⁶⁷
全新的 Windows 专属产品中，现代 Windows UI、Fluent、最新 Windows 体验直接关系到产品价值的话，WinUI 很有优势¹²
如果只是想用最新的 Windows API，并不一定要上 WinUI。WPF / WinForms 也可以引入 Windows App SDK 的功能²⁸⁹¹⁰
以「之后慢慢把 WinUI 插进去就行」为前提来选型，有点危险。分阶段迁移这个话题，实际比想象中更难搞¹⁰¹¹

简言之，大致如下。

现有资产规模大的话，先保留那条技术路线
全新项目想快速做标准表单的话选 WinForms
全新的长期成长型 Windows 业务应用的话选 WPF
全新项目里现代 Windows UI 本身是硬性需求的话选 WinUI
只是想用 Windows App SDK 的话，不要一股脑全上 WinUI

选定框架，既是选定 UI 技术，也是在 选定发布、运维、学习成本、迁移成本。如果只靠「新 / 旧」来决定，之后会悄悄地反噬回来。以让人讨厌的方式。

2. 本文中提到的 3 个技术

首先统一一下用语。

技术	大致来说	强项
WinForms	用 Visual Studio 的 Designer 容易快速搭出表单，Windows 上的传统 .NET 桌面 UI	快速搭建界面、标准控件、现有资产的复用
WPF	使用 XAML、数据绑定、样式、模板、命令，容易做出有表现力的 UI 的 Windows 专用 UI	中到大型业务应用、MVVM、界面容易梳理
WinUI	Windows App SDK 上的现代 Windows 原生 UI	Fluent、最新 Windows 体验、高 DPI、现代产品 UI

WinForms 在 Microsoft Learn 上也被描述为具备控件、图形、数据绑定、用户输入能力，容易用 Visual Studio 的拖放式 Designer 来做应用的框架。³

WPF 是包含与分辨率无关的矢量绘图、XAML、数据绑定、样式 / 模板、2D / 3D、动画等能力、表现力很强的 UI 框架。⁴

WinUI 是 Windows App SDK 的一部分，是以高 DPI、现代输入方式、流畅动画、Fluent 系列体验为前提的当下 Windows 专用 UI 框架。¹² 另外，data binding / MVVM 的引导路径也一样具备。¹²

这里重要的是 Windows App SDK 和 WinUI 并不是同一个东西。 WinUI 是 Windows App SDK 里的 UI 框架部分，但 Windows App SDK 本身也可以加到 WPF / WinForms / Win32 的现有应用里。²¹⁰

所以，

使用 WinUI
使用 Windows App SDK 的功能

看起来很像，实际上是不同的判断。这里混在一起的话，会议室里的讨论就会变得有点云里雾里。

3. 一页看懂的判断表

首先放上实务中最好用的一张表。

情况	优先选	理由
现有 WinForms 应用的改造、延续维护、迁移到新版 .NET	继续用 WinForms	容易复用现有界面、Designer 资产、控件资产
现有 WPF 应用的改造、延续维护、迁移到新版 .NET	继续用 WPF	容易直接复用 XAML、Binding、MVVM、界面结构
全新项目、企业内部工具、设置界面、管理界面、以录入表单为主	WinForms	以标准控件为主的话上手快
全新项目、界面数量多、状态复杂、想用样式 / 模板 / MVVM	WPF	容易做界面职责分离和 UI 梳理
全新项目、Windows 风格的现代 UI 本身是硬性需求	WinUI	容易贴近 Fluent 或最新的 Windows 体验
现有 WPF / WinForms 保持不变，想用 Toast / Windowing / App Lifecycle 等功能	现有框架 + Windows App SDK	为了用上最新 Windows 功能，往往不需要整体迁移 UI
COM / ActiveX / 老旧第三方控件依赖较重	偏向现有框架	UI 之外的依赖关系迁移成本很高
受发布、更新、企业内部运维便利性影响较大	优先考虑 WPF / WinForms，WinUI 要尽早确认发布设计	WinUI 必须尽早考虑 Windows App SDK / 打包相关的前提问题
将来想做跨平台	需要把这 3 个之外的方案也纳入重新考虑	这 3 个框架全部是 Windows 专属

光靠这张表就已经相当够用了，但容易纠结的是以下这两点。

全新的 Windows 业务应用，该偏向 WinForms 还是 WPF
已经有现有 WPF / WinForms 的情况下，应不应该转向 WinUI

这两点看下面的对比表就容易理清楚。

4. 按维度划分的对比表

这里不是官方的优劣评比，而是相当实务导向的对比。

维度	WinForms	WPF	WinUI
快速做小型录入表单	◎	○	○
以标准控件为主的企业内部工具	◎	○	△~○
与数据绑定 / MVVM 的适配度	△	◎	○~◎
样式 / 模板 / 界面的表现力	△	◎	◎
与现有 Windows 桌面资产的兼容性	◎	○	△
现代 Windows 风格	△	○	◎
现有界面的延续维护、分阶段改造	◎	◎	△
只想追加 Windows App SDK 功能	○	○	◎
发布 / 更新 / 运维设计的轻松程度	○	○	△~○
打造「全新且能长期成长的 Windows 专属产品 UI」	△	○	◎

看这张表的窍门不是找谁最强，而是找谁的摩擦最少。

例如，

企业内部的设置工具
设备设置界面
列表、明细、搜索、设置、按钮
比起外观更看重运维的稳定性和改造速度

这样的场景下，WinForms 现在也相当合理。

反过来，

界面数量多
显示状态切换频繁
想把 View 和逻辑分离
想让数据的变化自然映射到 UI
想用样式 / 模板统一管理 UI

这样的场景下，WPF 相当有效。⁶⁷

另外，

想以 Windows 11 风格的外观为前提
想好好利用 Fluent
想以高 DPI、触控、现代窗口 API 为前提
是全新项目，且作为 Windows 专属产品，UI 给人的印象也很重要

这样的场景下，选 WinUI 就很自然。¹²

5. 各自适合什么样的项目

5.1 WinForms

WinForms 常常被莫名其妙地轻视，但 在快速做出以标准控件为主的业务界面这一点上，它现在依然很强。³⁵

特别适合的场景例如以下几种。

企业内部用的设置工具
设备、仪表、监控工具的设置界面
管理界面、搜索界面、列表 + 明细
现有 WinForms 资产规模大的项目
用 Designer 搭界面这种文化比较强的团队

WinForms 的强项在于，不需要引入复杂的思想，就能相当快速地做出接近成品的界面。表单、按钮、标签、文本框、数据网格。如果主战场就在这个世界里，它相当能打。

但是，弱点也很明确。

想大幅统一整体界面的外观
想用样式和模板来控制 UI
想以数据绑定为主处理复杂的状态变化
想把界面逻辑漂亮地分离出来

这些方面，WPF 或 WinUI 更自然。

用 WinForms 做大型应用，一不留神就容易变成事件处理器的丛林。所以选 WinForms 的话，

让每个界面的职责保持精简
按 UserControl 为单位做拆分
意识到相当于 Presenter / ViewModel 的边界
不要把业务逻辑直接贴在界面事件里写

这些原则从一开始就定下来，后面会更省心。

还有，实务上相当重要的一点是不需要因为想用 Windows App SDK 就放弃 WinForms。官方也提供了在现有 WinForms 应用里加入 Windows App SDK 功能的引导路径。⁹¹⁰

也就是说，WinForms 可以这样选：

UI 保持不变
只把必要的 Windows 功能做现代化改造

这一点相当务实。

5.2 WPF

从 Windows 桌面的 .NET UI 角度来看，WPF 是 综合平衡最好的中枢选项。⁴

它的强项相当明确。

能用 XAML 以声明式写界面
Data Binding 能力强
能用 Style / Template
能用 Command
容易分离 View 和逻辑
容易梳理中到大型规模的界面

WPF 官方文档中，数据绑定也被说明为 WPF 的核心功能，命令则被归纳为分离输入和执行逻辑的机制。⁶⁷

所以例如相当适合以下这些项目。

界面数量多的业务应用
列表、详情、编辑、搜索、状态展示很多的场景
多人长期维护的 Windows 应用
想把 View 和逻辑分离开
将来改造时想先把外观和行为的职责分开
用 WinForms 做的话界面很快就会变得沉重

如果是全新的 Windows 专属业务应用还在犹豫， WPF 现在依然是相当安全的第一候选。用「WPF 太老了所以不行」这种理由直接否定它，有点粗暴。

毋宁说，

已经有现有的 WPF 资产
已经积累了 XAML / MVVM 相关的知识
还没到必须以 Fluent 为最高优先级的程度
但想比 WinForms 更精细地设计 UI

在这样的情况下，WPF 最合理，这种场景很常见。

当然 WPF 也有自己的脾气。

XAML 雕琢过头就会变得难读
一旦陷入自定义控件或模板地狱，维护成本就会变重
过度偏向「什么都用 Binding」这种教条，反而难以追踪

这些问题确实存在。不过，这不是 WPF 不好，而是表现力强的工具，一旦被粗暴地滥用，反噬也会更大这一类的话题。

WPF 也可以追加 Windows App SDK 的部分功能。也就是说，存在一条保持 WPF 不变、只把 Windows 功能现代化的路径。⁸¹⁰

因此，比起

全盘放弃 WPF，整体迁移到 WinUI

下面这种做法

把 WPF 迁移到现行 .NET 上
只用 Windows App SDK 补齐必要的 Windows 功能
大的新功能从一开始就重新规划结构

在实务中往往更容易赢。

5.3 WinUI

WinUI 是打造全新 Windows 专属应用时的现代首选。¹²

官方的定位是，

针对最新硬件和输入方式做了优化
高 DPI
流畅动画
是 Windows App SDK 的一部分

大致如此。¹

所以适合以下这类项目。

Windows 专属的全新产品
UI 给人的印象或体验本身就很重要
想自然地用上 Fluent
想贴近 Windows 11 当下的定位
想以新的窗口 API 或最新 Windows 体验为前提

真正有理由选 WinUI 的项目，大致是「不是单纯图外观新，而是想把 Windows 当下的体验融入产品」这类项目。

另一方面也有一些需要注意的地方。

5.3.1 WinUI 不是「只是新版的 WPF」

因为都用 XAML，看起来很像，但

底层 API
控件生态
项目结构
部署 / 打包的思路
与 Windows App SDK 的相处方式

都不一样。

也就是说，把它当成从 WPF 轻松换过去的目标有点危险。

5.3.2 选 WinUI，发布问题会提前跑到台面上

WinUI 3 应用默认以 packaged（打包）形式为主。另一方面，Windows App SDK 本身能同时处理 packaged / unpackaged 两种形式。¹³¹⁴²

这里重要的是，

打算怎么发布
怎么部署到运行环境
是否需要 package identity
走企业内部发布、Store、MSIX，还是走现有的 EXE / MSI 路线

最好尽早决定下来。

WinForms / WPF 的发布也很重要，但在 WinUI 这里，发布问题特别容易被提前推到台面上。明明以为只是在决定 UI，实际上却是在决定发布策略，这是这个领域稍微麻烦的地方。

5.3.3 「在现有 WPF / WinForms 里慢慢混入 WinUI」先做实验

这是期望容易被吹大的地方。但 Microsoft 的 FAQ 里也写明了，除非已经准备好彻底迁移 UI 框架，否则往往用不了 WinUI 这层意思。进一步说，XAML Islands 相关的官方文档虽然提示了往现有桌面应用中嵌入的路径，但 Windows App SDK 1.4 的发布说明里写着，目前阶段主要在 C++ 应用上做过测试，还没有为 WPF / WinForms 提供便捷的封装组件。¹⁰¹¹

也就是说，

「分阶段迁移好像可行」
「慢慢填进去好像没问题」

作为构想很有吸引力，但在把它当作项目主策略之前，最好先做小范围验证。

WinUI，

从零开始的全新项目
打造 Windows 专属产品的体验

时最有道理。反过来，把它当作现有 WPF / WinForms 的全面替代方案，则需要充分的理由和验证。

6. 常见的判断误区

6.1 「因为最新所以选 WinUI」

这个理由很好理解，但相当危险。

选择新技术的理由，最好用 是否具备只有这个技术才能带来的价值来判断。

现代 Windows 体验是不是产品价值所在
是否想自然地用上 Fluent
是不是全新产品
能不能接受发布 / 运维方面的前提条件

这些如果都是 yes，WinUI 就相当有优势。反过来，单纯因为「感觉更有前景」，这种成本上的解释就比较薄弱。

6.2 「想用 Windows App SDK 所以必须用 WinUI」

这一点很容易被误解，但其实不是这样。

Windows App SDK 也可以加到现有的 WPF / WinForms 里。官方 FAQ 也整理说明了，WPF / MFC / WinForms 应用可以使用与 WinUI 无关的 Windows App SDK API。¹⁰⁸⁹

例如，

App Lifecycle
Windowing
Toast 通知

这类功能，有时可以在保持现有 UI 不变的情况下引入进来。¹⁰

6.3 「WPF / WinForms 已经过时了」

这里同样最好不要一刀切地下结论。

WinForms 和 WPF 在现行 .NET 上都持续有文档和迁移引导，官方也把它们当作现役的 Windows 桌面 UI 来对待。³⁴

尤其在业务应用中，

现有资产
第三方控件
界面数量
报表或打印
设备联动
发布流程

比 UI 框架新不新更重要的情况很常见。

6.4 「反正都要全面重写」

全面重写不是一个技术选型问题，更接近一个业务判断。

如果已经有现有应用，最先该确认的是以下几点。

真正困扰的问题究竟是什么
是 UI 的问题，还是架构的问题
依赖的 DLL / COM / OCX / 报表 / 发布流程，是不是才是真正的重担
是不是不整体改 UI 就解决不了这个困扰

重写 UI 看起来很华丽，但成本也一样华丽。而且就算外观变新了，周边的麻烦通常还是留在原地。

6.5 「以后用 XAML Islands 应该能搞定」

这种期待可以理解。但从一开始就不要把它当成救生艇，会更安全一些。¹⁰¹¹

分阶段迁移的话，

想嵌入的控件到底是什么
焦点、输入、DPI、主题会变成什么样
那种宿主结构实际上是否稳定

最好先做小范围试验。

7. 以现有应用为前提时的思路

这里比起全新项目，现有应用更值得重视。

7.1 已经有现有 WinForms 的话

在直接跳到 WinUI 之前，先看以下几点。

能不能迁移到现行 .NET
是否需要做 64 位化
能不能把 async / await、异常处理、配置、日志梳理清楚
能不能通过界面拆分或 UserControl 化来提升可维护性
能不能只用 Windows App SDK 补齐必要的 Windows 功能

看起来像是 WinForms 的问题，实际上很多时候只是

界面和逻辑混在一起
线程边界划分粗糙
配置 / 文件 / COM / 数据库的职责挤在一起

而已。

这种情况下，就算搬到 WinUI，问题也只是换了个名字，照样留在那里。

7.2 已经有现有 WPF 的话

WPF 很容易复用现有资产，比如

XAML 资产
Binding
Style / Template
Command
MVVM

要放弃这些，理由应该相当明确才行。

例如，

想全面更新产品 UI
想以 Fluent 为主轴
把新模块作为独立产品切出去
作为 Windows 专属产品想贴近新的体验

这些可以成为考虑 WinUI 的理由。但如果理由只有「WPF 太老了」，就显得很单薄。

7.3 真正沉重的往往在 UI 之外

实务上真正痛苦的意外，往往就在这些地方。

ActiveX / OCX
COM interop
自定义报表
打印
Excel / Office 联动
原生 DLL
32 位 / 64 位之间的纠结
安装程序、权限、更新、签名

如果轻视这些方面，只把 UI 做得漂亮，整个项目也不会因此变轻松。

所以在现有应用的迁移过程中， 不能只看 UI 框架，最好先把依赖边界一并盘点清楚。

8. 犹豫不决时最后看的 5 个问题

如果最终还是拿不定主意，可以依次看下面这 5 个问题。

8.1 现有资产规模大吗

大 → 基本维持现有技术路线
小 / 没有 → 按全新项目来选型

8.2 这个应用「Windows 风格的现代体验」是必需的吗

必需 → WinUI 有优势
没到那种程度 → 确认 WPF / WinForms 是否已经足够

8.3 界面是以标准表单为主，还是需要 XAML 式的表现力

以标准表单为主 → WinForms
样式 / 模板 / Binding / MVVM 很重要 → WPF

8.4 想要的是 UI 的全面更新，还是 Windows 功能的追加

UI 全面更新 → 考虑 WinUI
只追加功能 → 先考虑现有的 WPF / WinForms + Windows App SDK

8.5 发布 / 更新 / 运维怎么做，能提前说清楚吗

还比较模糊 → WinUI 要尽早打磨 packaging / deployment 相关的设计
想紧密贴合现有运维体系 → WPF / WinForms 的摩擦往往更少

靠这 5 个问题，就能把范围相当程度地收窄。最后粗略整理一下，大致是这样的感觉。

想快速做出的企业内部表单 → WinForms
长期成长型的 Windows 业务应用 → WPF
全新的现代 Windows 产品 UI → WinUI
想复用现有资产、只把 Windows 功能现代化 → 现有框架 + Windows App SDK

9. 总结

WinForms、WPF、WinUI 的选型， 不是一场按新旧顺序排列、直接取最右边那个的游戏。

该优先看的是以下这 4 点。

现有资产在哪里
界面是以表单为主，还是以表现力为主
Windows 风格的现代 UI 是不是产品硬性需求
发布 / 更新 / 运维怎么落地

看清楚这 4 点之后，大致可以整理如下。

如果有大量现有 WinForms，优先继续用 WinForms
如果有大量现有 WPF，优先继续用 WPF
全新项目以标准表单为主的话选 WinForms
全新的中到大型 Windows 业务应用的话选 WPF
全新项目里现代 Windows 体验本身是硬性需求的话选 WinUI
只是想用 Windows App SDK 的话，不要一股脑全上 WinUI

最想避免的，是以下这 3 种想法。

因为旧就直接放弃
因为新就直接选
抱着中途总会有办法的心态直接开始

Windows 桌面这个领域，比起外观资产、发布、运维、依赖关系才是更重的部分。所以选型时，比起看起来光鲜与否，看摩擦够不够少通常更容易赢。

10. 参考资料

Microsoft Learn, “WinUI 3 - Windows apps” https://learn.microsoft.com/en-us/windows/apps/winui/winui3/ / Microsoft Learn, “Modernize your desktop apps for Windows” https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
Microsoft Learn, “Windows App SDK” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Microsoft Learn, “Windows Forms 是什么 - Windows Forms” https://learn.microsoft.com/en-us/dotnet/desktop/winforms/overview/ ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, “Windows Presentation Foundation 是什么 - WPF” https://learn.microsoft.com/en-us/dotnet/desktop/wpf/overview/ ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, “What is Windows Forms Designer?” https://learn.microsoft.com/en-us/visualstudio/designers/windows-forms-designer-overview?view=visualstudio ↩ ↩²
Microsoft Learn, “Data binding overview - WPF” https://learn.microsoft.com/en-us/dotnet/desktop/wpf/data/ ↩ ↩² ↩³
Microsoft Learn, “Commanding Overview - WPF” https://learn.microsoft.com/en-us/dotnet/desktop/wpf/advanced/commanding-overview ↩ ↩² ↩³
Microsoft Learn, “在 WPF 应用中使用 Windows App SDK” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/wpf-plus-winappsdk ↩ ↩² ↩³
Microsoft Learn, “Use the Windows App SDK in a Windows Forms (WinForms) app” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/winforms-plus-winappsdk ↩ ↩² ↩³
Microsoft Learn, “Windows 开发者 FAQ” https://learn.microsoft.com/en-us/windows/apps/get-started/windows-developer-faq ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹
Microsoft Learn, “Windows App SDK 1.4 release notes” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/release-notes/windows-app-sdk-1-4 / Microsoft Learn, “Windows App SDK” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/ ↩ ↩² ↩³
Microsoft Learn, “Windows data binding and MVVM” https://learn.microsoft.com/en-us/windows/apps/develop/data-binding/data-binding-and-mvvm ↩
Microsoft Learn, “Packaging overview - Windows apps” https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/packaging/ ↩
Microsoft Learn, “Quick start: Set up your environment and create a WinUI 3 project” https://learn.microsoft.com/en-gb/windows/apps/get-started/start-here ↩

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

WinUI 和 WPF 有什么区别？: 两者都用 XAML，看起来很像，但底层 API、控件生态、项目结构、部署与打包的思路、和 Windows App SDK 的关系都不一样，把 WinUI 当成「从 WPF 轻松换过去的目标」有点危险。WPF 是表现力强、综合均衡的 Windows 专用 UI 框架，适合中到大规模的业务应用；WinUI 是 Windows App SDK 上的现代 Windows 原生 UI，以 Fluent、高 DPI、最新 Windows 体验为前提，适合全新的 Windows 专属产品。
新项目该选 WinForms、WPF 还是 WinUI？: 全新的小到中型企业内部工具，如果以标准控件、录入界面为主并想快速做出来，WinForms 现在依然很能打。全新的中到大型业务应用，界面数量多、想好好利用数据绑定、样式、模板、MVVM 的话，WPF 大多数情况下最省心。全新的 Windows 专属产品，如果现代 Windows UI、Fluent、最新 Windows 体验直接关系到产品价值，WinUI 很有优势。如果存量资产规模大，还是先以延续原有技术路线为基本前提来考虑。
想用 Windows App SDK，就必须换成 WinUI 吗？: 不需要。Windows App SDK 和 WinUI 不是一回事：WinUI 是 Windows App SDK 的 UI 框架部分，但 Windows App SDK 本身也可以加到 WPF / WinForms / Win32 的现有应用里。官方 FAQ 也说明了 WPF / MFC / WinForms 应用可以使用与 WinUI 无关的 Windows App SDK API，例如 App Lifecycle、Windowing、Toast 通知这类功能，有时候可以在保持现有 UI 不变的情况下引入。
WPF 和 WinForms 已经过时了吗？: 不建议这么简单粗暴地下结论。WinForms 和 WPF 在现行 .NET 上都持续有文档和迁移指引，官方也把它们当作现役的 Windows 桌面 UI 来对待。尤其是业务应用中，存量资产、第三方控件、界面数量、报表或打印、设备联动、发布流程往往比 UI 框架新不新更重要。如果想在现有 WPF / WinForms 应用里分阶段混入 WinUI，官方 FAQ 也提到除非已经准备好彻底迁移 UI 框架，否则往往用不了 WinUI，所以在当成主策略之前最好先做小范围验证。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。

查看简介联系我们

公开链接

GitHub LinkedIn X COM_BLAS COM_BigDecimal

返回博客列表

Windows Forms、WPF、WinUI 该怎么选 - 新建项目、存量资产、发布、UI 表现力判断表

1. 先说结论（一句话）

2. 本文中提到的 3 个技术

3. 一页看懂的判断表

4. 按维度划分的对比表

5. 各自适合什么样的项目

5.1 WinForms

5.2 WPF

5.3 WinUI

5.3.1 WinUI 不是「只是新版的 WPF」

5.3.2 选 WinUI，发布问题会提前跑到台面上

5.3.3 「在现有 WPF / WinForms 里慢慢混入 WinUI」先做实验

6. 常见的判断误区

6.1 「因为最新所以选 WinUI」

6.2 「想用 Windows App SDK 所以必须用 WinUI」

6.3 「WPF / WinForms 已经过时了」

6.4 「反正都要全面重写」

6.5 「以后用 XAML Islands 应该能搞定」

7. 以现有应用为前提时的思路

7.1 已经有现有 WinForms 的话

7.2 已经有现有 WPF 的话

7.3 真正沉重的往往在 UI 之外

8. 犹豫不决时最后看的 5 个问题

8.1 现有资产规模大吗

8.2 这个应用「Windows 风格的现代体验」是必需的吗

8.3 界面是以标准表单为主，还是需要 XAML 式的表现力

8.4 想要的是 UI 的全面更新，还是 Windows 功能的追加

8.5 发布 / 更新 / 运维怎么做，能提前说清楚吗

9. 总结

10. 参考资料

将 .NET Framework 迁移到 .NET 之前该确认的事 - 动手前就决定成败的实战检查清单

PeriodicTimer / System.Threading.Timer / DispatcherTimer 怎么选 - 先理清 .NET 的定期执行

Windows 什么时候需要管理员权限 - UAC、保护区域与设计上的辨别方式

Windows 应用程序不要把敏感信息以明文存进配置文件的最佳实践

Windows 网卡高级设置详解 - Jumbo Packet、RSS、LSO、RSC、Flow Control、EEE、Wake on LAN 到底怎么设置

常见问题

作者简介

Go Komura

1. 先说结论（一句话）

2. 本文中提到的 3 个技术

3. 一页看懂的判断表

4. 按维度划分的对比表

5. 各自适合什么样的项目

5.1 WinForms

5.2 WPF

5.3 WinUI

5.3.1 WinUI 不是「只是新版的 WPF」

5.3.2 选 WinUI，发布问题会提前跑到台面上

5.3.3 「在现有 WPF / WinForms 里慢慢混入 WinUI」先做实验

6. 常见的判断误区

6.1 「因为最新所以选 WinUI」

6.2 「想用 Windows App SDK 所以必须用 WinUI」

6.3 「WPF / WinForms 已经过时了」

6.4 「反正都要全面重写」

6.5 「以后用 XAML Islands 应该能搞定」

7. 以现有应用为前提时的思路

7.1 已经有现有 WinForms 的话

7.2 已经有现有 WPF 的话

7.3 真正沉重的往往在 UI 之外

8. 犹豫不决时最后看的 5 个问题

8.1 现有资产规模大吗

8.2 这个应用「Windows 风格的现代体验」是必需的吗

8.3 界面是以标准表单为主，还是需要 XAML 式的表现力

8.4 想要的是 UI 的全面更新，还是 Windows 功能的追加

8.5 发布 / 更新 / 运维怎么做，能提前说清楚吗

9. 总结

10. 参考资料

相关文章

将 .NET Framework 迁移到 .NET 之前该确认的事 - 动手前就决定成败的实战检查清单

PeriodicTimer / System.Threading.Timer / DispatcherTimer 怎么选 - 先理清 .NET 的定期执行

Windows 什么时候需要管理员权限 - UAC、保护区域与设计上的辨别方式

Windows 应用程序不要把敏感信息以明文存进配置文件的最佳实践

Windows 网卡高级设置详解 - Jumbo Packet、RSS、LSO、RSC、Flow Control、EEE、Wake on LAN 到底怎么设置

常见问题

作者简介

Go Komura