很多人说 C++ 的 MFC 已经过时了，那新入门的人到底应该学什么？ 第1页

用过很多 GUI framework（或 library），在我看来，不同时期不同 frameworks 的侧重点都是不同的。

MFC 那个时期，C++ 连 lambda 都没有，人们基本就是把它当作 C with classes 来用的，而 MFC 要解决的一大问题就是把 Win32 API 面向对象化，仅此而已。可以回想一下用 Win32 API 创建一个按钮大致是怎样的一个流程。那时候一切皆是窗体（Win32 API 中用 HWND 表示，注意，它还是 kernel-awareness 的），控件作为子窗体存在于父窗体中，多创建几个按钮说不定还会句柄溢出，直接影响系统其他应用。不仅控件是窗体，连 Timer、Socket 和一部分 IPC 都要依赖与 HWND + 消息机制来搞。所以说 MFC 就是 Win32 API 的 C++ wrapper 也不为过，甚至 MFC 本身都没有完全隐藏 HWND 这个概念。

之后微软搞过很多界面库，什么 WTL、WinForms，思路都差不多，并没有突破性的进步。

Qt 是一个老牌的 GUI framework，其实发展到今天，它已经是一个类似 boost 的 C++ 开发全家桶了。Qt 一开始也是控件即窗体，那是因为它最初尊重每个系统自己的 convention，也会尽量让开发者的一份代码，在不同的系统上都有非常 native 的表现。但是从 4.x 开始，Qt 引入了 Direct UI 的概念。这就非常超前了，要知道，很多 UI 效果是标准控件所达不到的，假设我能从系统那里要来一个“画布”，哪怕是 HDC，开发者可以发挥的余地都会很大。所以 Qt 那时候搞了个 Graphics Scene，支持一个屏幕下显示上万个元素，并且支持各种 transform、opacity、composition 特性。之后 Qt 又做了许许多多非常 handy 的特性，比如 QSS、动画框架等等。

Linux 家族还有一个老牌界面库，Gtk。这个库我简单用过一点点，没有很深入研究，但我实在不明白我为什么要在当今这个时间点自虐一样地使用 C + GObject 来写东西。但是不得不承认，GObject 和 Gtk 设计得都非常优秀，虽说是 C 写的，但从设计和功能性上来说，比用 C++ 的 MFC 高到不知哪里去了。况且现在 Gnome 还搞了一个 Vala 语言，写起来跟 C# 差不多。

后来我去做移动开发了，接触了 Cocoa 和 Android UI Toolkits，不得不承认，这两者设计得都十分优秀。他们最大的一个突破在于把渲染 layer 化。最早 Cocoa 还没有引入这个概念，然后 WWDC 2006 上，乔布斯向开发者介绍了 Core Animation，正式把这个概念带入 Cocoa 开发中。它的突破点在于，开发者在做 UI 渲染时不需使用类似 DC 一样地东西来“画”界面，而是告诉框架“我的界面有什么”。Android 的 Canvas 虽然类似命令式绘图，但底层也是会转换成 layer，然后交给 Skia 去渲染。有了 layer 这个概念，开发者基本无需考虑性能和跨平台的问题，因为框架会操心如何渲染开发者交给它们的 layer，部分框架也会做优化，比如裁剪掉不需要的 draw call 等。并且也可以很轻松地在软件渲染和 GPU 渲染之间 switch。这个新的抽象极大地方便了开发者的开发。后来 Qt 也引入了类似的技术，做出了 Qt Quick，具体我就不展开了。

有人提到 WPF，它在微软的各种 UI 框架中算非常优秀的了，到后期 UWP 也沿用了一部分其中的技术，如 Xaml。上文提到的 Direct UI 和硬件加速 WPF 都做到了，并且还带来一些新的有突破的特性，像双向绑定、模板、资源字典、高 DPI 支持等等。

到这里归纳一下，MFC、Qt、Cocoa 这三个库可以代表那个时间段所产生的技术：面向对象、Direct UI、Layer & GPU 加速渲染。

