说实在的， 虽然折腾不少框架， 库啥的
但这么多年却没有正经学过微软的任何语言或框架， 原因就不讨论了
但我现在想做正统的 windows 本地桌面程序开发， 想请 windows 开发经验多的人指点下， 省的走弯路， 省点时间
我虽然没搞过， 但大概也知道， 就算微软支持的东西也很多， 比如 winform ，wpf ， 语言也一大堆
我说下我的目的和要求

目标是做正统的 windows 桌面程序， 不是为了学习目的
不用 c 或 c++， 不折腾
只使用微软官方支持技术（不要推啥 electron ，qt 等其他东西）
生成的 exe 或程序包尽量小， 依赖尽量少， 最好只需按照程序相关东西， 其他的系统直接支持
暂不考虑跨平台（当然我也知道.net 好像开源， 不清楚是否能容易移植到 macos ）
希望这套技术能在未来五年仍然是微软支持的主流技术框架

希望得到具体点的意见
比如用啥语言 ， 用啥框架， 怎么搭环境等
定好了直接开干。

delphi7

有时候不用想那么多，直接开干就好啦。为什么只用微软官方支持的技术？这个有点迷。官方现在主推 MAUI ，但是用过都会无尽吐槽，个人推荐 AvaloniaUI ，但现在的新技术基本都不支持 Win7 ，如果要支持 Win7 的话还是得用 Winform

react native ， microsoft.github.io/react-native-windows/

wpf 不就满足要求嘛，其实后面出的 uwp/maui 也都是 xaml 那套东西说到官方技术支持，就算是富哥们儿钱也不能这么造啊

昨天刚看到个 windows 界面开发相关的视频，可能和楼主第二条不符，但是思路还是可以借鉴的 www.bilibili.com/video/BV1rC4y1L7dX这人比较罗嗦，我个人总结，就是 GUI 区分为 IM 模式和 RM 模式。IM 模式指的是即时渲染，也就是可以不需要保存当前控件状态，你需要直接查状态就可以了，因为界面在不断刷新。RM 模式是传统的 GUI 消息模式，保存了所有控件的状态，比如某个按钮被点击了，会触发回调函数。需要完整 GUI 框架才能运行。视频推荐了 IM 模式进行开发，对比 RM 有一个好处，就是能极大化简 GUI 相关代码（因为不用管理状态）。

用.NET 做界面的话，可以在这些中挑下 WinForm, WPF, UWP, WinUI, Xamarin, MAUI, Blazor, Windows Community Toolkit, Uno Platform, Avalonia, Comet, ReactiveUI, Chromely, EdgeSharp, Electron.NET

这几个都是微软官方推荐的，任选一个： learn.microsoft.com/zh-cn/windows/apps/get-started/?tabs=net-maui%2Ccpp-win32

WPF 或者 WIN UI 3 ，UWP 已经半死不活了

如果追求体积小、现代化、微软支持、且排除 C++，那可以看看 React Native for Windows 。不涉及一些底层功能的话，只需要写 js 即可。底层界面框架是 Win10 自带的 WinUI2 ，不需要随程序附带。编译后 exe 印象中只有几百 KB ，React Native 的 dll 大概是 4MB 左右吧，以及你程序的资源文件，看复杂度有大有小。

另外要真正追求“Windows 正统”的话，其实只有 Win32 和 WinUI2 可选，因为只有这两者是 Windows 内置的。其他像 WPF 那些虽然是微软推出的，但是是比较独立于 Windows 本身的，去掉 .NET 部分也不会影响系统大部分功能。

那当然是 Microsoft DirectX , 楼上都是扯淡, Microsoft DirectX 才是王道 [doge]

保证正版微软支持, 并且满足以上所有需求. 不和语言绑定

WPF ，要不 webview2

WinUI 3

webview2 是目前主推的吧

小项目直接 winform, 大一点上 WPF,我说的,少看那些微软基于 webview 的东西,会变得不幸,微软后期推的技术都是一股咖喱味并且不太负责任,而 winform 和 WPF 是经典永不过时,大量工业软件都在使用它们,微软需要对这些技术负责,Windows 活一天他们活一天.并且他们的技术并不老旧一直在维护,winform 甚至都可以基于.net8 开发,我也推荐基于最新的.net8 sdk 而不是 framework 去开发.

