WPF更适合新项目，尤其需高自由度UI定制、动画、矢量图形、多分辨率适配、数据驱动（MVVM）或未来向MAUI迁移的桌面应用；WinForms适合维护旧系统或极简需求。
WPF 更适合新项目，WinForms 适合维护旧系统或极简需求。
WPF 适合哪些场景
需要高自由度 UI 定制、动画、矢量图形、多分辨率适配（比如 4K 屏）、数据驱动界面（MVVM）、或未来可能扩展为跨平台（通过 MAUI 迁移部分逻辑）的桌面应用，WPF 是更现代的选择。
-
WPF使用XAML声明式布局，样式和行为解耦更彻底，Binding和INotifyPropertyChanged支持原生且稳定 - 硬件加速渲染，滚动、缩放、透明效果等性能明显优于
WinForms -
VisualStateManager、StoryBoard、ControlTemplate等机制让复杂交互 UI 更易组织 - 注意：
WPF的WebView2控件需手动集成，不能直接拖拽；对低版本 Windows（如 Win7 SP1）需额外部署.NET Framework 4.6.2+或使用.NET 6+ SDK-style项目并发布自包含包
WinForms 什么时候还值得选
团队熟悉 WinForms、项目只需基础表单+报表+简单交互、目标环境受限（如老旧工控机只装了 .NET Framework 2.0/3.5）、或必须快速交付 MVP 验证流程，WinForms 依然可靠。
- 设计器成熟，
Button、DataGridView、ReportViewer开箱即用，双击事件写法直觉性强 - 内存占用更低，启动更快，尤其在资源紧张的嵌入式 Windows 环境中表现更稳
-
WinForms在.NET 5/6/7/8中已完全跨平台支持（仅限 Windows 运行时），但 UI 层不兼容 macOS/Linux - 坑点：高 DPI 缩放需手动设置
Application.SetHighDpiMode(HighDpiMode.SystemAware)和AutoScaleMode = AutoScaleMode.Dpi，否则模糊或错位
别忽略的现实约束
框架选择常被开发效率、团队技能和部署条件倒逼，而非纯技术优劣。
- 如果主力开发者只会拖控件 + 写
button1_Click，强行上WPF+Prism会拖慢进度甚至引入NullReferenceException高发区 -
WinForms调用DirectX或OpenGL需绕过Panel.Handle做窗口句柄桥接，而WPF用WindowsFormsHost嵌套 WinForms 控件反而更常见 - .NET 8 默认模板中，
WPF项目生成Microsoft.NET.Sdk.Razor引用是误配，应改为Microsoft.NET.Sdk+<UseWPF>true</UseWPF> - 第三方控件生态差异大：
DevExpress和Telerik对两者都支持，但Syncfusion的 WPF 版本更新更激进，WinForms 版本文档示例更“手把手”
<!-- .NET 8 WPF 项目文件正确配置片段 -->
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net8.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
</PropertyGroup>
</Project>真正卡住项目的往往不是框架本身，而是团队对 Binding 更新时机的理解偏差、Dispatcher.Invoke 漏用导致的线程异常，或者以为 WinForms 的 BackgroundWorker 能自动更新 UI —— 这些细节比选型更消耗调试时间。
