Uno Platform、Blazor与MAUI用于WPF迁移的对比及相关问题咨询

1. WPF代码与XAML复用率问题 #

• 现有WPF的C#业务逻辑复用率和Blazor WASM方案基本一致，几乎可以100%保留，这部分和你之前验证的Blazor方案没有差异。
• XAML的复用率属于部分复用：Uno Platform的XAML语法对齐UWP/WinUI 3标准，和WPF的XAML有70%~80%的重合度，基础布局控件（Grid、StackPanel、Border）、数据绑定、样式触发器的写法基本通用，但WPF特有的控件（比如DataGrid的部分原生API、DocumentViewer、部分自定义路由事件实现）需要调整，如果你原来的WPF项目用到了大量WPF专属第三方控件，这部分XAML的重写比例会更高。

2. CSS灵活性问题 #

迁移到Uno不会丧失组件设计层面的CSS灵活性：Uno的WASM渲染最终会把XAML控件转换成标准DOM元素，你可以直接给Uno控件添加CssClass属性绑定自定义CSS样式，也可以用全局CSS覆盖对应DOM元素的默认样式，自定义程度和纯Blazor开发没有本质区别。

3. WASM端动态生成XAML的支持 #

完全支持该能力：你可以和WPF端一样在运行时用C#代码动态创建XAML控件实例添加到视觉树，也支持通过XamlReader.Load()方法直接加载动态生成的XAML字符串生成控件，和WPF端的使用逻辑基本一致。

4. 原生应用方案与MAUI+Blazor的对比 #

• 如果你未来的多平台需求只需要覆盖Windows、macOS、移动端，两种方案差异不大：MAUI+WebView2的方案本质是套壳Web应用，原生性能会弱一些，但开发成本更低；Uno的原生方案是直接把XAML编译为对应平台的原生控件，渲染性能更高，同时可以直接调用各平台原生API不需要走JS互操作，但XAML的适配成本会比直接复用Blazor的HTML高。
• 如果你的需求需要覆盖Linux桌面端，Uno的支持成熟度远高于目前的MAUI。

5. UWP技术路线可靠性问题 #

不用担心UWP的生命周期问题：Uno已经把底层基础框架迁移到了WinUI 3，UWP现在只是作为兼容的旧标准存在，后续的开发路线都是对齐微软的WinUI 3标准，WinUI 3是微软官方现在主推的Windows桌面UI技术栈，路线稳定性有保障。

6. MAUI和Uno的合并可能性 #

目前没有任何官方信号表明二者会合并或者其中一方停止维护：MAUI是微软官方的跨平台UI框架，侧重全平台原生应用的统一开发体验；Uno是社区主导、有商业化支持的框架，侧重WinUI/XAML生态的跨平台迁移，二者的定位和发展路线差异很大，未来3~5年内不存在一方被淘汰的风险。

方案选择建议 #

如果你当前的核心需求是快速推出Web版本，原来的WPF项目没有大量复杂的自定义XAML控件，选Uno可以省下重写所有UI层的成本；如果你的WPF项目XAML部分定制化程度非常高，或者团队对HTML/CSS的熟练程度远高于XAML，那之前的Blazor WASM方案落地效率会更高。

内容的提问来源于stack exchange，提问作者Shuryno