WPF现状与未来发展策略解析：今生与前景探讨

时间：2026-08-20 20:08

本文承接上文《WPF老矣，尚能饭否——且说说WPF今生未来（上）：担心》，继续探讨WPF的发展现状与未来走向。“上篇”中的部分精彩点评：虽然WPF本身已经不再频繁更新，但围绕WPF理念延伸出来的技术体系仍在持续演进，比如如今的WinRT，本质上只是换了一套API，xaml还是xaml，数据绑定依旧是

本文承接上文《WPF老矣，尚能饭否——且说说WPF今生未来（上）：担心》，继续探讨WPF的发展现状与未来走向。

“上篇”中的部分精彩点评：

虽然WPF本身已经不再频繁更新，但围绕WPF理念延伸出来的技术体系仍在持续演进，比如如今的WinRT，本质上只是换了一套API，xaml还是xaml，数据绑定依旧是数据绑定，依赖属性仍然是依赖属性，模板机制也没有本质变化。其实学过WPF的人转向WinRT通常会比较顺手，Blend的使用方式变化也不大，只不过当前WinRT相关岗位的人才需求确实有些尴尬。
最后还是要感谢WPF，为我们带来了MVVM这种高效的开发方式和开发模型。 by @h82258652

虽然WinForm本身停止了功能更新，但是相关工具链其实一直在升级，比如VS设计器、C#语法、第三方控件以及开源组件等。
另外，WinForm基于Win32 API的设计本身已经非常成熟，从功能覆盖面来看也基本包罗万象，因此即便微软不继续更新，也未必会带来太大问题。 by @winkingzhang

技术总是在不断迭代和升级，有些人说厂商换个API只是为了赚钱，这种说法多少有些片面，也反映出不少人一换API就不会开发了。我倒觉得，平台更新归更新，开发者真正需要做的事情始终只有一件：写好代码，做好产品。.NET的开发思路其实一直都在那里，对吧。 by @笋干

微软的新策略

2014年2月，微软云服务部门负责人萨提亚·纳德拉被任命为新任CEO。
他接替了史蒂芬·鲍尔默，而鲍尔默此前对移动市场，尤其是iPhone和Android生态，缺乏足够敏锐的判断，这或许也是微软在与苹果、三星等竞争对手的市场竞争中失利的重要原因之一。

与前任不同，萨提亚·内德拉为微软确立了“云优先、移动优先”的整体战略，因此微软必须跳出传统桌面市场，这确实是顺理成章的发展方向。但更准确地说，WPF从设计之初就是基于一种相对“传统”的模型打造的，它是典型的富客户端桌面应用框架；而与之相对，WinRT采用了完全不同的设计模型，更加贴近现代移动平台和跨设备场景的需求。
当然，桌面应用和单机市场并没有消失，只是它们显然已经不再承担主导角色。

微软商店

为了从应用生态中获取一部分开发商收入，苹果、微软等平台厂商都建立了自己的“应用商店”，应用的发布、分发与购买基本都在其中完成。据我所知，很遗憾，微软商店中的应用通常必须基于WinRT开发，因此基于WPF开发的应用无法直接发布到微软商店。
需要注意的是，对于一些业务型软件来说，它们往往是内部部署和内部使用的；而像ERP系统这类大型软件厂商，也通常拥有自己的销售与分发渠道，所以这并不一定构成问题；但对于小型软件开发商或独立开发者来说，这就是一个现实障碍，因为你往往希望借助公开透明的应用市场，尽快在竞争对手之前占领市场。
如今，越来越多的用户在不知道去哪里获取新应用时，会本能地先去在线商店搜索。如果你开发的是WPF应用程序，那么在产品发布层面会遇到明显限制，更不用说后续的商业销售，因此，从市场渠道角度看，使用WinRT开发会更合适。

移动性

