简介这是一份 MinGW-w64 的 64 位离线安装包版本为 x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r核心编译器为 GCC 13.1.0面向需要在 Windows x64 环境下进行 C/C 原生开发的程序员。整个压缩包为 7z 格式共 18725 个文件包含编译工具链、头文件、链接库与文档主要文件类型包括 gcc/g 等可执行文件、dll 动态库、a 静态库、h/hpp 头文件以及 HTML 格式的 GCC 配套文档另有部分 Python 辅助脚本整体大小约 68.89MB。由于采用离线打包安装过程中不依赖网络适合内网或网络不稳的机器快速部署。选择 posix-seh-ucrt 线程模型与运行时组合兼容性较好可支持最新的 C/C 语言特性和标准库。已有 1637 人学习下载适合需要搭建本地编译环境或进行跨平台 Windows 开发的读者。开头第一次看到x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r这串文件名估计不少人都是一脸懵这到底是压缩包密码还是哪个发行版的代号其实它是一个非常标准的 MinGW-w64 编译器构建版本标识每一个用连字符分隔的字段都在告诉你这个编译器是给什么架构用的、用哪套线程模型、异常处理怎么做、链接哪个运行库。把这段字符串读懂了你就理解了 MinGW-w64 整个工具链的设计取舍也就能明白为什么有些 C/C 项目在 Windows 上必须用它来编译而不是直接装个 Visual Studio 了事。这篇文章就用这个具体的离线安装包做线索把 MinGW-w64 的版本命名规则、离线包的获取与校验、环境配置、和 MSVC 的差异以及我实际用下来踩过的几个坑一次性讲清楚。无论你是要在内网离线环境搭一套 C/C 编译工具链还是刚准备把项目从 Visual Studio 迁到开源工具链又或者只是想搞清楚posix、seh、ucrt这几个词到底意味着什么这篇都适合读。1. 版本串逐段拆解x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r里每段都代表一次取舍1.1 x86-64不只是64位安装包很多人一看x86-64就说哦64位版本严格来说不完整。x86-64描述的是目标 CPU 架构和 ABIApplication Binary Interface它既包括 64 位通用寄存器和指针宽度也包括函数调用约定、结构体内存布局这些底层规范。在 MinGW-w64 的世界里和x86-64相对的另一个常见前缀是i686后者是 32 位构建。选择x86-64意味着你编译出来的.exe或.dll只能在 64 位 Windows 上运行且默认启用 64 位指令集扩展。这比 32 位版本多出的不只是能用更多内存这么简单很多加密、音视频处理、科学计算代码在 64 位下能拿到更快的寄存器操作和更好的浮点性能。如果你的目标机器全是 64 位 Windows就不要犹豫直接选这个。1.2 13.1.0GCC 版本号的演进逻辑13.1.0是 GCCGNU Compiler Collection的版本号。GCC 是大版本号 小版本号 修订号的命名方式13表示这是 GCC 13 系列1是第一个特性更新.0是补丁级别。GCC 13 对 C 标准的支持已经相当完整默认情况下g会以-stdgnu17作为默认标准同时完整支持 C20 的大部分特性包括模块modules的初步实现、std::format、std::ranges的相关组件等。如果你在写现代 C或者要编译一些要求较高标准版本的第三方库选择 13 以上的版本会省掉很多因为语言特性不够而编译失败的麻烦。需要注意的是13.1.0是2023 年上半年左右的版本。电子产品的世界里没有最新只有更新但编译器这行稳定性和兼容性往往比追新更重要。13.x 这个版本线目前已经被大量开源项目验证过对 MSVC 兼容性、对常见第三方库的支持都趋于成熟拿来作为离线环境的固定工具链非常合适。1.3 posix vs win32线程模型的路线之争这个是版本串里最需要花时间理解的部分。MinGW-w64 官方构建提供两套线程模型posix和win32。win32 线程模型直接使用 Windows API 的CreateThread等底层接口作为线程实现编译出的程序不依赖额外的线程支持库体积更小。但它对 C11 标准库中的thread、mutex、future等线程设施支持得不好std::thread可能根本无法正常工作。posix 线程模型在 Windows 线程之上实现了一层 POSIX 线程接口基于 winpthreads 库让 GCC 可以完整支持 C 标准线程库也兼容 OpenMP、以及大量假设线程行为符合 POSIX 规范的第三方库。如果你打算写 C 多线程代码或者要编译的库内部用到std::thread、pthread_*接口那必须选posix版本。这就是为什么很多开源库的 Windows 构建说明里会特意写上请使用 posix 线程模型。有一点要提前说清楚posix线程模型在运行时可能需要额外的一个动态库libwinpthread-1.dll。后面部署到目标机器时要么把它一起复制过去要么在编译时加-static-libgcc -static-libstdc把相关库静态链进可执行文件不然会出现找不到 libwinpthread-1.dll的经典报错。1.4 seh vs sjlj vs dw2异常处理机制异常处理机制这栏在 64 位构建里基本都是seh32 位才常见sjlj或dwarf。它们的区别本质上是当程序抛出异常时运行时如何找到对应的 catch 块并展开调用栈。SEHStructured Exception HandlingWindows 原生结构化异常处理机制由操作系统和编译器协同处理。在 x86-64 上SEH 使用基于表的 unwind 信息异常抛出和捕获的开销非常低几乎没有额外的运行时成本。SJLJsetjmp/longjmp通过跳转表记录可能抛异常的代码位置。优点是兼容性强缺点是每次进入可能抛异常的代码块都要保存现场性能损失明显。DWARF基于 DWARF 调试信息里的展开表性能和 SEH 接近但通常只用于 32 位且对第三方库的交互要求更严格。选择seh意味着你拿到了异常处理性能最好的那条路径。在 64 位 Windows 下这基本没有争议除非你需要支持非常古老的系统或者特殊调试场景。1.5 ucrt运行库的兼容性关键ucrt是 Universal C Runtime 的缩写这是微软从 Windows 10 开始把 C 标准运行库拆出来的一个系统组件。在老一点的 MinGW-w64 构建里你经常会看到msvcrt这个标记它对应的是从 Windows 98 时代一路继承下来的老式 C 运行库。ucrt对比msvcrt最大的优势在于C99 和 C11 的标准函数支持更完整比如stdio.h里很多老库缺失的函数、snprintf、strtok_s这类安全版本接口都能正常使用。另一个更关键的点是UCRT 是 Windows 系统自带的组件MSVC 编译器默认也链接到 UCRT。这意味着使用ucrt构建的 MinGW-w64 程序在调用系统 API、处理标准输入输出、对接 MSVC 编译的库文件时底层运行库是一致的二进制兼容性更好。代价是如果你的目标系统是 Windows 7 且没有安装相应的 UCRT 系统更新程序可能跑不起来。在今天这个时间点绝大多数场景下都应该优先选ucrt不要再守着msvcrt了。1.6 rt-v11-r构建环境的版本信息最后这一段rt-v11-r最容易被忽略但它其实记录了 MinGW-w64 构建环境的版本。rt-v11是 MinGW-w64 源码树的一个构建标签r代表 revision修订版后面的数字是具体修订号。它相当于告诉你这个编译器是用 MinGW-w64 哪个版本的源码和构建脚本打包出来的。MinGW-w64 本身不是一个编译器而是一套让 GCC 能生成 Windows 可执行文件的头文件和导入库集合。所以同样的 GCC 13.1.0配不同版本的 MinGW-w64 运行时源码生成的二进制在兼容性上会有细微差别。日常使用中你不需要记住每个rt版本对应什么只需要知道如果某个第三方库要求MinGW-w64 至少是 rt-v10 或更高那这个rt-v11就是满足条件的。2. 为什么非得用离线包在线安装器的痛内网环境的需求2.1 在线安装器的问题出在哪很多刚接触 MinGW-w64 的人第一反应是去官网找个 exe 安装器。这个想法本身没错早期的 MinGW-w64 也确实提供过图形化安装器可以勾选组件在线下载。但这个方案实际用起来并不省心第一在线安装器需要从多个远程源拉取大量零散包服务器在国外的话下载速度很不可控经常是某个包下到一半就断掉然后安装器陷入重试-失败-重试的死循环。第二企业内网安全策略通常会拦截这种安装器运行时才去下载一堆可执行文件的行为最终结果就是安装器能启动但一个包都拉不下来。第三在线安装器每次装的组件版本是当前时间点的最新版换个时间换个机器再装一次得到的工具链版本可能就不一样了这在需要稳定复现构建的环境里是灾难。所以我现在养成的习惯是不碰任何在线安装器直接下载一个完整的离线包。2.2 离线包到底适合哪些场景离线安装包最适合这样几类场景隔离内网环境。物理断网或者出口受控的研发网里想装编译器唯一的办法就是把安装包拷贝进去。构建环境标准化。团队里所有 CI 节点、同事电脑全用同一个版本的编译器避免我这边能编你那边编不了的扯皮。反复部署。一次下载拷贝给十台机器每台解压配置哪怕其中八台没外网也能用。应急修复。生产服务器上程序崩溃需要编译一个带日志的修复版本不想在那台机器上装全家桶 IDE只想丢一个干净的gcc.exe进去用。2.3 如何选择具体的构建版本选离线包的核心原则是在满足需求的前提下尽量选 release 版本、选较新的大版本号、选posix线程模型、选seh、选ucrt。像标题里这个x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r就是一条非常标准的推荐组合。release说明它是正式发布版不是每天自动构建的 snapshotposix保证标准线程库可用seh保证异常性能ucrt保证运行库现代且与 MSVC 兼容。这几个条件同时满足基本能覆盖 95% 以上的日常 C/C Windows 开发需求。3. 离线包获取、校验与部署的完整操作清单3.1 获取渠道和文件识别获取离线包第一优先是去 MinGW-w64 项目官方的发布页面或者从被广泛认可的第三方分发站点比如 winlibs.com 这类专门做 MinGW-w64 构建的站点获取。下载前先看文件名确保它是编译器构建包而不是源码包。通常离线包是一个.7z压缩文件解压后的根目录下至少能看到bin、lib、include、libexec这些文件夹bin里有gcc.exe、g.exe、gdb.exe这些可执行文件。有时候你会看到文件名里多出win32或者dwarf后缀那是另一种线程模型或异常处理方式的构建如果没特别需求就绕开直接选本文标题这种标准组合最稳妥。3.2 下载后先做校验别急着解压离线包在网络上传播哪怕是从看起来很可靠的渠道下载也有被中间人篡改的微小可能。编译器一旦被植入后门你用它编译的任何产品都会带上恶意代码这是最可怕的一种供应链攻击。所以拿到压缩包后第一步就是校验哈希。Windows 下用 PowerShell 执行Get-FileHash .\x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r.7z -Algorithm SHA256然后在发布页面找到官方的 SHA256 校验值或者.sha256文件逐个字符对比。如果对不上宁可重新下载也不要解压特别是当你准备把编译产物交付给别人或者部署到生产环境时这一步绝对不能省。3.3 解压部署路径问题第一课解压这一步我强烈建议你遵守一个原则路径不要有空格和中文越简单越好。比如解压到C:\mingw64得到C:\mingw64\bin\gcc.exe这样的结构。不要解压到C:\Program Files\MinGW-w64这种目录。虽然现代 GCC 已经比早年容忍空格了但在 CMake、Ninja 等构建系统里带空格的路径依然会时不时引爆一些奇怪的解析问题。为一个工具链去趟这种浑水完全不值得。解压完成后可以检查一下C:\mingw64\bin下应该能看到gcc.exe、g.exe、mingw32-make.exe、gdb.exe等。如果这些文件都在说明包基本完整。有些构建版本还带了libwinpthread-1.dll和libstdc-6.dll这些动态库也在这个目录下运行时需要它们就在旁边。4. 从命令行到 IDE环境变量配置与首次编译验证4.1 配置 PATH 环境变量编译器解压好后要让系统能找到它核心就是配置 PATH 环境变量。右键此电脑→属性→高级系统设置→环境变量在系统变量里找到Path编辑并新增一行C:\mingw64\bin。如果只是想在当前命令行会话里临时测试也可以用set PATHC:\mingw64\bin;%PATH%还有一种方法是直接写入用户级 PATH用setxsetx PATH C:\mingw64\bin;%PATH%注意setx的坑它会把当前%PATH%展开后的完整值直接写死到注册表如果当前 PATH 里带了临时路径会把临时路径也永久固化进去。所以我一般推荐用系统环境变量图形界面来改稳妥可控。4.2 第一次编译冒烟测试配置完 PATH新开一个终端setx之后必须要开新终端才生效验证一下gcc --version g --version如果输出里能看到gcc.exe (MinGW-W64 ...) 13.1.0这样的字样说明编译器已经正常工作了。接着写一个最小的 C 程序测试编译流程#include iostream #include thread int main() { std::thread t([] { std::cout hello from thread std::endl; }); t.join(); std::cout hello mingw std::endl; return 0; }使用thread头文件是检验posix线程模型是否正常的最直接方法。如果你的编译器是win32线程模型编译这行代码很可能报错或者链接失败。把下面的命令敲进去g -stdc17 -O2 test.cpp -o test.exe如果没有任何警告错误test.exe能正常输出两行文本那这套 MinGW-w64 工具链的核心部分就已经完全可用了。4.3 接入 VSCode 和 CMake绝大多数人不会只停在命令行接下来会把它接进 VS Code 或 CLion。在 VS Code 里安装 C/C 插件后在.vscode/c_cpp_properties.json里指定{ configurations: [ { name: MinGW, compilerPath: C:/mingw64/bin/g.exe, cStandard: c17, cppStandard: c17, intelliSenseMode: windows-gcc-x64 } ] }如果是用 CMake 构建在 CMakeLists.txt 旁边执行cmake -S . -B build -G MinGW Makefiles -DCMAKE_C_COMPILERgcc -DCMAKE_CXX_COMPILERgMinGW Makefiles生成器会让 CMake 调用 MinGW 自带的mingw32-make这是 Windows 下最推荐的方式。也可以用-G Ninja前提是你单独装好了 Ninja。4.4 完整工具链的自检清单新环境配置完我习惯跑一遍这个自检流程确认工具链没有隐藏问题gcc --version确认版本号是 13.1.0且输出里带posix字样。编译一个使用thread的程序确认线程库可用。编译一个调用printf并snprintf的程序确认 UCRT 的运行时函数正常。运行gendef或dlltool在bin目录里确认 MinGW-w64 的辅助工具都在。只要这四条通过就说明这个离线包没白下后面可以放心写业务代码了。5. MinGW-w64 与 MSVC 的差异都是 Windows 编译器差别比想象中大5.1 为什么开源项目偏爱 MinGW很多从 Visual Studio 转过来的开发者第一眼看到 MinGW-w64 会很不适应没有.sln项目文件没有 IntelliSense连 Release/Debug 的配置都是 makefile 或 CMake 里的参数。但开源社区偏偏大量使用 MinGW原因很现实第一它是一套完整的开源工具链没有许可证和授权成本。第二它和 Linux 下的 GCC 工具链使用方式几乎一致同一个 CMakeLists.txt 在 Linux 和 Windows 下都能跑跨平台维护成本低。第三很多开源库FFmpeg、libcurl、OpenSSL 等的 Windows 官方预编译包用的就是 MinGW-w64 工具链你拿到源码自己编也能轻松对齐。5.2 底层差异对照我整理了一张表把两边核心差异列出来方便大家对照对比维度MinGW-w64MSVC底层编译器GCCcl.exeC 标准库libstdcMicrosoft STL运行库UCRT / msvcrtUCRT默认调试器GDBVisual Studio Debugger构建系统Make/Ninja/CMakeMSBuild/CMake二进制兼容与 MSVC 不互通与 MinGW 不互通异常处理SEH/SJLJ/DWARFSEH许可证GPL/公共许可商业授权附带免费社区版最关键的是二进制兼容性这一行。MSVC 编译出的.lib与 MinGW-w64 编译出的.a并不能直接互相链接因为两者的 C ABI名称修饰规则、异常处理元数据、结构体布局细节完全不同。同一个第三方库用 MSVC 编一份、用 MinGW 再编一份是常有的事。这也是为什么很多库的发布页面会提供x64MSVC 版和mingw-w64两个版本的预编译包。5.3 什么时候我应该用哪个我的经验是如果你要维护 Windows 独占的商业项目深度依赖 Visual Studio 的调试器、性能分析器、IntelliSense那继续用 MSVC 就好。如果项目本来就在 Linux 下用 GCC 构建只需要额外产出一份 Windows 版本那 MinGW-w64 是成本最低的选择CMake 一套配置两边复用。如果要编译和开源生态强绑定的库比如从源码构建 FFmpeg、Boost、Qt开源版MinGW-w64 通常比 MSVC 省事因为开源社区的脚本默认围绕 GCC 写。6. 使用离线 MinGW-w64 编译时的几个真实教训6.1 CRT 不匹配导致的只可意会的编译错误ucrt版本默认链接到 Windows 系统自带的 Universal C Runtime。如果目标机器是 Windows 7且没装 UCRT 更新程序在启动时会直接报缺少 api-ms-win-crt-runtime-l1-1-0.dll之类的缺失错误。解决办法是在编译时加g -static -static-libgcc -static-libstdc把运行库全部静态链接进可执行文件。但注意-static并不能把 UCRT 静态链进去UCRT 是系统组件不是你能静态打包的。如果必须跑在 Windows 7 且没打补丁的机器上就得考虑换msvcrt构建版本了。6.2libwinpthread-1.dll丢失的连锁反应使用posix线程模型编译出的第一个程序如果直接拷到别的机器上运行最常见的报错就是找不到 libwinpthread-1.dll。我从一开始就建议凡是准备对外分发的 exe统一用下面这条命令编译g -stdc17 -O2 -static-libgcc -static-libstdc main.cpp -o app.exe这样能把 libgcc、libstdc 全静态链接进去只有 winpthread 可能还得动态依赖。再保险一点直接把C:\mingw64\bin目录下的libwinpthread-1.dll复制到 exe 同目录双保险。6.3 路径空格和\vs/的折腾这点前面提过我在这里再强调一次MinGW 工具链里的工具大多源自 Unix 世界它们能识别/但 Windows 自带的一些脚本、IDE 插件时不时会往配置里塞\。最稳妥的做法是所有自定义路径统一写成正斜杠/比如C:/mingw64/bin/g.exe。不要低估一个反斜杠能让 CMake 崩溃的破坏力这种问题排查起来特别消磨耐心。6.4 静态编译与杀毒软件的亲密接触有一次我为了交付一个独立 exe加了全部静态链接参数结果编译出的文件体积从几百 KB 涨到好几 MB而且目标机器上的杀毒软件直接报毒。原因是编译器把异常处理表、调试符号和一堆运行库初始化代码都压进去了部分安全引擎的行为检测对这种大而全的可执行文件比较敏感。解决办法不是放弃静态编译而是注意两点一是尽量用 release 版本且去掉调试符号二是对编译产物做一次数字签名。纯内部使用的工具还好要外发给客户的话最好提前拿主流杀毒软件扫一遍免得交付当天被对方的 IT 拦下来。6.5 调试器版本和 GCC 版本要对齐最后提醒一个很多人忽略的细节MinGW-w64 的多个构建版本虽然都带gdb.exe但 GDB 和 GCC 的版本是两套独立的版本线。如果编译器很新而 GDB 太老调试时会遇到无法读取 DWARF 调试信息之类的问题。所以选离线包的时候不要只看 GCC 版本顺手确认一下包内 GDB 的版本。GCC 13.x 对应的 GDB 至少应该是 13.x 或更高调试体验才会正常。我自己现在维护的工具链就是把这套x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r离线包解压到C:\mingw64然后配合 VS Code 和 CMake 一起用。最省心的一个用法是先手动编译一次最小的 C 程序确认线程和异常都正常再用 CMake 配置整个项目。这样即使后面遇到问题也知道是构建脚本的问题而不是编译器本身的问题。如果你也是第一次配置 MinGW-w64 的离线环境建议你也按这个顺序走一遍比东搜一个教程西看一篇文档要高效得多。本文还有配套的精品资源点击获取