1. 先看本质WinForm 与 WPF 到底差在哪1.1 渲染架构GDI 与 DirectX 的分水岭很多刚入行的人觉得 WinForm 和 WPF 只是“长得不一样”其实两者的底层渲染机制完全不同。WinForm 基于 GDI所有控件绘制基本靠 CPU画一个圆、写一行文字、刷新一个表格都是在走 GDI 的绘制管线。WPF 则统一走 DirectX大部分渲染任务可以交给 GPU而且支持矢量图形、硬件加速、离屏渲染和动画合成。这个差异直接决定了界面上限WinForm 做传统的参数面板、按钮、表格完全没问题但如果你要做一个带实时曲线、旋转动画、3D 模型展示的产线看板WinForm 就会明显吃力而 WPF 反而越复杂越能体现优势。不过这里得先泼盆冷水。上位机项目里最不缺的就是“我以为界面会很复杂其实客户要求并不高”的情况。一套设备操作界面翻来覆去就是状态监控、参数输入、报警列表、手动操作按钮、简单曲线这些用 WinForm 写反而启动更快、内存占用更可控。我见过不少团队放着稳定的 WinForm 不用强行上 WPF结果花了两倍时间做界面最后交付效果和原来差不多。选型不是看谁技术更先进而是看你的项目到底需不需要那些先进能力。从项目启动速度来看WinForm 也有优势。纯 .NET WinForm 程序在普通工控机上打开几乎是秒出窗体同样的机器跑一个 WPF 应用首次加载 PresentationFramework 和主题资源会明显慢一截复杂模板首次渲染甚至会有半秒到一秒的延迟。这不是说 WPF 不好而是你在写上位机程序时要有心理准备WPF 的“流畅”是渲染起来之后的事情启动阶段反而是它的短板。工控现场经常有“一开机就要自动进入界面”的需求启动慢一秒客户就会觉得你的软件很笨重。1.2 生态和寿命谁更可能被微软放弃聊到选型大家最关心的一个问题就是都 2026 年了WinForm 是不是已经被微软抛弃了说实话微软对 WinForm 确实已经进入“维护模式”基本只修 bug、补兼容性不再加新功能。但“维护模式”不等于“不能用于新项目”.NET 8 和后续版本里 WinForm 依然是一条受支持的产品线你在 2026 年新建一个 WinForm 项目完全合法而且安全。真正的问题不是微软支不支持而是整个社区的新示例、新控件、新思想都已经偏向 WPF 了。WPF 的处境其实也有点微妙。它比 WinForm 受重视但微软现在的重心早就不在桌面独占技术上MAUI、Blazor Hybrid、Avalonia 这些都在分走注意力。WPF 的优势是成熟、稳定、有庞大的开源资源劣势是学习曲线比 WinForm 陡团队里必须有人真正明白数据绑定和 MVVM否则写出来的 WPF 会比 WinForm 还难维护。我在实际评估项目时经常跟客户说选 WinForm 是选“确定”选 WPF 是选“上限”。如果你是一名独立开发者或者团队里的人都只写过 WinForm那么贸然转向 WPF短期内一定会有一段效率低谷。至于 .NET Framework 4.8 和 .NET 8 的差异也是选型时绕不开的话题。很多老设备商提供的 SDK、DLL、示例代码还是基于 .NET Framework 4.x 的 WinForm 写的往上搬没有任何障碍。但如果你的新项目想用 .NET 8 自包含发布、单文件部署、内存分析等新特性建议还是尽快迁到 .NET 8 或更高版本别再守着老的 .NET Framework。WinForm 和 WPF 在 .NET 8 里都支持这一点没有分歧。2. 从实际场景拆解核心技术点2.1 界面复杂度和数据绑定我拆解上位机项目时第一个判断维度永远是“界面数据流动是否频繁”。传统 WinForm 的开发模式是事件驱动加手动赋值串口收到数据解析完然后textBox1.Text 值; label2.Text 状态;如果界面元素少这个模式非常直接代码量也不大。但界面一旦超过二三十个控件每个控件都散落着手动赋值逻辑你会发现自己永远在追着 UI 跑改一个变量名要好几个地方一起改调试时眼睛都花了。WPF 的核心优势是数据绑定。你只需要把界面的Text、IsEnabled、Foreground等属性绑定到 ViewModel 的属性上后台更新属性界面自动跟着变。举个例子WinForm 里更新一个状态栏你可能要写三行代码WPF 里只需要让 ViewModel 实现INotifyPropertyChanged然后修改属性值界面自己就刷新了。对于多页面、多参数、需要频繁联动控制的复杂上位机软件这个优势是压倒性的。public class MainViewModel : INotifyPropertyChanged { private string _status; public string Status { get _status; set { _status value; OnPropertyChanged(nameof(Status)); } } public event PropertyChangedEventHandler PropertyChanged; protected void OnPropertyChanged(string propertyName) PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName)); }XAML 里这样绑定TextBlock Text{Binding Status} /代码简单到没什么好解释的但背后涉及的东西不少DataContext从哪里来、绑定的路径对不对、属性变更通知有没有触发。这些都是 WPF 新手最容易踩坑的地方。最典型的问题是ViewModel 属性值已经变了界面却没反应排查半天发现属性类没有继承INotifyPropertyChanged或者集合用的是普通ListT而不是ObservableCollectionT。这种问题在 WinForm 里根本不存在因为你永远是主动写“赋值代码”去刷新界面绕过了数据绑定这一层。我的实际建议是如果你的软件界面只有简单几个页面数据量也不大WinForm 够用别为了“先进”硬上 WPF。但如果你预感到界面会越改越复杂比如客户后期一定会加报表、加看板、加多级联动配置那从一开始就用 WPF MVVM 会更省心。我自己接手过好几个“先 WinForm 图快、后期需求膨胀到想重构”的项目那种痛苦比一开始多花两周学习成本要难受得多。2.2 多线程与设备通信上位机开发里最绕不开的一个问题就是“后台通信线程和 UI 线程怎么协作”。串口、TCP、Modbus、PLC、扫码枪、仪表不管接什么设备数据几乎都是异步到达的。WinForm 里最经典的做法是用Control.Invoke或BeginInvoke把 UI 更新丢回主线程serialPort1.DataReceived (s, e) { string data serialPort1.ReadExisting(); textBoxStatus.BeginInvoke(new Action(() { textBoxStatus.AppendText(data); })); };这段代码本身没毛病但它在高频场景下会引发性能问题。串口数据几十毫秒来一次还好如果是网口上传的批量数据、摄像头识别结果、或者每秒几十条状态帧你还这样一条一条BeginInvokeUI 线程会被刷新消息塞满界面肉眼可见地卡。所以在 WinForm 里高频刷新一定要做“合并”把最新数据放到一个共享对象里然后用一个 100~200ms 的定时器统一刷新界面而不是来一条刷一次。WPF 的思路是一样的只是把Control.Invoke换成了DispatcherApplication.Current.Dispatcher.BeginInvoke(new Action(() { Status receivedText; }));要注意的是上位机里的很多通信库本身就在后台线程触发事件所以无论你选 WinForm 还是 WPF都必须具备“线程切换”的基本功。我面试上位机工程师时必问的一个问题就是Invoke和BeginInvoke有什么区别Invoke是同步等待BeginInvoke是异步丢进去不等待前者在极端情况下可能造成死锁后者不会阻塞后台线程。WPF 里对应的Dispatcher.Invoke和Dispatcher.BeginInvoke也一样。这块基础打不牢换哪个框架都会写出一堆偶发卡顿和闪退。2.3 报表、大屏和 3D 看板2026 年这个时间节点上位机的概念早就不是“一台工控机加一个串口面板”了。客户张口就是“我要一个数据大屏”要做产线看板、设备综合效率看板、能耗看板、实时报警看板。这类界面有共同特点深色背景、大数字、大图表、平滑动画、多屏拼接显示。这时候 WinForm 和 WPF 的差距一下就拉开了。WPF 做动态看板非常顺手因为它的动画体系是声明式的绑定的数据一变界面可以自动过渡、闪烁、变色。图形图表也有成熟方案比如 LiveCharts、OxyPlot、ScottPlot 在 WPF 里都表现不错。再往上走WPF 还支持 3D 渲染虽然性能不能和专用游戏引擎比但画一个简易的设备三维示意、机械臂姿态动画、料仓液位立体效果完全能做到。如果你需要在界面上展示设备空间位置、实时运动轨迹WPF 是明显更合适的选择。WinForm 也不是不能做但大多是靠第三方图表控件堆出来的。你用 WinForm 画一个 3D 看板要么走 OpenTK 之类的外部库要么自己用 GDI 模拟每一帧都要手动控制刷新代码量大、可维护性差。遇到客户要求“这个数字跳一下要有动画”WinForm 要费很大劲写定时器、插值、动画状态机而 WPF 一个DoubleAnimation就能搞定。但我得说一句公道话如果只是像样地从零开始做网站式大屏其实还有更多非 WPF 的路线比如用 Blazor、Web 前端嵌浏览器但那些是另一套复杂体系不是所有人都有精力学。回到桌面上位机范畴WPF 就是目前做漂亮界面的最佳默认选择。3. 2026 选型决策按项目需求对号入座3.1 什么情况无脑选 WinForm不是所有项目都需要 WPF 的重型渲染能力。我做了十几年上位机遇到下面这些情况基本都会建议客户继续用 WinForm项目要求两到四周内交付界面简单主要逻辑在通信和流程控制。工控机配置低用的是老旧 CPU或者没有独立显卡甚至还在用 Windows 7 的触摸屏一体机。设备厂商的 SDK、示例代码、DLL 都是基于 WinForm 写的照着改最简单。现场维护工程师只熟悉 WinForm 代码招人不容易培训新框架成本高。软件需要长期无人值守运行追求极致稳定不追求花哨界面。这些项目里WinForm 的效率是真的高。写一个设备状态监控界面拖控件、订阅事件、更新文本框半天就能出个能用的版本。客户看到界面不丑、不卡、功能达标就很满意。技术先进与否在工厂产线上没那么重要稳定交付永远排在第一位。另一个容易被忽视的点是WinForm 对高分屏的适配虽然不如 WPF 干净但在老设备上运行反而更稳。很多工业触摸屏的分辨率还是 1024x768 或者 1366x768WinForm 做完直接铺满屏幕不需要考虑复杂的缩放策略。WPF 在这种低分辨率老旧设备上反而可能出现字体渲染发虚、界面初始化慢这类问题。3.2 什么情况值得为 WPF 多花学习成本如果项目命中下面几条我建议你认真考虑 WPF界面对客户有很强的“展示属性”比如投标演示、对外参观、大屏展示界面观感直接影响项目成败。需要做多页面、复杂联动配置后台数据结构比较深UI 只是数据的一种呈现方式。需要做动画、实时曲线、3D 示意、数据可视化而不是简单表格。团队里至少有一两个人愿意花时间研究 MVVM并且能沉淀出项目模板。你希望代码可测试、可维护后续可能从 UI 层剥离业务逻辑方便复用接口。WPF 最值钱的地方不是“看起来漂亮”而是“数据和界面分离”。MVVM 模式下你的通信逻辑、数据处理逻辑都在 ViewModel 里不依赖具体控件单元测试可以放心写。WinForm 想做到同样程度的分离不是不行但需要很强的自律否则最终还是会滑到“事件方法里全是业务代码”的老路。如果你的项目已经预见会长久迭代代码结构的重要性会逐渐超过“快速出界面”的重要性。我自己的感受是WPF 前期学习曲线主要在三个方面数据绑定、路由事件、模板和样式。前两个搞明白你已经能写出结构清楚的 WPF 上位机第三个属于进阶用来做风格统一、换肤、自定义控件。很多人半路放弃是因为一上来就想写自定义模板结果被依赖属性、附加属性搞崩溃。其实做上位机一开始根本不需要碰这些东西老老实实绑定数据、写几个简单样式够用了。3.3 一个偷懒但很实用的决策矩阵为了避免选型变成“拍脑袋”我给自己总结了一张很实用的对照表。每次接项目先看几个关键维度打分后自然就有结果。评估维度WinForm 得分WPF 得分项目交期紧张程度高低界面美观要求低高数据/界面分离需求低高动画、大屏、3D 需求低高团队现有技术积累高低工控机硬件配置高低后期需求变化频率低高招聘/培训难度低高这张表不是让你算总分而是帮你把优先级想清楚。交期特别紧硬件配置又差界面没要求那 WinForm 就是正确答案。反之客户要长期做品牌展示界面会不停迭代那 WPF 就是值得投入的方向。最怕的是项目命令矛盾交期只有两周却要求各种炫酷动画。这时候我的经验是先跟客户确认真实需求很多“动画效果”其实只是“数字跳一下”“图表刷一下”WinForm 加一点定时器也能做到七成效果。如果你实在拿不准还有一个更保守的方案先用 WinForm 快速搭出业务功能后期如果有界面升级需求再逐步把表现层迁移到 WPF。这个路线听起来不够优雅但在工控行业里非常常见而且成功率不低。重要业务逻辑不要写在 UI 里只要你一开始就做分层未来重写界面层并不会伤筋动骨。4. 打包、部署和团队协作的现实问题4.1 安装包制作与现场部署选型时大家大多关注写代码的过程但上位机项目里“能不能顺利装到客户电脑上”才是售后痛苦的真正来源。WinForm 和 WPF 在这件事上其实没有本质差别真正有差别的是你到底用 .NET Framework 还是 .NET 8 之后的版本。老的 .NET Framework WinForm 项目客户机器上没装对应版本就白屏现场一堆 Win7、Win10、Win11 混用环境千奇百怪。后来的 .NET 8 已经支持框架依赖发布和自包含发布自包含模式会把运行时一起打进去客户机器上不用装 .NET 也能跑代价是发布体积变大。对工控上位机来说我一般强烈建议自包含发布因为现场环境太不可控了你不会希望一个客户换了电脑、没装运行时就把锅甩给你。单个上位机程序几百兆在现在这个硬件条件下完全不是问题。安装包制作方面WinForm 和 WPF 用的工具基本一样。WinForm 项目里很多人习惯用 Visual Studio Installer Projects 打包这个插件在 VS2015 上很好用但在新版本 Visual Studio 里已经不太好找了。现在更主流的做法是用 Inno Setup、NSIS 或者 WiX。我个人最常用 Inno Setup理由很简单脚本门槛低能自定义安装界面能写注册表启动项能创建开始菜单快捷方式还能在安装过程中做驱动和依赖检查完全够用。打包时一个常见的坑是程序发布成单文件后WPF 的资源文件、字体文件、多语言资源有时会因为IncludeAllContentForSelfExtract之类的配置没设对而出现运行异常。你会发现程序在开发机上跑得好好的拷到现场机器上就报“找不到资源”。我的排查经验是不要盲目迷信单文件发布对 WPF 项目直接把必要的资源文件放在程序目录里用相对路径引用往往比压缩进单文件更省心。WinForm 项目相对简单但也要注意不要把配置文件写死在Program Files目录下上位机软件经常要写配置跑到客户机器上权限不够就写不了这是最典型的售后问题。4.2 团队水平与招聘难度选型不只是技术决策更多时候是人事决策。我见过不少团队用 WPF最后代码写得跟 WinForm 一样到处都是button_Click里塞业务逻辑数据绑定没怎么用还额外扛了 WPF 的复杂度。这种项目还不如直接用 WinForm 来得干净。所以你在 2026 年做选型必须先问一句团队里有没有真正写过、写懂 WPF 的人从招聘角度看市场上会 WinForm 的人很多但“会 WinForm”和“会写上位机”是两回事。真正值钱的是懂串口、懂 Modbus、懂 PLC 通信协议、懂多线程、懂异常处理的人。你招一个只会拖控件的 WinForm 工程师可能不如招一个数据结构扎实但愿意学 WPF 的年轻人。反过来如果你非要招一个既懂 WPF 又懂工控的人市场上确实少薪资也会高一些。对于小团队和独立开发者我的建议永远是别学两个都学不精扎扎实实把一个框架吃透比盲目追新更重要。还有一个很现实的问题老代码的维护。很多工厂里现在跑得最稳的上位机软件还是十年前用 WinForm 写的。你选型时不能只考虑“新项目怎么写”还要考虑“未来两年谁维护”。如果公司里只有你一个人会 WPF你一离职项目就是黑盒。所以我会要求团队至少在核心代码里坚持清晰的注释、明确的日志、统一的异常处理不管用什么框架都要让后来人能接手。技术选型决定了项目的起点代码规范决定了项目的终点。4.3 第三方控件的授权和兼容性WinForm 和 WPF 在第三方控件上的选择差异很值得注意。WinForm 领域老牌厂商很多比如 DevExpress、Telerik、ComponentOne它们做得最熟练的就是表格、树形列表、报表、图表。WPF 领域同样有这些厂商但功能覆盖和更新节奏略有不同而且 WPF 的第三方控件往往对数据绑定支持更好也更能发挥 MVVM 优势。问题在于第三方控件的商业授权价格不低一套控件抵得上小项目一半的开发费小公司不一定愿意买。如果真的要用免费方案WinForm 里常见的组合是DataGridView加ZedGraph、ScottPlot再配一个开源日志组件基本能覆盖七成需求。WPF 这边免费的DataGrid、LiveCharts、OxyPlot也能做不少东西但 LiveCharts 的版本分裂很严重老版本和新版本 API 变化很大在 Stack Overflow 搜到的很多答案已经失效。我踩过这个坑之后现在写 WPF 图表更倾向于 ScottPlot它对实时数据刷新支持比较友好性能和 API 稳定性都让我更放心。除了功能第三方控件在高 DPI 下的表现也要提前验证。有些 WinForm 第三方控件在老版本和高分屏模式下会出现文字模糊、布局错乱有些 WPF 第三方控件则会因为模板内部没有跟随系统缩放而变形。我的做法是在选型阶段就把目标控件下载试用版放到客户真实分辨率的设备上跑一跑不要等到交付前才发现控件渲染有问题。一次试错成本远低于后期全部替换的成本。5. 常见问题与排查技巧实录5.1 高 DPI 缩放的坑现在新买的工控机基本都是 1080p 起步很多触摸屏一体机更是直接用 4K 分辨率。上位机软件如果不做高 DPI 适配界面在客户机器上会糊成一片按钮位置乱掉字仿佛蒙了一层雾。WinForm 的老问题是默认不感知 DPI在缩放比例 150% 的 Windows 上控件会被系统强行拉伸变成模糊一团。解决办法是在app.config里声明 DPI 感知模式为 PerMonitorV2或者在代码启动时设置ApplicationHighDpiMode。但这样做了以后老式第三方控件很容易出问题因为它们的绘制逻辑是基于旧 DPI 体系写的。WPF 因为是矢量渲染对高 DPI 的适应能力天然强于 WinForm。理论上 WPF 在任意缩放比例下都能保持文字和形状清晰但实际项目里也会遇到问题嵌入的图片、截图、非矢量资源不会跟着缩放某些第三方控件的固定尺寸模板也会错位。所以在 WPF 上位机里我习惯把关键图标做成矢量格式或者用尺寸单位DIP来设计界面而不是写死像素值。字体大小、行高、间距都尽量让系统来算少做手动硬编码。如果你同时维护 WinForm 和 WPF 两套代码高 DPI 问题会让你非常痛苦两边的调试方式完全不一样。我的经验是在高 DPI 问题没解决之前别急着交付先准备一台和高分屏、触摸屏或远程桌面分辨率一致的测试机专门用来做界面回归。上位机软件在客户现场的展示位经常是竖屏或超宽屏你开发时用的普通显示器根本暴露不了问题。5.2 界面卡顿与刷新优化上位机卡顿的最大元凶不是框架选错而是“UI 刷新频率过高”和“UI 线程被阻塞”。很多人写 WinForm收到数据就textBox.AppendText数据密集时每秒可能追加几百次控件的文本重排、绘制、滚动更新全挤在主线程不卡才怪。我后来在项目里强制要求所有高频实时数据先写进一个环形缓冲区UI 侧用一个 200ms 的System.Windows.Forms.Timer统一刷新这样界面最多每秒更新五次肉眼根本感觉不到延迟CPU 占用却能大幅下降。WPF 也有类似问题只不过把定时器换成DispatcherTimer。列表控件尤其要注意。WinForm 的ListView在大数据量时直接Items.Add会卡正确做法是开启VirtualMode只加载可见区域的数据。DataGridView数据量大了也要考虑VirtualMode或者分页。WPF 的ListBox、DataGrid绑定大数据集合时如果启用了默认的容器虚拟化情况会好一些但前提是你不要随手关闭虚拟化。很多人为了做自动滚动把ScrollViewer.CanContentScroll或面板改成StackPanel结果数据一多内存直接爆掉这种坑我见得太多。还有一个常见优化点是BeginUpdate和EndUpdate。WinForm 里批量刷新前调用SuspendLayout、BeginUpdate完成后再恢复可以避免每次属性变化都触发一次重绘。WPF 里没有这么直接的 API但可以用Freeze冻结不变化的画刷、几何对象减少渲染线程的压力。性能优化没有银弹核心思路始终是同一个能少刷新就少刷新能合并就合并能只改一个属性就不要改十个属性。5.3 状态栏与进度条更新很多上位机项目都有“状态栏显示当前通讯状态 进度条显示任务进度”的需求。WinForm 里传统做法是BackgroundWorker它提供了一个ProgressChanged事件后台线程里调用ReportProgress事件会在 UI 线程触发直接更新ProgressBar和ToolStripStatusLabel这是最稳妥的写法backgroundWorker1.ProgressChanged (s, e) { progressBar1.Value e.ProgressPercentage; toolStripStatusLabel1.Text $正在处理... {e.ProgressPercentage}%; }; backgroundWorker1.DoWork (s, e) { for (int i 0; i 100; i) { Thread.Sleep(20); backgroundWorker1.ReportProgress(i); } };WPF 里我更喜欢用 .NET 自带的IProgressT配合ProgressT它在创建时捕获当前同步上下文所以在异步方法里直接调用Report就能安全更新界面var progress new Progressint(value { ProgressValue value; StatusText $正在处理... {value}%; }); await Task.Run(() { for (int i 0; i 100; i) { Thread.Sleep(20); progress.Report(i); } });这里有一个非常容易踩的坑ProgressT是在创建它的线程上下文里回调所以如果你在后台线程里重新new Progressint回调就不会回到 UI 线程。很多人把进度条做成一个后台服务结果回调跑在随机线程池线程上直接改 UI 就崩了。我的建议是进度对象要么在构造函数或 UI 线程创建后一路传下去要么在回调里再包一层Dispatcher.InvokeAsync别想当然。5.4 数据绑定和 MVVM 的诡异问题WPF 数据绑定写起来快但出问题时排查也麻烦。最常见的现象是界面什么都没显示但代码看不出问题。这时候第一件事就是看输出窗口里的 Binding 错误日志。WPF 的绑定失败原因一般都会打印在 Debug 输出里比如“找不到路径”、“数据上下文为空”等。你可以在 XAML 里临时加上PresentationTraceSources.TraceLevelHigh来打开详细追踪这招对定位绑定问题非常有效。如果绑定的属性是普通string、int没问题但如果绑定的集合不自动刷新就有大问题了。普通ListT在绑定后不会通知界面“我加了一个元素”必须换成ObservableCollectionT。同理属性更新必须触发PropertyChanged否则绑定的TextBlock永远停留在旧值。很多新人是把get和set写对了却忘了属性所在的类没有继承INotifyPropertyChanged这等于绑了个一次性快照。WinForm 的数据绑定相对简单用BindingSource加DataSource就能绑定集合但同样有值更新不同步的问题。如果集合元素是普通类修改了属性不会自动刷新列表必须重新调用ResetBindings。还有一个非常反直觉的坑WinForm 的ComboBox.SelectedValue和SelectedItem在某些状态下会互相干扰导致明明设置了选择项显示却是空的。这类问题没有固定解法只能靠日志和逐步隔离排查。6. 我的选型体会和一条折中路线做了这么多年上位机我的最终体会是2026 年的 C# 上位机开发真正重要的不是“哪个框架会取代谁”而是你能不能把一个项目从“能跑”做到“好维护”。WinForm 和 WPF 在微软产品线里会继续共存很长时间选型没有绝对答案只有和你的项目、团队、客户匹配的答案。如果让我给还没入行的新人一个套路我会建议先老老实实把一个 WinForm 上位机项目写完搞懂串口、TCP、多线程、委托、事件再去看 WPF 的绑定和 MVVM。有了 WinForm 的经历你才知道 WPF 解决了哪些痛也才知道哪些地方是 WPF 帮不上忙的。直接上手 WPF 不是不行但容易浮在表面只会绑定不深入理解线程和通信一样写不好上位机。如果你已经在维护一个老 WinForm 项目又想要更现代的架构我的经验是别重写先重构分层。把串口通信、协议解析、数据缓存全部拆到独立类库里UI 层仍然用 WinForm但只是做展示等哪一天公司下定决心做界面升级再把 WinForm 窗体整体换掉业务逻辑和通信代码几乎不用动。我自己有一个项目就是这么迁移的从 WinForm 到 WPF过程很痛苦但风险可控核心代码没有推倒重来。最后再分享一个经验选型之前先去客户现场看一眼设备环境。如果客户现场全是老式工控机、屏幕分辨率低、环境灰尘大、程序常年不关WinForm 依然是最稳的选择。如果客户要把设备软件当成展示窗口要频繁给领导、客户演示界面效果就是销售的一部分那就别省 WPF 的功夫。技术没有高低贵贱能让你安安稳稳交付、顺顺利利收款、踏踏实实睡觉的框架就是好框架。