如果你每天都通过移动设备上的浏览器或本地App获取信息，那么你一定明白当前市场的主流趋势：你的应用需要具备移动版本。
而WPF从来就不是为移动开发准备的核心角色，甚至连配角都谈不上。前些年，面向Windows Phone定制的Silverlight曾一度登场，作为当时Windows Phone 7的主要开发工具。但一个平台对应一套独立开发框架显然不是理想方案，尽管它们之间可以共享部分流程和标记代码。
WinRT正是在这样的背景下诞生的，它是一套面向Windows 8及以上全系列平台设计的开发框架，从系统层面强调一致性，目标是提供更易上手的统一开发工具集。也正因如此，一些第三方控件厂商也开始支持WinRT，例如：ComponentOne Studio for WinRT XAML。

维护成本

如果你这些年一直在微软技术平台上工作，那么你大概会知道，微软在资源投入和成本控制方面向来十分谨慎。原因其实也很简单：首先，作为一家商业公司，微软必须盈利，而且还要达到甚至超过股东预期，所以自然会倾向于控制开支；其次，很多看起来只是“小改动”的功能，背后往往需要投入大量研发、测试和兼容性验证工作。Eric Lippert曾在博客中对此做过非常形象的说明：How many Microsoft employees does it take to change a lightbulb?
因此，当社区提出修复某个bug或增加某项新功能时，通常只有在它符合下面两类情况时，微软才更可能采纳：
- 重大问题，例如安全漏洞，即便只有少量用户会遇到
- 改动不大，但有大量用户持续抱怨
如果同时维护WPF和WinRT，就意味着要并行处理两套功能需求、两套缺陷修复和两套生态支持，这显然并不经济，尤其是在微软持续压缩成本的前提下更是如此。

可移植性

想一想，究竟是什么特质能让WPF长期“活下来”呢？例如，作为一种具备可移植能力的客户端开发技术？但很遗憾，它并不具备这一优势。
事实上，已经存在一个可移植版本的.NET（这里指更学院派意义上的、包含CLI的实现），那就是Mono。它不仅可以运行在Windows上，也能够运行于Linux、Unix和Mac平台。[注：本文未提到微软.NET开源、可移植的最新消息]
另外，Mono并不是一个“玩具级”技术，它是真正可用于生产环境的。就我个人而言，我已经在Ubuntu服务器以及Jenkins集成服务中使用它来构建应用。
Mono支持.NET框架中的大部分技术，但唯独没有真正支持WPF；如果我没记错，过去曾有一个名为“Olive”的项目尝试过相关工作，但最终并没有真正推进下去，因为整体工作量实在太大，尤其是底层渲染层的实现难度非常高。
Mono目前支持的唯一界面技术是WinForm，颇具讽刺意味的是，也正因为具备一定可移植性，WinForm反而比WPF拥有更强的生命力。

Silverlight综合征

作为一名Silverlight开发者，我对技术生命周期的短暂有着非常深刻的体会。回到2008/2009年，富互联网应用（RIA）正处于高速发展阶段，微软顺势推出了自己的框架Silverlight，并在随后的一系列微软活动中大力推广，希望各类企业和业务负责人能够在其IT体系中采用这一方案。接着在2010年直到2011年第一季度，我们都还在持续投入Silverlight应用开发。
然而，在之后的一次技术会议上，微软却宣布不再重点推进Silverlight，转而大力拥抱HTML5生态体系（包括CSS和Ja vaScript）。尽管官方一再表示Silverlight的定位并未改变，但我对此始终持怀疑态度，也曾对这件事进行过相关报道。随后，我所在的团队决定停止Silverlight项目开发，把精力重新集中到更“传统”的WPF开发上，因为这样做在当时反而还有一些实际优势（例如，Silverlight并不是“开箱即用”的，还需要管理员权限安装Silverlight运行环境）。

值得庆幸的是，大部分XAML和C#代码（大约85%）都可以与WPF共享，因此整体迁移损失并不算大，我们几乎没有经过太多犹豫就停止了相关投入。
事实证明，这最终是一个正确决定，因为到了2013年，微软官方宣布Silverlight终止，许多IT从业人员都感到非常震惊，因为他们此前几乎没有收到明确预警。
我并不认为类似的事情会以同样粗暴的方式再次发生在WPF身上，但在当下的IT环境和技术语境中，你难免会感到失望、变得更加谨慎，甚至对平台路线产生深深的不信任。