LLLXY

Microsoft.UI.Reactor - 使用 MVU 开发 WinUI 应用

10/23/2026 13:56:38 | China Standard Time

Microsoft.UI.Reactor 是微软在 WinUI 上验证 MVU 模型的实验性框架，界面以纯 C# 描述，不再依赖 XAML 与 MVVM。本文讨论其渲染与状态更新机制、工具链能力，以及框架处于实验性阶段时的工程取舍。

# Microsoft.UI.Reactor - 使用 MVU 开发 WinUI 应用

## 一个跑在真实控件上的 MVU 运行时

WinUI 的编程模型这些年基本定型：XAML 描述结构，code-behind 挂事件，ViewModel 持状态并通过 `INotifyPropertyChanged` 通知界面。Microsoft.UI.Reactor 换掉的是"界面怎么描述"和"状态放在哪里"，没有换平台。它不带新渲染器，也不是谁的 fork：写 `Button`、`TextBox`、`NavigationView`、`TreeView`，物化出来的是真正的 WinUI 控件，由同一套布局面板、同一套主题资源、同一套 UIA 检查工具处理。

它加进来的东西有三样：一棵可以 diff 的虚拟元素树（element records）、一套与渲染逻辑同处的 hook 状态、一个用类型化工厂方法替代标记语言的 C# DSL。MVU（Model-View-Update，模型-视图-更新）在其中的落点很朴素——状态集中持有，更新函数据此算出下一个状态，视图是状态的纯函数。Elm 把这个模式做成了范式，React、SwiftUI、Jetpack Compose 是它在不同平台上的变体。

MVU 与 MVVM 不是新旧关系。MVVM 要解决的是"状态如何被观察并推送到控件"，MVU 要解决的是"界面如何由状态推导出来"。前者是一条常驻的推送管道，后者是一次次纯函数求值，再把结果折到已有控件上。WinUI 现在两条路都能走。

还有一条边界需要先划清：Reactor 不替代 XAML，也不替代 MVVM。XAML 没有进入维护模式，设计器、模板、第三方控件生态照旧，WinUI 的日常开发正搬到 `microsoft/microsoft-ui-xaml` 公开进行。两种模型并存，同一进程、同一棵视觉树里可以互操作。

## 十二行写完一个应用

一个完整的 Reactor 程序，连包引用和编译属性都在同一个文件里：

```csharp
#:package Microsoft.UI.Reactor@0.1.0-preview.16
#:property OutputType=WinExe
#:property TargetFramework=net10.0-windows10.0.22621.0
#:property UseWinUI=true

using Microsoft.UI.Reactor;
using Microsoft.UI.Reactor.Core;
using static Microsoft.UI.Reactor.Factories;

ReactorApp.Run<MyApp>("Hello Reactor", width: 340, height: 200);

class MyApp : Component
{
    public override Element Render()
    {
        var (count, setCount) = UseState(0);

return VStack(
            TitleBar("Hello Reactor"),
            VStack(12,
                Heading($"Count: {count}"),
                HStack(8,
                    Button("-", () => setCount(count - 1)),
                    Button("+", () => setCount(count + 1))
                        .AccentButton()
                )
            ).Padding(24)
        ).Backdrop(BackdropKind.Mica);
    }
}
```

存为 `counter.cs`，直接运行：

```bash
winapp run counter.cs
```

窗口里有真正的 TitleBar、TextBlock 和两个按钮，计数器可用。

顶部 `#:` 开头的是 .NET 10 的 file-based apps：包引用和 MSBuild 属性写在源文件里，`OutputType=WinExe`、`TargetFramework=net10.0-windows10.0.22621.0`、`UseWinUI=true` 都由这几行决定。这让"试一下"的成本接近脚本语言。一旦要正式做，就换成普通工程，Reactor 代码本身不变。

`MyApp` 继承 `Component`，唯一必须实现的是 `Render()`。它没有字段保存 `count`——状态在 `UseState(0)` 这个 hook 里，返回"当前值 + 设置器"的元组，形状与 React 完全一致。`VStack`、`HStack`、`Button`、`TitleBar` 来自 `static using ...Factories`；`.Padding(24)`、`.AccentButton()`、`.Backdrop(BackdropKind.Mica)` 是链式修饰符。整段不是新语言，就是普通 C# 表达式，IntelliSense、重命名、跳转定义全部照常工作。