你这几乎指定了就是 WPF 。WPF 那么好学好用的。

winform/wfp: 你直接念我身份证号得了

“经典永不过时,大量工业软件都在使用它们,微软需要对这些技术负责”MFC 也符合上述说法“winform 甚至都可以基于.net8 开发”最新的 VS2023 ，C++20 都能用 MFC“并且他们的技术并不老旧一直在维护”WPF 似乎一直只支持 Direct3D9 渲染，那么多年了也没有更新WinForm 和 WPF 估计已经进入维护模式了，就和 MFC 、IE 一样，微软停止更新后一般也会维护很长一段时间，但这不能代表好坏。

react native, flutter ,Electron 三个任选吧.. 不过从上手难度来说 react native ,Electron 最低... 毕竟不用再学一门语言 直接 JS 就搞定了

＃19 Winform 和 WPF 将在未来一直支持最新的.NET SDK ，将能够使用所有.NET 的新技术。而开源后的全新.NET 的前景以及微软的支持力度是有目共睹的。MFC 则并非如此，MFC 只是 win32 api 的封装，并且 MFC 的开发难度以及效率，功能完全无法与 Winform 和 WPF 相提并论。 MFC 当然可以基于语言的新版本开发，你不应该将新版本语言的好处与新版本.NET 的好处混淆，至少最基本的 GUI 开发方面，处理异步没有比.NET 更好的方式。 WPF 基于 DX9 渲染我不认为有任何问题，没有人会在 WPF 项目中写 3D ，如果你有图形需求你不应该在 GUI 框架中寻找解决方案。 至于维护模式，第一你不要估计，第二微软会维护很久，就像你热爱的 MFC 一样。

支持，这个比 wpf 简单多了

开发语言使用 c＃开发环境 visual studio 开发体验 wpf > winfrom控件框架的话 winfrom 我 n 年前使用过 DevExpress(收费) 体验还行,开发前注意对常用控件进行样式封装wpf 控件框架 有一个 HandyControl 还有注意 wpf 和 winfrom 不跨平台如果有跨平台需求用楼上推荐的 AvaloniaUI

满足这些要求的只能是 WPF+C＃了如果哪天突然想要跨平台了，移植到 AvaloniaUI 也比其他框架方便

我并不热爱 MFC ，请不要给我扣帽子，我讨厌 MFC 。.NET 的新技术难道不是“新版本语言的好处”吗？WPF 只支持 D3D9 本身就是问题，即使它使用了新版本的语言，但仍然使用旧的操作系统功能，那就无法获得最佳性能以及最新特性。这和 MFC 类似，MFC 能使用最新的 C++，但仍然只能使用老旧的系统功能。

至于异步问题，个人认为 C++20 的 coroutine 也很好用。我没有详细调查过 C＃的异步，不便评价。

试下 Duilib ？

Duilib 基于 C++ 的符合你要求的只有 WinFormShadowsocks Nutstore 以及一众餐饮 酒店 网吧管理软件都是 winform

就 C＃ WPF 就行，用最新的.Net 版本

目前来看只有 WPF 了

wpf 最新的.net

＃25 C++版本再高只影响语法，不影响 MFC 调用的 win32 底层实现。同理 C＃版本高也不影响任何实现，但是.NET 的升级会直接影响实现增加功能提升性能。至于 Windows GUI 开发不讨论异步，那么还有什么其他更加值得讨论的呢？

写 Windows 怎么可能不碰 win32 呢？

WPF 。一周上手 两周精通

犹豫不决，java 解决，上 swing ，jfx

“.NET 的升级会直接影响实现增加功能提升性能”提升性能很正常，C++编译器升级也能提升性能。但增加功能是怎么回事？ .NET 升级后 WPF 的功能就自动增多了？“至于 Windows GUI 开发不讨论异步”我有说过不讨论吗？我说 C++20 的 coroutine 很好用，但是 C＃我没详细调查过，不便评价，这就叫不讨论了？明明我在讨论 C++的异步。

