@nicaiwss ROCm: ?
反倒是 Intel 没有对标 CUDA 和 ROCm 的东西。ROCm 是和 CUDA API 级兼容，目前 PyTorch 官方唯二支持的 GPU 加速就只有 CUDA 和 ROCm 。在正经生产环境训练 AI 的话，排除一些公司自研的 AI 芯片，应该除了 CUDA 就只有 ROCm 了。

@idealhs
“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 。

推荐看看 https://www.bilibili.com/video/BV1sN411t76f

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

1. 一般不会，我试过几个路由器、光猫、开发板，在系统中用 poweroff 关机后都是不会自动启动的，需要拔插电源(或者一些开发板可以按开机键)才会启动。我手头上的 x86 电脑都不支持这种功能，没法测试。

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

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

@idealhs
“经典永不过时,大量工业软件都在使用它们,微软需要对这些技术负责”
MFC 也符合上述说法

“winform 甚至都可以基于.net8 开发”
最新的 VS2023 ，C++20 都能用 MFC

“并且他们的技术并不老旧一直在维护”
WPF 似乎一直只支持 Direct3D9 渲染，那么多年了也没有更新

WinForm 和 WPF 估计已经进入维护模式了，就和 MFC 、IE 一样，微软停止更新后一般也会维护很长一段时间，但这不能代表好坏。

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

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

Windows 和 Unix 进程的一大区别是，Unix 进程参数是字符串数组，而 Windows 进程参数只是一个字符串。因此 Unix 程序无需自行解析参数，参数是由 shell 解析成字符串数组的，而 Windows 则需要程序自己解析参数成字符串数组。楼上几位似乎都没提到这个根本区别。
@geelaw 有说法称 CommandLineToArgvW 和 MSVC CRT 内置的解析逻辑不同，cmd 的解析逻辑似乎也与前两者不同，我没有实际测试过情况如何，只是提醒一下可能遇到坑。

市面上 bat2exe 似乎都是写到某个位置然后用系统的 cmd.exe 运行。要完全不释放文件的话，系统的 cmd.exe 没有提供这样的功能，所以不能实现。
另外建议说说原始需求。

gc 语言就是不确定释放时机的，因此不能用 C++的 RAII 这种写法，只能用语言提供的 with 等机制。

带分类指的是什么？
可以看看纯纯写作是否符合要求。

@wzw 发行版提供的一般不是最新的。许多时候用一键脚本是为了能编译最新版的。

我选择用包管理装。
nginx 比较尴尬，官网虽然提供预编译包，但是 brotli 属于 nginx plus 收费版功能，官网的包并没有该插件。所以我目前用 Docker Alpine Linux 跑 nginx ，配置起来稍微有点麻烦。
PHP 的话大多数发行版都有第三方的预编译包，比如 CentOS 可以用 remi repo ，里面有最新的 PHP 。
MySQL/MariaDB 的话都有官方包。