`winapp run` 依赖 Windows App SDK 的 CLI（v0.7.0 起支持直接跑 `.cs` 文件）。它负责脚手架、包标识、MSIX 打包与签名，面向所有 Windows 框架。想留在 `dotnet` 里也能跑，`dotnet run counter.cs -a x64 -p:WindowsAppSDKSelfContained=true`，但那是无包标识的普通桌面应用。装 CLI 与生成正式工程分别是：

```bash
winget install Microsoft.WinAppCli
```

```bash
winapp new -t reactor -n MyApp
cd MyApp
winapp run
```

脚手架生成的工程带 `Package.appxmanifest`、assets 和发布配置，Debug 构建还会带上 Reactor devtools。模板有四个（`reactor`、`reactor-mvu`、`reactor-navview`、`reactor-tabview`），全部是实验性的。

## 同一屏的 XAML 版本

对比要公平，否则框架会背上它不该背的名声。XAML 版本按熟练开发者真实会写的方式：`x:Bind` 加 MVVM Toolkit 源生成器。

最少五个文件加一个工程：窗口标记、code-behind、ViewModel、`App.xaml` 与 `App.xaml.cs` 做启动，再加 `.csproj`。核心的三个是这样：

```xml

<Window x:Class="CounterApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Hello XAML">
    <Window.SystemBackdrop>
        <MicaBackdrop />
    </Window.SystemBackdrop>
    <StackPanel>
        <TitleBar x:Name="AppTitleBar" Title="Hello XAML" />
        <StackPanel Spacing="12" Padding="24">
            <TextBlock Text="{x:Bind ViewModel.CountText, Mode=OneWay}"
                       Style="{StaticResource TitleTextBlockStyle}" />
            <StackPanel Orientation="Horizontal" Spacing="8">
                <Button Content="-" Command="{x:Bind ViewModel.DecrementCommand}" />
                <Button Content="+" Command="{x:Bind ViewModel.IncrementCommand}"
                        Style="{StaticResource AccentButtonStyle}" />
            </StackPanel>
        </StackPanel>
    </StackPanel>
</Window>
```

```csharp
// MainWindow.xaml.cs
public sealed partial class MainWindow : Window
{
    public CounterViewModel ViewModel { get; } = new();

public MainWindow()
    {
        InitializeComponent();
        ExtendsContentIntoTitleBar = true;
        SetTitleBar(AppTitleBar);
    }
}
```

```csharp
// CounterViewModel.cs
public partial class CounterViewModel : ObservableObject
{
    [ObservableProperty]
    [NotifyPropertyChangedFor(nameof(CountText))]
    public partial int Count { get; set; }

public string CountText => $"Count: {Count}";

[RelayCommand] private void Increment() => Count++;
    [RelayCommand] private void Decrement() => Count--;
}
```

这是好的 XAML。源生成器把当年让 MVVM 出名的样板基本抹平了：`INotifyPropertyChanged` 由 `ObservableObject` 提供，`ICommand` 由 `[RelayCommand]` 生成，变更通知交给 `[ObservableProperty]`。但有几件事没有变：

一个整数要穿过三个文件和两种语言才到达像素。`{x:Bind ViewModel.CountText, Mode=OneWay}` 是一段要被 XAML 编译器解析、再生成代码去跟进的标记文本；在 C# 里改掉属性名，生成代码能否跟上，取决于工具链有没有正确重写它。状态住在一个类里，而这个类存在的全部理由就是"被观察"。"Count 等于 5 时这一屏长什么样"这个问题，答案要靠读三个文件、再在脑子里跑一遍绑定引擎。

Reactor 对这个问题的回答很无趣：读 `Render()`。它是个函数，给一个 count，返回一个界面。

真正的分歧不在文件数量，而在因果方向。MVVM 是状态变化触发通知、绑定把新值推给控件属性，是一条持续运行的管道；MVU 是状态变化后重算整棵描述树、与新树比较、只把差异打到控件上，是一次纯函数的重复求值。前者的失败模式是运行时的静默失配，后者的失败模式是渲染不纯导致的循环与错位。

## 渲染管线：从 element record 到控件树

### 状态存在 slot 里