大多数情况下可以只碰.net 上的封装，不至于直接接触 Win32 API

现在根本不用考虑其他的,直接使用 windows app sdk 即可--微软官方现在只有 winui2 与 winui3 在桌面端是持续维护的winui2 或者说是内置于系统的 xaml ui 框架,微软已经不再推荐 app 开发直接使用(windows 内置的应用,还有系统界面基本都是 winui2)windows app sdk 是独立于系统的一套 api,可以无缝使用 winrt,win32,winui3---当然现在 winui3 配合 c++是速度最快的,而.net 还不支持原生编译,启动比较慢以下是基于 winui3 的一些 app github.com/Paving-Base/APK-Installer github.com/files-community/Files github.com/Richasy/Bili.Copilot...

我想学做一道菜, 虽然中餐有很多菜, 比如这个那个的, 我要说下我的目的和要求:目标是要正统的中餐, 不为学习不用预制材料只用中国传统方法用材简单, 依赖少, 最好只要按菜谱材料, 非中餐地区也直接可以做不考虑使用刀叉用餐的问题 (当然我知道勺子也可以吃, 但不清楚是否容易)希望制作方法能一直流传/流行

＃39 西红柿炒鸡蛋，水煮白菜，请

WPF + C＃, 符合你要求列表中的所有条目。

WPF 工具成熟AvaloniaUI 工具还是有点问题

以前看过 Win MFC ，在 Win2000 、WinXP 时代，用纯正统 Win32 API 做一个窗体按钮出来，从头开始的话，很有可能是一个程序员半整天的工作量。。。不知道 MFC 被微软丢进柜子里后，2023 年用什么角色来担当这个事情了， 要小巧，要快，始终还是 Win32 API ，实在是太麻烦了。。。

＃36 C++编译器升级无法提升 win32 api 的性能，.NET 升级则能提升 WPF 框架性能。增加功能当然是增加.NET API 给你用。当然这些争执是无益的，Windows 下 GUI 开发选择 WPF 早就是标准答案，没有任何其他方式的开发效率，开发体验以及功能效果能够与之媲美。

要小要快一直是 Winform 在做

blazor-desktop ，纯 csharp ，发布到 edge-webview2 ，唯一的问题是新手大概要被 blazor 的一些特性绕几天

对了，如果开发时间宽裕的话，可以用 unity3D 做，挺多人用 unity3D 做跨平台图形界面应用程序的，但是个人账户发布的制品在启动时会显示 unity3D 的标识。

今天的电脑和 Win2K 时代的电脑相差特别大，消费者的需求也变了。那个时代 GUI 程序绘图全靠 CPU 处理，当时的主流分辨率还是 640x480 ，而且很多电脑的“显卡”用途真的就只是为了显示画面，没有加速绘图的能力。MFC 、Win32 API 、GDI+都是那个时代背景下的产物。而今天很多人都在用 4K 分辨率的显示器，还希望用触摸板滚动界面时能按像素滚动，滚完了还有惯性。软件界面要有丰富且流畅的动画。如今那么多人喜欢 macOS ，有很大一部分因素就是这个。所以微软不可能做一个全新的 MFC ，它已经不适合这个时代了。这种技术越多，Windows 的用户体验反而越差。现代的 Windows GUI 应用，绘图的部分都是 Direct2D 、DirectWrite 、Direct3D ，能利用 GPU 加速渲染。还能分担 CPU 的负担。这样才能实现在超高分辨率下平滑滚动等过去都不敢想象的需求。MFC 提供的其他与界面无关的功能，后来被.NET 平台完全取代了。因为这些东西早已成为 Windows 的一部分，所以上层应用同样可以“小巧”。如果仍然想用 MFC 、Win32 API 开发，其实依然可以用，用起来还是那个味道。但对于大多数应用来说，开发成本高，用户体验差。也许很省内存，但今天的内存十分廉价，甚至不如用这廉价的内存去省下其他更昂贵的东西。怎么想都觉得划不来。如果只是想做个无比简单的小工具，那么，用 WinForm 随便拖个界面，双击各种按钮填上代码，分分钟就糊出来了……

