简介面向Windows开发者的MinGW 64位离线安装包基于GCC 13.1.0满足C/C程序编写与编译需求。版本采用posix线程模型、seh结构化异常处理及ucrt通用C运行时库兼容64位Windows系统适合构建原生64位应用。整个资源以7z格式压缩共18725个文件大小仅68.89MB除核心编译器gcc、g与链接器外还包含丰富的头文件、静态库、动态库以及Python辅助脚本并配有数千个HTML帮助文档便于查阅和二次开发。包体紧凑完整无需联网即可完成安装对网络受限或偏好本地构建环境的用户尤为实用。资源内部目录结构清晰bin、lib、include等模块划分明确便于快速定位所需工具和库文件。同时它提供从预处理、编译、汇编到链接的一整套工具链支持现代C标准方便学习操作系统级编程和跨平台开发。目前已有1637人学习/下载是快速搭建Windows下GCC开发环境、编译学习C/C的可靠选择。1. 这个下载包到底解决什么问题先说结论x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r是 MinGW-w64 项目在 GCC 13.1.0 时代的一份离线安装包完整打包了 64 位 Windows 下的 C/C 编译器工具链。换句话说下载这份东西解压配好环境变量你就能在 Windows 上直接敲gcc命令编译 C/C 程序不需要装 Visual Studio 那个动辄几个 GB 的庞然大物。很多人第一次看到这串名字第一反应是“这啥玩意儿怎么这么长”。但说实话这不怪 MinGW 项目组矫情因为编译器的构建配置实在太多样了不写在文件名里用户根本分不清该下哪个。后面我会把这串名字逐段拆开讲透你以后看到任何 MinGW-w64 的压缩包都能一眼判断适不适合自己的需求。我知道你可能更关心的是为什么微软自己有 MSVC 编译器还有必要折腾 MinGW我个人的体会是——Linux 下写的 C/C 代码迁移到 WindowsMinGW 是最省事的路径你要用 CMake 配合一些开源库比如 FFmpeg、SDL2 的某些构建分支MinGW 也是绕不开的选择更别提 Code::Blocks、Dev-C 这类开源 IDE 的默认编译器就是 MinGW。我的经验是能离线安装是最大的优势——我深度使用后感觉对于网络不太稳定、或者在内网环境干活的朋友有个离线包真的能救急。2. 逐段拆解安装包命名每个字符都有含义2.1 架构标识x86-64 是 64 位别下错版本“x86-64” 指的是目标架构也常写成x86_64、amd64代表编译器生成的是 64 位程序。你可能会问现在的电脑不都是 64 位的吗没错但编译器的位数决定了它能生成什么目标代码x86-64生成 64 位程序可访问更大内存性能更好。现代 PC 的默认选择。i686生成 32 位程序老软件兼容、以及某些特定场景比如内核驱动调试才需要用。注意一点64 位编译器里有些工具链是x86_64-win32-seh还是x86_64-posix-seh这样组合出现的千万别只看前面一段就完事。在 64 位宿主上装 32 位工具链虽然也能跑但你需要额外兼容 32 位库很多人第一次编译就会踩这个坑。2.2 版本号13.1.0 代表 GCC 版本13.1.0是 GCCGNU Compiler Collection的版本号也就是编译器本体。GCC 13 这个版本在 2023 年发布带来了不少 C/C 标准的新支持比如C 的std::expected、std::flat_map等新特性逐步完善C23 标准的部分新语法支持更好的 LTO链接时优化性能对 OpenMP 和 OpenACC 的持续改进你说 “最新版” 其实得看你怎么定义。GCC 版本迭代到现在已经出到 13 甚至 14、15 了。但实际工作中源码兼容性比版本新更重要。比如说某些 Linux 内核版本或大型 C 项目可能要求对应的 GCC 版本范围你装一个太新的 GCC 去编译老版本代码反而会因为头文件变化导致报错。13.1.0是一个相对稳定、社区反馈较好、兼容性也平衡的版本如果你不是非要尝鲜新特性用它做日常开发完全够用。2.3 线程模型posix 和 win32 的差异这一节在 MinGW 圈子里经常有人争论。posix和win32指的是线程模型的实现方式。posix版本使用 POSIX 线程模型pthreads支持std::thread、std::mutex等 C 标准库多线程功能还支持 OpenMP、GNU 的跨平台线程库。对写 C11 以后代码的人来说这是更友好的选择。win32版本直接使用 Windows 原生线程 API 实现编译出的程序体积略小、运行时依赖略轻。但代价是部分依赖 POSIX 语义的库和代码可能编译不过或者出现奇怪的兼容性问题。我的建议很直接如果你写 C17/C20 或者用的库比如 Boost.Thread、Catch2、某些图形库内部用了std::thread直接选posix没有悬念。如果你只是用纯 C 写一些底层模块不涉及多线程标准库win32也可以。但作为通用开发环境posix是最省心的。你拿到的这个包恰好是posix算是比较主流的选择。提示很多开源项目在 Windows 上用 MinGW 编译时会在 CMake 里检查WIN32还是POSIX线程模型。选错之后通常表现为链接阶段报错提示找不到pthread相关符号。我见过不少新手在 Stack Overflow 上求助最后发现就是线程模型下错了。2.4 异常处理模型seh 与 sjlj 的取舍seh是 Structured Exception Handling结构化异常处理的缩写这是 Windows 特有的异常处理机制。MinGW 的异常处理主要有三种变体模型全称性能表现兼容性sehStructured Exception Handling较好由 Windows 内核直接参与仅限 64 位与 MSVC 异常处理天然兼容sjljSetJump/LongJump较差异常路径慢跨平台通用32/64 位皆可dwarfDWARF 调试信息格式较好多用于 32 位跨平台支持好从使用角度讲seh是现代 64 位 Windows 上的最佳选择也是 MinGW-w64 官方推荐给大多数用户的默认配置。它有两个明显优点异常处理性能更高。sjlj在函数入口处都要设置跳转上下文即便函数根本不抛异常也会付出额外开销seh则只在真正抛异常时介入正常代码路径更快。和 Windows 原生生态兼容。使用seh构建的 DLL 可以更好地与 MSVC 构建的模块互操作因为底层异常处理机制一致。sjlj还有一个典型的使用场景就是需要兼容 32 位程序或者在 Linux、macOS 上交叉编译 Windows 程序时。但你这个包是 64 位且工作目标就是 Windows 原生选seh完全正确。2.5 C 运行时库ucrt 与 msvcrt 之争这部分最容易被忽略但恰恰是“能不能跑起来”的关键。ucrt是 Universal C Runtime 的缩写它是 Visual Studio 2015 之后 Windows 10 默认随系统提供的 C 运行时库。msvcrt则是老式的、伴随早期 Visual C 分发的运行时。我给你的核心建议是优先选择ucrt。从 Windows 10 开始ucrt是系统组件UCRT 相关 DLL 基本都在系统目录中不需要额外拷贝到程序目录。msvcrt版本通常用于极老的程序兼容或者为了追求最小的运行时依赖。但在新系统上可能出现 API 缺失等问题。ucrt相比msvcrt最直观的优势是C 标准库函数覆盖更全面比如新增了不少安全函数_s后缀对新标准C11、C17的支持也更好。你在编译时如果用了snprintf这种 C99 函数在老的msvcrt环境下行为可能不对ucrt就没有这个顾虑。13.1.0配合ucrt在 Windows 10/11 上几乎不用操心运行库缺失的问题。2.6 尾部标识rt-v11-r 是什么rt是 revision tag 的缩写v11代表 MinGW-w64 构建版本r表示这是经过修订的发布版本。这个和 GCC 版本是两个维度的概念GCC 版本是编译器本体的版本rt-v11是 MinGW-w64 项目自己维护的运行时和头文件的修订号。它主要影响的是 Windows API 头文件的完整性和一些底层库的细节修正。一般来说这部分不用太关注拿到手能用就行但如果遇到某些 Windows API 相关函数缺失可以看看是不是 MinGW-w64 修订版本太旧。你这个v11相对比较新了。3. MinGW 与 MSVC 的区别为什么开发者愿意选 MinGW这个话题隔三差五就有新人在社区里问。我用一个不太严谨但特别容易理解的类比MSVC是微软自家的“专属工具链”像是原厂配件。它的强项是和 Windows API、Visual Studio、调试器无缝配合弱项是不跨平台你在 Linux/macOS 上没法直接用 MSVC 编译代码。MinGWMinimalist GNU for Windows是 GNU 工具链的 Windows 移植版像是第三方兼容配件。它把 GCC、GNU Binutils、GNU 调试器 GDB 都搬到了 Windows 上你的 Makefile 和 CMakeLists.txt 可以轻松跨平台复用不用为每个平台单独维护一套构建脚本。具体到实际体验有几点我深有体会编译速度同级别的优化选项下MSVC 和 GCC 速度差别不大但 GCC 在 Linux 生态中的测试更充分。如果你在写高性能计算或底层库GCC也就是 MinGW往往能发挥出更好的优化效果。标准支持GCC 对 C 新标准的支持一直领先很多新特性都是 GCC 先实现MSVC 紧随其后。所以要用到最新 C 特性MinGW 是个不错的选择。生态衔接很多开源库的 Windows 构建说明里明确写了“支持 MinGW-w64”。用 MSVC 去编译这些库时常常需要为每个库单独调整编译选项而 MinGW 则相对顺畅。我编译 SDL2、FreeGLUT 这些图形库时用 MinGW 基本一把过。调试体验MSVC 的调试器集成度确实高但 GDB 也一直在进步配合 VS Code 的 C/C 扩展日常断点调试完全够用。对于 gdb 调试启动后file、break、run、print这一套命令虽然不如图形化调试直观但功能一样不少。4. 离线安装实操解压、配环境变量、验证一条龙4.1 下载与解压这个离线包是一个压缩文件通常下载下来是.tar.xz格式在 Windows 上可能是.zip或.7z。如果下载到的是.tar.xzWinRAR、7-Zip 新版本都能直接解压不需要额外装 Linux 的 tar。建议解压到一个纯英文路径且不要带空格。比如C:\mingw-w64\或D:\tools\mingw64\。为什么这么强调因为有些构建工具尤其是老版本的 CMake、autotools在路径有空格时会解析失败报一些莫名其妙的错误。我见过有人把 MinGW 装在C:\Program Files\下结果一堆脚本跑不动最后只能重装。解压完成后你会看到几个核心目录bin存放所有可执行文件gcc.exe、g.exe、gdb.exe、mingw32-make.exe、ld.exe 等includeC/C 标准头文件存放处lib标准库和链接脚本所在libexec编译器内部辅助工具4.2 环境变量配置这是安装过程中最关键的一步。配置环境变量的目的是让命令行工具cmd 或 PowerShell能在任意目录下直接访问gcc等命令。操作步骤如下右键“此电脑” → “属性” → “高级系统设置” → “环境变量”在“系统变量”里找到Path双击编辑点“新建”把bin目录完整路径填进去比如C:\mingw-w64\mingw64\bin一路点“确定”保存之后需要重新打开命令行窗口环境变量才会生效。如果你用的是 Windows Terminal可以直接关掉重开。4.3 验证安装是否成功重新打开 CMD 或 PowerShell依次敲三个命令gcc --version g --version gdb --version我的实操经验是这三个命令只要第一个能正常输出版本号后面基本就稳了。如果提示“不是内部或外部命令”先从两个方向排查路径是否写错经常有人把bin路径写成了mingw64的根路径新开的终端是否还是旧缓存的环境Windows 在环境变量修改后常需要重启终端再进一步测试实际编译能力写一个最简单的 Hello WorldC:\ echo int main(){return 0;} test.c C:\ gcc test.c -o test.exe C:\ test.exe如果最后没有报错且正常退出说明 MinGW 工具链已经可以正常工作了。4.4 配置完环境后的日常编译流程已经配好环境日常编译 C 或 C 项目的习惯做法是# 编译 C 文件 gcc -Wall -O2 -o app.exe main.c -lm # 编译 C 文件带调试信息 g -Wall -g -stdc17 -o app.exe main.cpp # 多文件编译 g -c util.cpp -o util.o g -c main.cpp -o main.o g util.o main.o -o app.exe上面的-Wall开启警告-O2优化-g生成调试信息-stdc17指定 C 标准。这些参数跟 Linux 下的 GCC 用法完全一致这就是 MinGW 最大的价值——你在 Linux 上学到的 GCC 技能直接平移过来。5. 常见问题排查与避坑经验5.1 下载的包解压后没有 gcc.exe这种情况大概率是你下载错了包。MinGW-w64 的官方发布页面中有的压缩包是源码包不是二进制包。务必选择文件名中带有release-posix-seh-ucrt这类字样的二进制发行版而不是类似gcc-13.1.0.tar.gz这种源码包。另外MinGW-w64 的发布站点有几个不同的维护分支比如 WinLibs、MinGW-builds、MSYS2 等它们的目录结构略有不同有的直接解压就能用有的需要额外处理。5.2 编译时提示undefined reference to pthread_create这个错误在 MinGW 圈子非常经典。原因分两类如果你用的是posix线程模型当前这个包就是本来应该自带 pthread 支持但仍需要在编译时加-pthread或-lpthread链接参数如果你下载的是win32线程模型的包那么pthread这个符号就没法直接解析需要额外装 winpthreads解决办法按顺序试gcc test.c -o test.exe -pthread如果还报错检查你用的头文件是不是#include pthread.h。确保链接命令里显式加了-pthread。5.3 编译出的 exe 在其他电脑上报缺少 DLL这个问题在新手阶段最容易遇到。用 MinGW 的ucrt版本编译的程序除了标准的系统 DLLkernel32.dll、user32.dll 等很多时候还需要libgcc_s_seh-1.dll、libstdc-6.dll、libwinpthread-1.dll这几个运行时 DLL。解决思路有三个把需要的 DLL 和 exe 一起分发。在bin目录里找到这些 DLL 拷贝到 exe 同目录下这是最快但最不优雅的方式。静态链接运行时。编译时加-static-libgcc -static-libstdc参数这样编译出的 exe 对 MinGW 运行时 DLL 的依赖会大大减少。完全静态编译。加-static参数把所有运行时都静态链接进 exe。代价是编译出的文件体积明显变大。我最推荐第二种方式多数场景下-static-libgcc -static-libstdc就够了既保证可移植性又不用太操心体积。5.4 Code::Blocks 25.03 自带 MinGW还需要单独装吗Code::Blocks 25.03 的安装包现在确实集成了 MinGW 工具链安装时勾选集成组件即可。但这里有个细节它自带的 MinGW 版本往往比你单独下载的最新版旧而且band的下载是随 IDE 一起发布的不是实时更新的。我的建议是如果你只是用 Code::Blocks 写课程作业或小工具自带的 MinGW 完全够用如果你要处理比较复杂的项目、需要使用最新标准特性还是用独立安装的13.1.0更靠谱。你甚至可以两者共存在 Code::Blocks 的 Settings → Compiler → Toolchain Executables 里把编译器路径手动改成你新装的 MinGW。5.5 VS 2022 的开发者命令行可以用 MinGW 编译吗可以但需要注意一件事MSVC 和 MinGW 的工具链不要混用。VS 2022 自带的 Developer Command Prompt 默认把 MSVC 的 cl.exe 路径放进了 PATH如果你这时再调用 MinGW 的 gcc.exe两者可能因为运行时不同导致链接错误。解决方案是先确认你想用哪个编译器然后临时调整 PATH# 只保留 MinGW 的路径在命令行中覆盖 PATH set PATHC:\mingw-w64\mingw64\bin;%PATH% gcc --version这样就能在 VS 终端里使用 MinGW 了但我不建议长期这么干因为环境变量很容易搞混。更稳妥的做法是直接开 CMD而不是 VS 的开发者命令行。6. 我的实际使用经验与额外建议这几年来我在 Windows 上用 MinGW 编译过的项目类型比较杂有跨平台的 CLI 工具、有调用 OpenGL 和 SDL2 的小游戏、有用 freeglut 做的图形学实验、还有对接串口和网络通信的嵌入式上位机程序。整体感受是MinGW-w64 的稳定性相当可靠尤其在配合 CMake 构建体系时几乎能做到与 Linux 下完全一致的体验。有一个技巧想分享给从 Linux 转到 Windows 的朋友MinGW 安装目录里的mingw32-make.exe相当于 Linux 下的make但它默认读取的 Makefile 规则略有不同尤其是在 Windows 上涉及路径分隔符时。很多项目在 Linux 下用make好好的到 Windows 下用mingw32-make就各种奇怪报错。更推荐的做法是直接用 CMakecmake -S . -B build -G MinGW Makefiles cmake --build build指定-G MinGW Makefiles生成器CMake 会帮你处理好 MinGW 相关的编译细节比你手动写 Makefile 省心太多。另外一点是关于 MinGW 与 MSYS2 的关系。你可能看到很多教程推荐直接装 MSYS2然后从 MSYS2 的软件仓库里安装 MinGW-w64 工具链。这种方式当然也行而且包管理非常方便能直接pacman -S mingw-w64-x86_64-gcc装好。但这个离线包的价值在于它不依赖任何包管理器也不依赖网络源非常适合把工具链拷贝到 U 盘或者内部服务器上复用。我经常在外场没有稳定网络的设备上编译小工具有一个这样的离线包在手里帮了大忙。最后给新手一个建议下载 MinGW 版本时不用过度纠结是不是“最新”。13.1.0 这个版本已经能覆盖绝大多数 C/C 开发需求与其花时间追新版本不如把精力放在熟悉编译参数、构建工具链、调试器用法这些更持久的能力上。真正的高手用哪个版本都能把活儿干漂亮——但选对线程模型和异常处理模型能让你少走很多弯路。如果后面有时间我还可以写一篇基于这个工具链结合 CMake 和 VS Code 搭建完整开发环境的文章那套组合拳用熟了之后你基本就告别 Visual Studio 庞然大物的依赖感了。本文还有配套的精品资源点击获取