WinLibs下载页面上那个UCRT和MSVCRT的选择估计劝退了不少刚入坑的人。我当年第一次打开这个网站看着满屏的GCC版本号和zip包第一反应是直接关掉去找一键安装包。后来用顺手了才发现WinLibs其实很简单一个解压即用的GCC/MinGW-w64工具链专门给Windows平台准备适合不想折腾MSYS2、也不需要Visual Studio那种大块头的C/C开发者。真正需要在下载前想明白的就是UCRT和MSVCRT这两个运行时怎么选。这篇把我自己的理解、选择逻辑和完整安装过程写一遍按这套思路来5分钟就能把环境跑起来而且不会再纠结。1. WinLibs到底是什么为什么装个编译器还要做选择题1.1 一个解压即用的GCC工具链先把这个东西的本质说清楚。WinLibs是第三方维护的Windows平台GCC工具链发行版核心内容是MinGW-w64编译器套件也就是GCC在Windows上的移植版本。它不是像MSYS2那样带完整包管理器的生态也不是Cygwin那样上面套了一层POSIX模拟层的环境而是一个很纯粹的“编译器压缩包”下载、解压、配置PATH然后就得到一个能用的gcc、g、gdb、make以及一堆Windows原生库和头文件。我觉得它最适合的人群是这几类想用纯GCC写C/C但不想装Visual Studio的在学校或者实验室用Linux写代码、回Windows临时编译提交作业的以及做跨平台项目、需要验证代码在GCC下能不能过的Windows开发者。WinLibs解决的问题很直接给你一套不自带奇怪依赖、不强制包管理的原生Windows编译器。有人会问那MSYS2不也能做到吗能但MSYS2默认把工具链、包管理器、shell环境全揉在一起对“我只要一个编译器”的人来说有点重。WinLibs就是那种拿来即用的发行版它的更新节奏也快基本跟着新版本GCC走这也是我长期用它的原因。1.2 下载页面那一堆选项分别代表什么打开winlibs.com你看到的不是一个大大的“Download”按钮而是一排参数很多人就是在这里开始懵的。我简单拆一下架构x86_64代表64位i686代表32位。现在绝大多数电脑是64位Windows直接选x86_64不用犹豫。除非你明确要编32位程序给老设备用否则32位版本不需要碰。线程模型posix或者win32后面会单独说默认posix。异常处理模型SEH、SJLJ、DWARF64位版本基本是SEH一个选项后面会展开讲。运行时UCRT还是MSVCRT这就是本文的核心选择题。GCC版本号选最新稳定版就行网站一般会把最新版放在最上面。这些参数最后都会体现在文件名里比如我下载的那个包长这样winlibs-x86_64-posix-seh-gcc-14.2.0-mingw-w64ucrt-12.0.0-r1.zip。把文件名拆开看x86_64是架构posix是线程模型seh是异常处理模型gcc-14.2.0是GCC版本ucrt就是运行时类型。所以你下载的时候不是在做一道抽象选择题而是在选一个具体配置的工具链。2. UCRT和MSVCRT差在原生的“地基”2.1 先搞清楚“运行时”是什么很多教程默认你懂运行时其实这个坑不填上选择永远都是瞎猜。用一句话解释你写的C代码里那些printf、malloc、strcpy编译器不会真的逐个帮你实现而是去调用某个现成的库这个库就是C运行时C Runtime。Windows上的情况比较特殊。Linux系统自带glibc大家不用选但Windows上微软提供过好几代C运行时MinGW-w64编译出来的程序默认要跟其中某一个对接。UCRT和MSVCRT就是两个不同年代的对接对象。选哪个运行时直接决定了你的exe在别人电脑上依赖哪个系统DLL、能跑在哪些Windows版本上、标准库行为跟不跟得上现代C标准。2.2 UCRT微软在2015年后重新做的C运行时UCRT全称Universal C Runtime是微软在Visual Studio 2015前后重新设计的一套C运行时。它的定位就是替代老掉牙的MSVCRT解决标准库实现不完整、长期不更新、区域和字符处理混乱的问题。从Windows 10开始UCRT直接作为操作系统组件内置也就是说只要目标机器是Windows 10或Windows 11你的程序链接UCRT运行的时候不需要额外安装任何东西。UCRT最大的优势是“还在被维护”。它跟着Windows Update一起更新微软会修bug、补函数、调整行为C99和C11的符合度比MSVCRT高一大截。另外它在Unicode和区域设置上现代得多如果你跟中文、UTF-8、各种语言环境打交道UCRT会让你少掉很多头发。MinGW-w64从某个版本开始支持UCRT目标之后WinLibs的UCRT构建就一路做下来了目前是官网主推的默认项。2.3 MSVCRT二十多年前的老将MSVCRT对应的动态库是msvcrt.dll这个文件从Windows 95时代就在系统里源头可以追溯到Visual C 6.0那一代产品1998年左右。微软后来基本不再更新它它在现代Windows里存在的意义更多是“兼容老程序”。那MSVCRT为什么还没被淘汰因为兼容性这个属性太强了。它几乎出现在所有Windows版本上从XP到Windows 11都能找到msvcrt.dll所以编译出的二进制理论上可以跑得非常老的操作系统。早期MinGW和MinGW-w64默认链接的就是它大量历史遗留的预处理库、DLL、开源项目二进制都是按MSVCRT编译的。你在用这些老库对接自己的程序时如果能跟它保持同一个运行时能省掉一大批符号冲突和内存分配边界问题。2.4 一张表看透核心差异对比维度UCRTMSVCRT出身年代2015年随VS2015引入1998年VS6时代基本冻结系统内置情况Windows 10/11内置Windows 95以来全系列都有旧系统支持宗旨面向Win10老系统要额外补丁XP、Vista、Win7原生可用C99/C11符合度高较接近标准实现低部分函数缺失或行为古老Unicode/区域处理现代支持UTF-8 code page老式区域逻辑常见乱码更新维护Windows Update持续更新不再更新第三方库兼容新库基本都适配老MinGW预编译库常见看完这张表你可能会觉得那肯定选UCRT啊。确实对新项目来说UCRT是更优解但事情没这么绝对下面说选择逻辑。3. 到底怎么选默认UCRT特殊情况再回头看3.1 为什么默认选UCRT我给你一个直接结论如果没有任何特殊理由直接选UCRT版本不用问了。理由很朴素。第一你的开发机和目标机器大概率都是Windows 10或Windows 11UCRT内置部署零成本。第二UCRT还在被微软维护标准库行为更接近Linux下的glibc代码跨平台移植时少踩坑。第三现代第三方库尤其是这几年还在活跃维护的C/C库对UCRT的适配已经非常成熟继续绑着MSVCRT反而是给自己找麻烦。我自己的经历是早些年用MSVCRT版本编译一个用到了标准正则和字符转换的程序在Linux上跑得好好的到Windows上就出现各种诡异行为。后来查到根子是msvcrt.dll那套老掉牙的字符处理。切到UCRT之后代码一行没改行为就正常了。那次之后我所有新项目一律UCRT起步。3.2 出现这四种情况再考虑MSVCRT当然UCRT不是万能的下面这几种情况我建议老老实实切回MSVCRT必须兼容Windows 7及更早的系统。虽然Windows 7 SP1理论上可以通过补丁安装UCRT但实际部署中没人会为了你的程序去装一个不停机更新的运行库补丁。msvcrt.dll是系统自带的MSVCRT版本过去就能跑。你要对接别人提供的旧MinGW预编译DLL或静态库。这种老库基本是按MSVCRT ABI编译的你拿UCRT程序去链接轻则警告重则链接失败。最省事的方案是让工具链跟对方保持同一个运行时。项目里依赖了某些直接操作CRT内部结构的第三方组件比如钩子库、内存检测工具、插件注入器之类它们往往假设你用的是某个特定运行时。拿不准目标机器环境又没法逐个确认的时候。有些工业老设备、嵌入式相关主机装的是精简版Windows里面可能没跟着Windows Update长期维护MSVCRT这种“系统永远自带”的选项更保险。一句话总结面向现代Windows的新项目选UCRT面向老系统或老库选MSVCRT。两个版本可以同时下载到不同目录切换时改一下PATH就行所以不必把这个选择当成一锤子买卖。4. 5分钟完成安装与配置图文级步骤4.1 下载并解压打开winlibs.com网页顶部就是“Latest available builds”一般会列出几个GCC版本每个版本后面都有UCRT和MSVCRT两个链接。我以“x86_64 posix SEH UCRT”为例点对应的链接下载zip包。如果你选了MSVCRT也没关系后续步骤完全一样。下载完解压我建议放到一个干净、没有空格、不在受控目录下的路径比如C:\winlibs\mingw64或者D:\dev\mingw64。不建议解压到C:\Program Files倒不是说GCC跑不了而是UAC权限会让你以后生成的项目文件、临时文件都收到各种“拒绝访问”的干扰。解压工具的“Extract All”通常会自动创建一个同名文件夹注意最后确认一下顶层目录里能直接看到bin、include、lib这些文件夹。4.2 配置PATH环境变量这一步做完工具链才算真正能用。右键“此电脑”进入“属性”选“高级系统设置”点“环境变量”。想让你自己一个人用就编辑用户变量里的Path想让这台机器上所有用户都能用就编辑系统变量里的Path。点“新建”把C:\winlibs\mingw64\bin这一行填进去确定保存。如果你习惯命令行也可以用PowerShell追加到用户PATH一条命令的事[Environment]::SetEnvironmentVariable( Path, [Environment]::GetEnvironmentVariable(Path, User) ;C:\winlibs\mingw64\bin, User )注意这条命令每次执行都会追加一个重复项所以跑过一次就好别当成反复使用的脚本。无论用哪种方式配置完之后已经打开的终端窗口全部关掉重开PATH刷新需要新的进程环境。4.3 验证工具链是否可用新开一个命令行窗口依次执行下面几条命令gcc --version g --version where gcc where ggcc --version会输出类似gcc (WinLibs) 14.2.0 ...这样的信息where gcc会显示gcc实际路径。如果路径指向的是C:\winlibs\mingw64\bin\gcc.exe说明配置成功。这里提醒一句如果输出的是别的路径比如来自MSYS2、Qt自带的编译器、Strawberry Perl之类说明PATH里有多个GCC在抢位置后面第6章会专门说怎么处理。到这一步一个可用的WinLibs工具链就装完了全程确实用不了5分钟。5. 装完之后先验证一件事你链接的到底是哪个运行时5.1 写一个最小的测试程序装完不等于万事大吉。很多人下载的时候压根没注意自己点的哪个链接装完也不知道自己用的UCRT还是MSVCRT。我建议第一步就写个测试程序把运行时确认清楚。随便建一个目录比如C:\temp\test新建一个test.c写这个最基本的程序#include stdio.h int main(void) { printf(runtime test ok\n); return 0; }然后在命令行里编译gcc test.c -o test.exe如果编译过程没报错运行test.exe能看到输出说明工具链本身工作正常。5.2 检查exe实际依赖的DLL要确认你链接的运行时到底是哪个最直接的方法是看exe依赖哪些系统DLL。MinGW-w64自带的objdump就能干这活objdump -p test.exe | findstr DLL Name输出里会列出一堆DLL重点关注这两行的区别如果看到ucrtbase.dll或api-ms-win-crt-*.dll你用的是UCRT版本。如果看到msvcrt.dll你用的是MSVCRT版本。用PowerShell的话把findstr换成Select-String DLL Name就行。这一步的实操价值在于当你的程序在别人机器上报“找不到DLL入口点”之类的错时你能快速判断是不是运行时版本和系统环境不匹配排查起来会快很多。6. 实际使用中的常见坑与排查实录6.1 “gcc不是内部或外部命令”这应该是新手遇到最多的问题。出现这个提示先打开新终端再敲一次命令如果好了就是刚才没重启终端。如果还是不行检查PATH是否真的写进去了路径是否拼错。还有一个高频原因你编辑的是用户PATH但终端是以管理员身份打开管理员会话和普通用户会话的环境变量不一定同步。另外记得用where gcc看解析结果Windows在PATH里找命令是按顺序从上往下找的找到第一个就不往下看了所以顺序错也会导致“明明装了却调用了别的版本”。6.2 一运行就提示缺少libwinpthread-1.dll这是posix线程模型特有的问题。WinLibs的posix版本编译程序时默认动态链接libwinpthread库所以exe运行时需要同目录或PATH里有libwinpthread-1.dll这个文件就在你的mingw64\bin里。如果你只是在自己机器上跑通常没问题但你要是把exe拷给别人或者放进一个不包含bin目录的环境就会报缺失。两个解决办法一是拷贝时把libwinpthread-1.dll一起带上二是在编译链接时加-static参数让GCC把运行时依赖静态链接进去gcc test.c -o test.exe -static我个人做命令行小工具时都喜欢顺手加-static分发省心但要注意静态链接会让程序体积变大而且如果你依赖了其他要求动态链接的库这个方法就不适用了。6.3 编译出的程序拷到别的电脑上无法运行除了libwinpthread还可能缺libgcc_s_seh-1.dll、libstdc-6.dll等GCC运行库。具体缺哪个还是用objdump -p查依赖。拷程序给别人的时候要么把这个环境里bin目录下的相关DLL一起带过去要么就直接静态链接。对纯命令行工具和演示程序静态链接是成本最低的方案。如果你在做一个正经项目建议用打包工具把所需的DLL一起打进安装包里别指望每台机器都装了MinGW。6.4 装过MSYS2或其他GCC命令被“抢走”了很多人的Windows上不止一套GCCMSYS2装过、Qt装过、某个软件捆绑装过。这时候where gcc会列出所有能被找到的gcc.exe排在最前面的生效。解决办法很简单打开环境变量编辑窗口把WinLibs的bin目录上移到其他GCC目录之前。移动完之后重启终端再跑where gcc确认。还有一个更干净的做法不设置全局PATH而是写一个env.bat每次开编译终端先执行它临时把WinLibs加进当前会话set PATHC:\winlibs\mingw64\bin;%PATH%这样全局环境不会被搞乱还能按项目切换不同GCC我自己后来就一直用这种方式。7. 顺手把另外两个“选择困难”也解决掉7.1 posix线程还是win32线程WinLibs下载页的线程模型选项就这俩。一次性说清楚win32线程模型只提供Windows原生的线程API包装对C11标准库里的std::thread、std::mutex支持不完整posix线程模型则为GCC的libstdc提供完整的线程支持std::thread、std::async、std::mutex这些都能正常用代价是程序会依赖libwinpthread-1.dll。除非你有极其特殊的需求比如编译产物不能有任何额外的运行时DLL否则就选posix。现在业界默认也是posixWinLibs官方把posix放前面不是没道理的。写C线程代码的朋友尤其记住这句话win32线程模型会让你在编译期或者运行期被C标准线程库坑得很惨。7.2 SEH、SJLJ、DWARF到底选谁异常处理模型这个选项64位版本不用选默认SEH。SEH是Windows原生的结构化异常处理机制性能好跟其他Windows程序互操作也顺。32位版本里你会看到SJLJ和DWARF两个选项SJLJsetjmp/longjmp兼容性最好异常能跨DLL边界传播但性能差一些DWARF性能更好但要求整个程序涉及的所有DLL都统一用DWARF编译否则异常可能传不过去。结论64位系统直接SEH不用纠结真到了需要用32位i686版本的时代无脑选SJLJ就完了。这俩性能差距在现代CPU上体现得微乎其微兼容性反而更重要。7.3 GCC版本选哪个WinLibs官网上会同时提供多个GCC版本还有实验版本。我的建议是不搞特殊就选最新的稳定版一般就是网站列表里最上面那个。实验版本适合想尝鲜GCC新特性的玩家不适合当日常工作环境。如果你的项目有特定GCC版本要求比如必须用老GCC编译某个老代码库那就按需求选反正多下载几个版本放不同目录互不冲突切换成本几乎为零。最后再分享一个我自己的使用习惯。从一开始在群里问“UCRT和MSVCRT选哪个”到现在我踩过的坑主要集中在运行时依赖和PATH冲突上而不是编译器本身。所以我现在装WinLibs一定会顺手做三件事把下载的zip版本和文件名记录在项目README里方便以后复现环境写一个按项目激活PATH的bat脚本避免全局环境污染编译小工具一律加-static省去分发DLL的麻烦。这三个习惯看着不起眼实际帮我省掉了很多次“换台电脑就编译不过、跑不起来”的尴尬。你第一次装的话先把UCRT版本装好把第5章的运行时验证跑一遍然后正常写代码就行了——选UCRT还是MSVCRT这个纠结真不值得你花超过5分钟。