“C++编译器升级无法提升 win32 api 的性能”这是废话， .NET 升级也无法提升系统 API 的性能。举 MFC 的例子是为了说明“经典永不过时”、“可以使用最新语言特性”这些理由并不能说明一个框架的好坏，Delphi 那套也符合这些，但是也很少人使用了。再者 MFC 许多功能也并非由 Win32 API 提供，比如 MFC 有 Ribbon UI ，是 MFC 自己实现的，而不是 Win7 加入的那套，那升级 C++ 以及编译器显然也可以提升 MFC 本身的性能。曾经很长一段时间 Windows 下 GUI 开发是没有“标准答案”的，Windows 内置程序少有使用 WPF 的，而是使用 C++以及一个私有的界面库。微软自家的大型软件，似乎只有 Visual Studio 使用了 WPF ，而且还是主界面 WPF+部分界面 MFC 混合，Office 使用的是另一套跨平台的界面库。.NET 系一直有一些细节问题。比如 Win7 只预装了 .NET 3.5 ，如果想免安装兼容 Win7-Win10 ，就得放弃一些新特性。WinForm 和 WPF 的主题风格和 Windows UxTheme 不一致，有种粗制滥造的感觉，比如 Win32 的 Common Control 基本都有一些过渡动画，WinForm 动画直接没了，WinForm 的菜单风格也与系统菜单不一致，WPF 更是完全没有使用 UxTheme ，而是自己搞了套主题，与系统主题相差较大，Qt 对系统主题的模仿都比 WinForm/WPF 细致得多。当然对于开发者来说开发效率是很高，主题也是要用第三方的，并不是什么问题，但在用户眼里，则是觉得 Windows 从来没有统一的界面风格，也做不到“程序包尽量小， 依赖尽量少”。说个题外话，为什么长期以来 Windows GUI 程序如此割裂？个人认为根本原因是因为微软强推 .NET 。自 21 世纪以来，许多新的操作系统都自带一套丰富的 API 及开发框架，比如 macOS ，以及后来的 iOS 、Android 等，但 Windows XP 仍然只有老旧的 Win32 API 。Vista 发布前夕，有传言称新的系统将要引入 WPF 等全新的开发框架，结果发布后发现 WPF 等是与 .NET 平台捆绑的，而 .NET 则是比较独立于 Windows 的，Windows 本身的 API 及开发框架并没有得到升级，微软也没向 .NET 提供 Win32 API 的 SDK ，想要使用，就得自己写一大堆声明。结果就变成了，旧应用没法渐进式升级，要升级只能重写。开发者想要获得良好的开发体验，就只能使用 .NET ，而使用 .NET 又很难访问底层 Win32 API ，WPF 的界面风格又与 Windows 本身的主题不统一。结果就是开发者要不然用 .NET+第三方界面库，要不然用 C++ Win32 controls ，要不然用其他的一些界面库。反观 macOS ，Objective-C 语言可以直接兼容 C/C++，系统中有内置风格统一、好用的界面库，自然许多开发者会倾向于使用系统提供的而不是第三方的。多年之后的 Win8 ，微软再一次犯了错误，虽然 Win8 终于在系统中加入了现代化的 API 及开发框架 / 界面库，但是绝大多数仅面向 Modern App(或者说 UWP)，而 UWP 缺少许多经典好用的 Win32 API 。个人认为微软是想通过 UWP 变相强迫开发者为他们的移动平台开发应用，因为如果允许桌面的 UWP 应用使用传统 Win32 API ，那自然很难移植到移动平台上。然而砍掉 Win32 API 这种行为动摇了桌面应用的根基，时至今日 macOS 都不敢砍掉 POSIX API ，因此许多开发者就直接拒绝使用 UWP 。在微软放弃移动平台之后，终于引入了 Xaml Island ，允许 Win32 应用使用 UWP 的界面库，开发者可以渐进式地把传统 C++ Win32 或者 .NET 应用的部分界面替换成 UWP Xaml 界面(WinUI)，同时微软也在开发 React Native for Windows 以及 .NET MAUI 等跨平台框架，这些框架底层使用系统内置的界面库，能保持界面风格与系统统一，开发者可以使用自己熟悉的语言开发，不需要学习新的语言。因此“没有任何其他方式的开发效率，开发体验以及功能效果能够与之媲美”这话，随着新框架的推出而变得不再准确了。个人推荐楼主使用 React Native for Windows ，因为背靠 WinUI ，有着与系统统一的风格，且系统内置界面库，不需要庞大的依赖 ( .NET 后续版本不再内置在系统中，需要单独安装或者随程序发布 )，后续也容易移植到其他平台。坏处则是不兼容老系统，应该至少要 Win10 1903 。