`Component` 的每次 `Render()` 都走同一个 `RenderContext`，hook 状态按调用顺序编号存在 slot 表里。`setCount` 写入 slot，context 向宿主请求一次重渲染。整个过程没有 `INotifyPropertyChanged`，也没有谁在监听属性。可用 hook 的集合是：`UseState`、`UseReducer`、`UseEffect`、`UseMemo`、`UseRef`、`UseCallback`、`UseContext`、`UseObservable`、`UseCollection`。

顺序是硬约束。hook 必须无条件、同序调用：在 `if` 里放一个 `UseState`，分支翻转后 slot 索引整体错位，下一次渲染在 slot N 上期待 `UseEffect`，读到的却是 `UseState`。`REACTOR_HOOKS_001`、`REACTOR_HOOKS_002`、`REACTOR_HOOKS_005` 抓的就是这类问题。这条约束不是风格问题，是按序号寻址的直接后果。

### 一次渲染做了什么

流向是单向的：setter 写 slot，请求重渲染，`Render()` 产出新树，reconciler 同步遍历新旧两棵树，把差异写到已有的 WinUI 控件上。没有任何东西在 pull。元素节点是值语义的不可变 record，一次渲染就是堆上的一棵新树，旧树在 diff 结束的那一刻变成垃圾。

reconciler 是唯一的写入者，它做四件事：

- keyed diff。列表比对用最长递增子序列，重排时移动的控件数量最少。
- 元素池化。`Button`、`TabView`、`ItemsRepeater` 这类重对象跨渲染租借与归还，不重建。
- 渲染合并。同一帧内的多次 setter 合并成一次渲染。
- 跳过未变化子树。`Component` 的 `ShouldUpdate()` 默认为 `false`，无参组件不会因为父组件重渲染而跟着重算。

副作用被安排在提交之后：`UseEffect` 在 reconciler 写完属性后才触发，所以 effect 里观察到的界面就是屏幕上的界面。

`Render()` 的纯度因此不是代码风格问题，而是运行时正确性前提：渲染里写状态会形成循环，发请求会每帧重复，读外部可变状态会让 diff 失去意义。这是五条核心规则之一，另外四条是 hook 顺序稳定、列表有稳定 key、setter 与 deps 稳定、主题用 token 而不是字面量。

### 一个容易误解的点

Reactor 并没有摆脱依赖属性。它物化的每个控件照样有 DP，照样由 reconciler 写入。消失的是监听 ViewModel 并主动取值的那条 `BindingExpression`。如果在 Reactor 拥有的控件上再挂一个 `{Binding}`，就造出一条 reconciler 不知道的响应式边，下一轮 diff 会把你的写入覆盖掉。

同理，别在 Reactor 之外长期缓存控件引用。控件可能在元素被替换时归还到池子、剥掉 element tag，再被树的另一处租走，你手里那个引用指向的已经是个被复用的对象。需要访问控件就通过 `UseElementRef`，在 effect 里读 `.Current`。

## 编译期能拿到什么

类型安全替代字符串路径。`{Binding Foo}` 写错要到运行时才报，`StaticResource` 键名拼错要到界面空白才发现；在 Reactor 里属性访问就是属性访问，重命名会改掉所有使用点，因为没有第二套引用语法。

analyzer 是收益最大的一块。随包发布的 Reactor 专用 Roslyn 规则有 60 多个，覆盖 hook 用法、可访问性、主题、commanding、性能。它们抓的是机械上可检测、但在标记语言里看不见的问题：列表项漏了 key、hook 写在 `if` 里、硬编码画刷在暗色模式下失效、只有图标的按钮被读屏软件念成"button"。反馈延迟是敲下字符后的几秒，而不是发版前几周。需要说明的是仓库 README 的成熟度表里，同一项记的是 40+，两个数字口径不一致，确切数目以 `src/Reactor.Analyzers` 的规则清单为准。

内置能力的覆盖面比"少写几个文件"实在得多：flexbox 布局来自 Meta Yoga 引擎的 C# 移植（README 记载 590 个移植测试夹具）、commanding（标签、图标、快捷键、动作打包成一条命令定义）、导航、主题 token、本地化（ICU 消息格式）、`DataGrid` 与 `PropertyGrid`、Visual Studio 风格的 docking（标签撕离、跨窗口停靠、浮动面板、布局序列化）、以及基于 D3 算法移植的 charting。

