WinUI 去掉了"3"——微软终于说清楚：Windows 原生应用才是正途

Build 2026 上，微软软件工程副总裁 Chris Anderson 说了一句开发者等了多年的话："我们无意构建新框架。"伴随这句话落地的还有一个更直观的变化——WinUI 3 的品牌名称正式被放弃，今后只叫 WinUI。

少一个数字，多一份确定性。

从 WinUI 3 到 WinUI：不只是改名

过去几年，Windows 原生 UI 框架的命名一直在变：WinUI 2 是 UWP 时代的 XAML 控件库；WinUI 3 被包装成"Windows App SDK 里的下一代 UI 框架"，和 App SDK 的版本号绑在一起，让开发者搞不清自己到底在用什么。每次有人问"WinUI 3 和 WinUI 2 有什么关系"，回答都绕不开一段历史课。

这次改名本质上是微软在说：别再等新框架了，这就是我们要长期维护的那一个。 WinUI 不再是"实验性的第 3 版"，而是 Windows 原生 UI 的正式品牌。Anderson 的表态进一步锁定了路线——不会再来一次"从零开始"，现有框架会持续演进。

为什么"原生而非 Web 封装"值得认真听

微软这番表态的背景是：过去几年，Electron、Tauri、WebView2 封装方案把大量桌面应用变成了"套壳 Web 应用"。好处显而易见——跨平台、前端生态直接复用、开发速度快。但代价也很真实：

• 内存占用高：每个 Electron 窗口自带一个 Chromium 实例，十个窗口就是十个渲染进程。
• 启动延迟：Web 引擎初始化需要时间，冷启动体验很难追上原生。
• 系统集成浅：通知、文件系统、剪贴板、窗口管理，每一层都要写桥接代码，桥接代码就是维护负担。

Anderson 的判断是：如果你的应用主要跑在 Windows 上，原生框架能给你更好的性能、更深的系统集成、更小的安装包。WinUI 就是那个框架。

用 WinUI 写一个最小窗口应用

下面用一个完整可运行的项目演示 WinUI（原 WinUI 3 / Windows App SDK）的开发流程。前提：你已安装 Visual Studio 2022 并勾选了"Windows Application Development"工作负载，或者用 .NET CLI + Windows App SDK 项目模板。

步骤一：创建项目

# 使用 .NET CLI 创建一个 WinUI 桌面应用（需要安装 Windows App SDK 项目模板）
dotnet new winui -n MinimalWinUIApp -o MinimalWinUIApp

cd MinimalWinUIApp

如果你用的是 Visual Studio，新建项目时选择 WinUI App in .NET（不是 UWP 版本）。

步骤二：最简 MainWindow.xaml

打开 MainWindow.xaml，替换为以下内容：

<Window
    x:Class="MinimalWinUIApp.MainWindow"
    xmlns="http://schemas.microsoft.com/winui/2004/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winui/2004/xaml">

    <StackPanel Orientation="Vertical" HorizontalAlignment="Center"
                VerticalAlignment="Center" Spacing="12">

        <TextBlock Text="WinUI 原生窗口" Style="{StaticResource TitleTextBlockStyle}" />

        <TextBox x:Name="InputBox" PlaceholderText="输入点什么..."
                 Width="300" />

        <Button Content="确认" Click="OnConfirmClick" />

        <TextBlock x:Name="ResultText" Style="{StaticResource BodyTextBlockStyle}" />
    </StackPanel>
</Window>

步骤三：对应的后端代码

在 MainWindow.xaml.cs 中：

using Microsoft.UI.Xaml;

namespace MinimalWinUIApp;

public sealed partial class MainWindow : Window
{
    public MainWindow()
    {
        this.Title = "最小 WinUI 应用";
        // 设置窗口初始大小
        this.AppWindow.Resize(new global::Windows.Graphics.SizeInt32(480, 320));
    }

    private void OnConfirmClick(object sender, RoutedEventArgs e)
    {
        ResultText.Text = $"你输入了：{InputBox.Text}";
    }
}

步骤四：运行

dotnet run

你会看到一个原生 Windows 窗口弹出，标题栏是系统原生渲染，控件风格跟随 Windows 11 的 Fluent Design——圆角、微妙阴影、系统主题色自动适配。没有 Chromium 进程，没有 WebView 桥接，内存占用在 30–50 MB 级别（对比 Electron 空窗口通常 150 MB+）。

原生路线的现实边界

微软把话说清楚了，但开发者做选择时仍要权衡几个问题：

如果你的产品只跑在 Windows 上、对启动速度和内存敏感、需要深度调用 Windows API（通知中心、剪贴板历史、窗口管理器集成），WinUI 是合理选择。如果你团队全是前端工程师、产品必须同时发 Mac 版，Web 封装仍然更务实。

迁移检查清单

如果你正在考虑从 Web 封装方案转向 WinUI，可以按这个顺序推进：

1. 确认平台范围：产品是否只需要支持 Windows？如果必须跨平台，WinUI 不适合单独承担。
2. 盘点系统 API 依赖：列出你当前通过桥接调用的 Windows API，逐条检查 WinRT 是否有直接对应——大部分有，少数可能需要用 P/Invoke 补位。
3. 评估团队技能：XAML + C# 的学习曲线对前端团队来说不算陡峭，但需要时间。可以先让一两个人做原型验证。
4. 从小窗口开始：先用 WinUI 做一个独立工具窗口或设置面板，跑通发布流程，再决定是否全面迁移。
5. 关注 Windows App SDK 版本：微软已明确不再另起炉灶，但 SDK 版本迭代节奏仍需跟踪。建议锁定 1.6+ 稳定版作为起步基线。

微软这次表态的意义不在于技术本身有多新——WinUI 的控件和 API 和之前的 WinUI 3 大体一致。意义在于方向锁定了：不再摇摆，不再暗示"可能还有下一个框架"。对已经观望多年的 Windows 原生开发者来说，这总算是一个可以放心投入的信号。