用汇编语言

你这是点名 c＃

wails golang 写的

不用 c++ 官方支持 依赖尽量少，这三点下来根本不剩几个了。

感谢各位大佬 ， 经汇总各方面建议 ， 现在基本确定两个方案 - 用标准 c＃ + WPF ， 都是正统微软支持的技术， 但唯一问题在于不跨平台 - react native for Windows, 可以跨平台， 也算微软支持的方案， 可用 web 技术， 但不支持老点的系统我后面可能会做这两个方案各做一个简单图形界面的 demo ， 再确定长期使用的方案很有价值 ， 至少不会没方向了

想想十年前的 WPF 刚问世不久有很多人吐槽，现今的 WPF 已经是.NET 界的扛把子了。

aardio 你试试

感谢各位回帖的同学把 Windows 的 W 大写了，强迫性真难受

其它乱七八糟不论，Xaml 确实是好文明

楼主还忘记说要支持哪些 Windows 平台了。这个也非常的关键。

主流就行， 也没想着非要兼容老的win10 以上就可以了毕竟开发方面， 兼容老的就意味这软件包更大， 开发更复杂， 等等问题， 往往不划算， 就和浏览器一样

生成的 exe 或程序包尽量小， 依赖尽量少--------------------------------------------------------就这一条已经把范围缩小到只有 Winform+C＃，WPF+C＃两位选手了。如果考虑尽可能的兼容老版系统（ XP ，Win 7 ），且性能不能太差，那么只有 Winform如果 GUI 比较花哨，定制较多，那么只有 WPF+C＃前面说 RN 做的 4M 就算小了，Winform 做的 GUI 几百 K 都能出来不错的界面，因为控件本身都是 win32api 提供的。

大小只是相对而已主要是如果利用 electron 等方案， 哪怕自己写的代码很少， 出来都是上百 M ， 这肯定不能接受的我个人的理想目标是， 如果自己写一个简单的 form ， 有几个按钮文本框等东西， 编译出来的软件包总体积在 10M 以下， 我认为就算合格了并没追求极限， 毕竟都知道越接近底层， 肯定中间东西越少， 出来软件包越小， 所以上面有人提议 react native 如果出来软件包只有几 M ， 我是可以接受的

擦，很久没见有人用 asm 写了，哈哈哈哈。你这建议还不如让他用 c+sdk 搞呢。上面好多大部分都是 winform ，其实 windows 常见 app 还是躲不过 cxx ，微信刚开始是用 delephi 写的(foxmail 同样，毕竟那个啥吧)，后来改成用 vc 他们自己的库了，我记得国内有个开源的 gui 库，大厂都用。当然写个规模不大的 WinForm 真香。顺便再吐槽一下，MFC 毁我青春。。。

WinForm 或者 electron 套壳

flutter

wxpython

unity?

看了评论区后 果断尝试了一把 react native for Windows环境装麻了，对于一个长期写 python 的人来说 这个环境的依赖有点多了。然后还是坚持跑起来官方提供的初始 demo 了。

听起来你想学的是.NET MAUI 之类的。但你要是想学了找工作的话，只能说吃力不讨好。单纯的自娱自乐的话轻便吧。

自己开发产品得

+1

🐎UI 一把梭

如果不嫌弃界面丑的话，真心推荐 WinForm 。 没有 WPF 这个选项。 折腾太多次了，每次回退到 WinForm 这选项时内心都是不甘心的，但是它用起来是真的舒服。

delphi 算么？ delphi 挺快的，这么多年也挺稳定的