工具链的完整度也超出"实验项目"的预期：`mur` CLI 提供脚手架、did-you-mean 检查与 `mur doctor`；`dotnet watch` 下热重载在多数修改中能保住应用状态，因为状态本来就在 hook slot 里，重建组件不等于丢状态；VS Code 扩展提供并排的实时预览；Visual Studio 的嵌入式预览 VSIX 存在，但仓库自己标注它是全仓最粗糙的表面。

## 与 React、SwiftUI、Compose 的模型差异

把四个框架放在一起，差异在"状态如何被追踪、重算范围如何界定"。

React 是 hooks 加显式 setter，重渲染由调用触发，代价靠 `memo`、`useMemo` 和 key 手动控制。Reactor 与它几乎一一对应，`UseState`、`UseMemo`、`UseCallback` 连拼写都只差首字母大小写，区别是把 JSX 换成方法链。对 React 背景的人学习曲线接近零，但同样的坑也一并继承：闭包捕获旧值、deps 数组写漏、key 不稳定。

SwiftUI 走另一条路：`@State`、`@Binding` 加框架侧依赖追踪，视图是 struct，框架自己知道哪个视图读了哪个属性，只重算受影响的子树。Reactor 没有自动依赖追踪，它是显式 hook 加全量 `Render()`，靠 diff、池化、跳过未变化子树控制成本。写过 SwiftUI 的人会觉得它更手动，也更容易顺着代码读清哪次渲染由哪次 setter 引起。

Compose 在思想上最近：`@Composable` 函数、重组、跳过未变化的组。区别在手段。Compose 靠 Kotlin 编译器插件和 slot table 界定重组作用域，Reactor 不改编译器，它用 Roslyn analyzer 在编辑期约束写法。取舍很清楚：侵入性低，代价是一部分正确性只能靠静态检查保证，而不是语言机制。

对 .NET 开发者，最准确的描述是：它不像一门新语言，像一个类型安全、带 IntelliSense 的 Fluent API。这既是优点也是天花板——表达力受 C# 语法约束，嵌套一深，括号就开始难看。DSL 在规模上是否可读，是这套设计绕不过去的未知数：十二行很好看，四百行的界面呢。语法仍在与 C# 语言团队一起调整，这也是它还把实验标签挂着的原因之一。

## 实验性标签的具体含义

官方定位写得很直白：没有支持策略，没有 API 保证。实验标签还会挂上几个月，没有给出更具体的时间承诺。

落到工程上，这意味着 API 形状会变。DSL 语法可能调整，控件可能增删，分层可能重组，所有区域都在 pre-1.0，公开 API 可能无预警变更。

仓库用三档标注成熟度，标准是测试广度与 API 变动概率，不是功能完整度：

- Preview：核心 reconciler、DSL 与 elements、hooks、flex 布局、commanding、charting、markdown。
- Draft：导航、可访问性、动画、主题与样式、列表虚拟化、输入手势、docking、WinForms interop、DevTools、`mur` CLI 与 analyzer。主路径可用，边角粗糙，AOT 支持不全。
- Early：本地化、数据系统、异步资源、Shell 集成、Win2D canvas、控件包装生成器、预览与热重载。能用，但形态还会大改。

实验性不等于玩具。全部代码在 MIT 许可下公开，包括框架、设计规格、示例应用、完整测试套件、CLI、analyzer 和 VS Code 扩展；从第一次提交就是公开的，没有藏着"真正工作"的内部分支。测试规模到 2,200 个以上，其中 590 个是 Yoga 移植夹具。Rust 侧有并行实验 `windows-reactor`，在 crates.io 上发布 0.100.0，许可为 MIT OR Apache-2.0，模型独立但落到同一批原生控件上。

生产用例要分开看。OpenClaw 的 Windows 客户端在生产中默认启用 Reactor 跑聊天，这是"它能撑住真实负载"的存在证明，不是支持承诺。

## 存量项目怎么算这笔账

### 维护成熟的 XAML/MVVM 产品

