微软试验纯 C# 原生 Windows 界面框架

Windows 11 应用想摆脱「网页套壳」，光喊原生体验还不够，还得让开发者愿意写。IT之家 10 月 23 日援引 Windows Latest 报道，微软正在推进实验性 C# 框架 Microsoft.UI.Reactor：直接渲染 WinUI 控件，让开发者不用先学 XAML 就能构建界面。

它值得程序员关注的地方，是微软试图用更低的学习门槛、更及时的反馈，把开发者引向原生应用。不过，降低开发门槛能否换来更低的内存占用，报道还没有给出实测答案。

不写 XAML，为什么仍然是原生界面

Reactor 的关键，是用 C# 描述界面，直接渲染 WinUI 控件和基础组件。开发者不必先学习 XAML 标记语言及其绑定引擎，就能开始搭建 Windows 界面。

这里要分清两件事：用什么语言描述界面，以及最终由什么组件呈现界面。Reactor 改变了前者，底层仍然使用 WinUI 原生控件。

用 C# 写界面，不等于把网页装进桌面窗口。

微软希望借此吸引来自 Android、macOS，以及熟悉 React、React Native、SwiftUI、Jetpack Compose 的开发者。这些读者可能更容易接受用代码描述界面的方式，但报道没有说明 Reactor 是否兼容相关生态，也没有给出组件复用或迁移方案。

对前端开发者而言，可以把它理解成一个新的 Windows 原生界面入口。熟悉 React 可能有助于理解开发思路，却不能据此认定现有 React 项目可以直接迁过去。

从文件数量到即时反馈，微软想降低哪些成本

微软给出的例子很直观：一个原本需要五个文件加一个项目文件的 XAML 示例应用，使用 Reactor 后，可以压缩为一个 C# 文件。

这至少说明，在这个示例里，开发者需要处理的文件更少。不过，报道没有提供示例规模和完整项目结构，不能把它外推成大型应用也应该集中到单个文件。

另一项能力是编辑反馈。Reactor 能在多数编辑操作后保留应用状态，让开发者即时查看修改效果。调界面时，如果每次修改都要重新进入页面、恢复输入，反馈成本就会不断累积。保留状态的价值正在这里，但「多数编辑操作」具体包括哪些，原文没有展开。

框架还内置了 60 多项代码检查，覆盖深色模式、无障碍和性能等问题。例如，检查硬编码画刷是否会在深色模式下失效，以及图标按钮是否缺少有效说明，导致屏幕阅读器只读出「按钮」。

这类检查也契合 AI 编程场景：代码能生成、界面能显示，并不代表交互细节合格。微软希望结合 AI 编程工具，让更多开发者和非专业开发者构建原生 Windows 应用。不过，原文没有给出 AI 参与后的开发效率或质量对照数据。

我的判断

我认同微软把开发门槛作为切入点。想让团队选择 WinUI，需要同时考虑学习成本、修改反馈和常见问题检查，不能只强调原生体验。

但报道里的内存问题，需要单独看待。文中提到，Windows 11 天气应用曾通过 WebView2 加载 MSN 内容，内存占用超过 1GB。这是一个具体案例，不能据此判定所有 Electron 或 WebView2 应用都有相同表现，更不能证明使用 Reactor 后会节省多少内存。

Reactor 降低了原生界面的编写门槛，性能收益仍需实际项目验证。

和 Electron、WebView2 相比，Reactor 提供的是直接使用 WinUI 控件的路径；已有 Web 界面如何复用、其他平台如何覆盖，报道没有交代。微软提出的「100% 原生应用」是目标，也不能理解为 Windows 11 应用已经完成全面替换。

此外，它仍是实验性框架。原文没有提供稳定版本号、兼容性承诺或生产项目数据。目前更适合把它看作值得观察和试验的方向，而不是已有方案的确定替代品。

能拿来做什么

• 如果正在评估 Windows 桌面应用，可以选择一个包含表单、列表和图标按钮的小页面试做，同时观察开发成本、深色模式和屏幕阅读器表现。
• 如果现有 Electron 或 WebView2 应用内存偏高，先定位具体页面、内容和进程的占用，再判断是否需要迁移；不要把天气应用超过 1GB 的案例当成自己的性能结论。
• 使用 AI 编写界面时，可以直接借鉴文中的检查点：避免硬编码颜色，为图标按钮提供可读说明，并验证修改代码后应用状态能否正确保留。