简介：面向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++ 代码迁移到 Windows，MinGW 是最省事的路径；你要用 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是 GCC（GNU 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 的跨平台线程库。对写 C++11 以后代码的人来说，这是更友好的选择。win32版本：直接使用 Windows 原生线程 API 实现，编译出的程序体积略小、运行时依赖略轻。但代价是部分依赖 POSIX 语义的库和代码可能编译不过，或者出现奇怪的兼容性问题。
我的建议很直接：如果你写 C++17/C++20 或者用的库（比如 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 的异常处理主要有三种变体：
| 模型 | 全称 | 性能表现 | 兼容性 |
|---|---|---|---|
seh | Structured Exception Handling | 较好，由 Windows 内核直接参与 | 仅限 64 位，与 MSVC 异常处理天然兼容 |
sjlj | SetJump/LongJump | 较差，异常路径慢 | 跨平台通用，32/64 位皆可 |
dwarf | DWARF 调试信息格式 | 较好 | 多用于 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 编译代码。
- MinGW（Minimalist 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.xz，WinRAR、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 等）include：C/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 World：
C:\> 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 -std=c++17 -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生成调试信息，-std=c++17指定 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版本编译的程序，除了标准的系统 DLL（kernel32.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 PATH=C:\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就各种奇怪报错。更推荐的做法是直接用 CMake：
cmake -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 庞然大物的依赖感了。
本文还有配套的精品资源，点击获取