什么都不用做。XAML 没有被废弃，Reactor 也没有提供自动迁移路径，只提供同进程的双向互操作：XAML 宿主里可以放 Reactor 内容，Reactor 应用里也可以嵌 XAML。缺控件时，任何其他 WinUI 控件——第三方的或自写的——都能包成 element 当内置控件用，`[GenerateReactorWrapper]` 源生成器能自动生成工厂方法、描述符和双向属性。真要试水，挑一个边缘窗口或内部工具页做三个月就够。

### 开全新的 Windows 桌面项目

吸引力是真实的：文件少、绑定安全、布局与数据网格内置、可访问性有诊断、跑在同一运行时上。但要先确认三件事：第三方控件能否包成 element；设计交付是否依赖 XAML 设计器（Reactor 侧提供的是代码编辑加实时预览，没有对应的设计器）；团队能否接受 API 变更。前两项任一为"是"，就该留在 XAML。

### 团队里有 React 或 Compose 背景的人

这是收益最高的场景。他们的心智模型已经是"UI 是状态的函数"，Reactor 只是把 JSX 换成 C# 方法链。反过来，让一个纯 WPF 团队切过来，难点不在语法，而在放弃"setter 里顺手做事"的习惯、接受渲染纯度、重新划状态边界。

### 状态边界要提前想清楚

组件级 hook 在简单界面上很舒服；复杂主窗口如果把状态全提到顶层，`Render()` 会长得难以维护。这时需要 `UseReducer` 管动作、`UseContext` 做跨层共享——依赖注入也走 Context：在根部提供，下面任何组件都能读。

MVVM 里被诟病的 ViewModel 并没有消失。它的职责被拆到了 reducer、context 和"状态放在树的哪一层"这个设计决策上。少了样板，多了判断。

## 判断

路线是自洽的。它没有重新发明 UI 平台，只换了描述方式与状态模型，因此能完整复用 WinUI 的控件、主题和辅助功能设施。这是它相比 Avalonia、Uno 这类"另一套 UI 栈"最大的优势。全量重算加 diff 在桌面端已被 React Native 和 Compose 验证；额外的工作是把差异落到真实 WinUI 控件上而不重建控件树。

真正的价值可能不在 Reactor 本身，而在它作为试验田的角色。charting、可访问性校验、commanding、flex 布局、主题 token 若在 Reactor 里被验证并回流 WinUI，所有 XAML 用户都受益。即使永远不写一行 Reactor，这个项目的进展也值得跟着看。

风险同样具体。最大的不确定性不是技术，而是承诺：实验期结束后，它是独立演进、并入 WinUI，还是安静归档？这几个月的窗口只覆盖设计迭代，不覆盖产品级支持。其次才是表达力上限——C# 方法链的嵌套可读性，如果需要语言层面支持才能解决，那就不是框架自己能决定的。第三是没有设计器，视觉驱动的团队要重建工作流。

所以建议是：花一个下午把 `counter.cs` 跑起来，再花一天写一个 `DataGrid` 加 `NavigationView` 的小工具。两天就能判断它契不契合你的思维方式，比读十篇分析都准。但不要把现有产品的路线图押上去，也不要因为"微软出品"就假定它一定 GA。

## 参考链接

- 发布公告：<https://devblogs.microsoft.com/ifdef-windows/microsoft-ui-reactor-a-c-first-way-to-build-winui-apps/>
- 项目仓库（MIT）：<https://github.com/microsoft/microsoft-ui-reactor>
- 文档：<https://microsoft.github.io/microsoft-ui-reactor/latest/>
- 架构总览：<https://microsoft.github.io/microsoft-ui-reactor/latest/architecture-overview/>
- Rules of Reactor：<https://microsoft.github.io/microsoft-ui-reactor/latest/rules-of-reactor/>
- Reactor vs XAML：<https://microsoft.github.io/microsoft-ui-reactor/latest/reactor-vs-xaml/>
- analyzer 架构：<https://microsoft.github.io/microsoft-ui-reactor/latest/analyzer-architecture/>
- VS 扩展预览：<https://microsoft.github.io/microsoft-ui-reactor/latest/vs-extension/>
- NuGet 包：<https://www.nuget.org/packages/Microsoft.UI.Reactor>
- crates.io 上的 Rust 实验：<https://crates.io/crates/windows-reactor>
- WinUI 仓库：<https://github.com/microsoft/microsoft-ui-xaml>
- winapp CLI：<https://github.com/microsoft/winappcli>