但是近些年，UI frameworks 的发展方向变了，大家不再去研究怎么把 Direct UI 做得更好，怎么把硬件加速玩出更多花。来看看 SwiftUI、Flutter，它们都是站在“巨人的肩膀上”，一个基于 UIKit / AppKit，另一个基于 Skia。它们用现有成熟的技术，搭配新的开发范式，来进一步提升开发效率，改变开发方式。同样的还有 React、Vue，虽然它们也是 UI library / framework，但它们并不具体关心怎么“画” UI，反正真正的排版绘制交给浏览器就行了。

所以我想说的是，今天我们不需要纠结用哪个界面库了，界面库一直在发展，只是每个时期的方向和重点都不一样。老的项目考虑兼容性肯定需要采用不那么激进的方案，而新的项目现在用纯 native 的方式开发的人确实很少了。VS Code 已经证明，Web 技术也能做出一个高可用的 IDE 应用。现在不是还流行小程序吗？用一套 DSL 来描述界面，具体的 UI 渲染是用 Web 还是 native 开发者都不需要 care 了。这种做法也已经被广泛应用了，像 VS Code 有它自己的 UI 抽象层，Chromium 也有自己的 UI 抽象层。有了这些，开发者就只要专注于业务即可。语言？框架？那都不是事。

P.S. 看到很多回答都建议题主用 Qt，我觉得还是具体问题具体分析吧。用什么首先看场景，你说你要做一个 Photoshop、Word 这种级别的 app，Web 技术确实还比较捉襟见肘，首先性能就不会太好。但如果你要做一个音乐播放器、聊天软件，甚至游戏客户端，用 Electron + ffi 足够了，至少我日常使用的国产软件，我觉得 Electron 全都能搞定，再不行就 CEF（比如我现在部门做的产品）。

MFC是否过时，需要从几个方面讲。1.设计是否过时 2.业务是否过时

MFC是微软给出的 windows c++应用框架，对win32 api封装，并提供了一套自动化工具visual studio,兼容原生的win32 c api，它几乎必须配合vistual studio来开发，还支持比较抽象的概念比如com等。

这就是MFC的使用场景了。

现在大部分公司如果做windows新应用，大概率不会再直接使用mfc，而是使用微软给出的 c# wpf 这套方案。

如果公司技术仍然是mfc，要么是维护老的平台代码；要么是公司的技术路线就是c++，大量的扩展功能都是c++开发；

综上，MFC的业务我认为是过时的。大环境不是MFC过时，现在是互联网的天下了，做原生前端软件本身就很过时，开发难度大，工作机会少，还不挣钱。现在网上看看，讨论最热烈的，都是web前端、后端，动不动就高并发、分布式，人工智能AI、区块链等，技术更新太快了，MFC都几十年了，不会太调整了，这些新兴领域，才是未来，前景一篇大好。

设计是否过时呢？我们对比最多的就是MFC和QT，因为毕竟这俩都是C++写的。那么可以说，肉眼可见的设计落后。但是，要理解，MFC是没办法的，它的目的：1.完美兼容 windows c api 2.性能跟原生开发一个量级 ，你看看吧，这样的需求，当时的C++语言功能如此孱弱，为了不影响性能，大量使用宏，为了兼容，消息传递就是原生的msg,只能设计成这样了。这是无奈之举，你看后来用C#弄了一套，是不是顺眼多了。 QT跟MFC相比，无论是原生接口的融合度，还是性能，都是有差距的。 但是，QT目的不在于此，它就是要设计，模拟出一套跟平台无关的应用接口，它告诉大家，不管什么平台，做应用，应该有哪些接口。

新人入门，要看你入什么门了。是C++，还是win32开发呢？

如果是c++应用开发，不建议做MFC了。因为大环境上，做这个太委屈了。出力不讨好，别难为自己了。可以选择做做Linux端的c++服务应用，搞搞数据库等，这些内容更新慢，不容易过时，跟c++的定位相似

如果是做win32原生开发，那我建议从c#入手。

一切都是有感而发，未必正确，仅供参考。