MinGW下载安装与配置指南：从VS Code到Qt Creator避坑全解
下载 MinGW 装了一下午、最后发现编译出来的东西不是自己想要的，这种经历我太熟了。尤其是一帮做 Qt 和 VS Code 开发的朋友，被“MinGW 到底该从哪下”“官网为什么打不开”“下 32 位还是 64 位”“msvc 和 mingw 有什么区别”这几个问题卡得死死的。2026 年了，MinGW 的生态其实已经比十年前清爽了很多，但网上大量教程还在互相抄老旧的 SourceForge 链接，版本混乱得离谱。这篇东西我不跟你扯官方文档的官话，直接把整套流程从下载、版本识别、安装、PATH 配置到 VS Code 和 Qt Creator 里的落地方法，全按“踩过坑之后”的角度讲清楚。
1. 先弄清 MinGW 和 MSVC 的底细：为什么 Windows 上装个编译器这么绕
1.1 MinGW 到底是个什么东西
MinGW 的全称是 Minimalist GNU for Windows，说白了就是把 Linux/GNU 世界里的 GCC 编译器、GDB 调试器、binutils 工具链原封不动移植到 Windows 上的一套环境。它让 Windows 开发者能用 gcc/g++ 编译 C、C++、Fortran 等语言的代码，生成的 exe 可以直接跑在 Windows 上，不需要额外装虚拟机或者 WSL 中间层。
很多人知道 MinGW 这个名字，但 2026 年还在维护的其实是它的分支项目 MinGW-w64。老 MinGW 官方项目停留在 32 位时代，对 64 位系统的支持一塌糊涂，2013 年前后基本就没人更新了。现在你看到的大多数“MinGW 下载”，本质上下载的都是 MinGW-w64。这俩的关系用一句话形容：MinGW 是爷爷辈的原始计划，MinGW-w64 是继承者，支持 x64 和 ARM64，GCC 版本也是跟着上游持续更新的。网上还有极少数人引用的“mingw-get-setup.exe”那套老安装器，在 2026 年已经非常难用了，后面我会专门讲怎么绕开它。
1.2 MSVC 和 MinGW 的使用场景差异
MSVC 是 Visual Studio 自带的编译器，全称 Microsoft Visual C++。它和 MinGW 最大的区别在于三点：C/C++ 标准库实现、二进制兼容性、以及调试器配套。
表格按使用场景列开：
对比维度
MinGW-w64
MSVC
编译器前端
GCC 系列（gcc/g++/gfortran）
cl.exe
C++ 标准库
libstdc++（GNU 系）
Microsoft STL
二进制库格式
静态库 .a，动态库 .dll，导入库 .dll.a
静态库 .lib，动态库 .dll，导入库 .lib
调试器
GDB（gdb.exe）
Visual Studio Debugger / WinDbg
开源生态
对 CMake/Autotools 友好，基本不用改代码
很多开源库需要 vcpkg 编译或找预编译版本
标准支持速度
跟随 GCC 上游，新标准落地快
跟随 MSVC 版本，需较新 VS
IDE 常见组合
VS Code、Qt Creator、CodeBlocks、CLion
Visual Studio、VS Code + MSVC 模式
选型的逻辑其实很简单。如果你用的是 Visual Studio，那继续用 MSVC 最省事，官方库和工具链早就配好了。如果你要跑 CMake 项目、Qt widget 项目、或者某个只有 GCC 才能正确编译的开源库，那 MinGW-w64 是更稳妥的选择。很多人问我“是不是用了 VS Code 就必须用 MinGW”，这其实是个误解。VS Code 只是一个编辑器，它既可以调用 MSVC，也可以调用 MinGW，只是调用 MSVC 需要额外安装 VS Build Tools 并且接受那一大堆环境变量配置，而 MinGW 的配置路径轻量得多。
1.3 为什么“编译器”和“IDE”要分开理解
我见过不少新手把 CodeBlocks 和 MinGW 混为一谈。实际上 CodeBlocks 是 IDE，MinGW 是编译器工具链。CodeBlocks 安装包里有带 MinGW 的版本（比如热搜里提到的 codeblocks-17.12-mingw-setup.exe），装完之后 CodeBlocks 自己带了个编译器，但这只是 MinGW 的一个特定历史版本，不是你 2026 年手动下载的最新版。同理，Qt 安装器里的 MinGW 工具链通常也是它自带的特定版本。IDE 和编译器的关系，相当于微信和你手机里网卡的关系——微信负责交互界面，网卡负责真正收发数据。MinGW 是网卡，IDE 是微信，别买了个手机以为网线就不用插了。
2. 版本选择不踩坑：MinGW-w64、WinLibs、MSYS2，到底该下哪一个
2.1 三个常见下载渠道的定位
2026 年的 MinGW-w64 并没有一个“唯一官方下载站”，这点和很多人的直觉不一样。真正稳定的渠道主要有三个。
第一个是 SourceForge 上的 MinGW-w64 项目主页，地址是 sourceforge.net/projects/mingw-w64/。这个页面提供的是最原始的 GCC 交叉编译器压缩包，但它的下载方式对新手不太友好，页面里放的“MinGW-W64-builds”版本在 SourceForge 上已经很多年没更新了，经常只能看到 GCC 8.1.0 这类老版本。如果你只是随便做个练习，它能用；但如果要装新版本，这个渠道其实已经半废弃。
第二个是 WinLibs，地址是 winlibs.com。这是我目前最推荐的渠道。它提供的是预编译好的 MinGW-w64 工具链包，直接解压就能用，而且同时提供 GCC 13/14/15 等多个新版本，也集成了 GDB、make、binutils 等常用组件，打包非常干净。WinLibs 还分“仅仅编译器”和“带 MSYS2 基本系统”两种包，前者轻量，后者适合需要更多 Unix 工具的情况。
第三个是 MSYS2，地址是 msys2.org。它本质是一个 Windows 上的 Unix 环境，内置了 pacman 包管理器，你可以在里面安装 MinGW-w64 工具链、Qt、CMake、Python 等一大堆东西。MSYS2 的优势是包管理和升级方便，劣势是它引入了一层类似 Linux 的文件系统和环境变量（/mingw64 路径），理解和配置成本比 WinLibs 高。如果你打算长期搞 C/C++ 开源开发，MSYS2 很值得学；如果只是想快速配一个能编译的环境，WinLibs 更合适。
表格再直观一点：
渠道
适合人群
安装方式
主要风险
SourceForge MinGW-w64
临时使用、教学演示
压缩包解压
版本老旧，页面混乱
WinLibs
大多数日常开发
解压即用
无
MSYS2
重度开源用户、Linux 习惯用户
pacman 包管理
学习成本高，环境复杂
2.2 下载参数那些绕人的名词：posix/win32、seh/sjlj/dwarf
在 WinLibs 或者 SourceForge 的下载页面，你会看到一连串后缀，每个都是有实际影响的，选错了轻则软件闪退，重则链接失败。这里我把最容易懵的三个参数拆开讲。
第一个是架构：x86_64（64 位）和 i686（32 位）。2026 年默认选 x86_64，除非你明确要编 32 位程序。Qt 自带的旧版工具链或者某些老游戏插件需要 32 位时才会用到 i686。
第二个是线程模型（threads）：posix 和 win32。这个坑极大。posix 线程模型提供了完整的 C++11 std::thread 支持，并且兼容 POSIX 线程 API（pthread）；win32 线程模型用的是 Windows 原生线程接口，早年很多开源库为了兼容性都编译 win32 版本。问题在于二者生成的二进制文件不能混用，比如你用 win32 线程模型编译的 Qt 库，再用一个依赖 std::thread 的库去链接，很容易出现符号找不到的情况。我个人的建议是：如果你的项目用到了 std::thread、std::async、std::jthread 这类 C++ 多线程组件，直接选 posix。如果你在跑 Qt 5.9.9 这种老环境，尤其要看一下 Qt 官方预编译包是哪种线程模型，尽量保持一致。
第三个是异常处理模型（exception）：x64 架构下选 seh，x86 架构下是 sjlj 或 dwarf。SEH 是 64 位 Windows 上的标准异常处理格式，性能和兼容性都最好；sjlj 是跨架构兼容的兜底方案，速度慢一点；dwarf 只支持 32 位，不能跨 DLL 边界传播异常。简单粗暴的选择法：64 位下单 seh，32 位下单 dwarf。如果做的是需要异常穿过 DLL 边界的插件项目，再考虑 sjlj。
2.3 UCRT 和 msvcrt 运行时你也不能忽视
WinLibs 下载页还有一档选择是 runtime：UCRT 和 MSVCRT。MSVCRT 是老 MinGW 一直用的 C 运行时，兼容 Windows XP，但功能老。UCRT 是 Windows 10 之后微软官方推广的 Universal C Runtime，性能和安全性更好，现代 MinGW-w64 默认倾向用 UCRT。如果你的目标系统是 Windows 10 或更高，选 UCRT 没问题；但如果要兼容 Windows 7 或更老的系统，选 MSVCRT 风险更小。从这里也能看出，2026 年的 MinGW 下载已经不是“下个 exe 下一步下一步”那么简单，参数选错了，后面写十个 hello world 也看不出来，等真实项目一链接，一堆莫名其妙的报错全来了。
3. 安装和环境变量配置：压缩包解压后还要走完这几步
3.1 为什么我不用“官网安装器”而用压缩包
很多人搜“MinGW 官网下载”，点进去看到 Download 按钮，下载回来一个 .exe 安装器。这个安装器在 2026 年基本属于不可用状态，原因有三个：安装器依赖 mingw-get 在线拉取组件，网络稍差就卡死；默认源的包还停留在 GCC 6.x 时代；安装路径和历史软件包兼容性都差。所以我的建议是直接从 WinLibs 或其他镜像下载 7z 压缩包。解压之后，你会看到一个 bin 目录，里面躺着 gcc.exe、g++.exe、gdb.exe、mingw32-make.exe 这些核心文件。整个过程不需要任何注册表操作，也不需要管理员权限，这就是现代 MinGW-w64 的典型使用方式。
3.2 老式 CodeBlocks 自带 MinGW 的处理方式
如果你下载的是 codeblocks-17.12-mingw-setup.exe，它会把一个老版本 MinGW 自动安装到 C:\Program Files\CodeBlocks\MinGW。这个老版本对 CodeBlocks 项目来说是开箱可用的，但注意它和当前 MinGW-w64 的最新包不互通。CodeBlocks 的坑主要体现在：默认编译器路径写死、无法自动识别新版 MinGW、以及 32/64 位选择混乱。如果要用 CodeBlocks 搭配新版 MinGW，建议在 Settings -> Compiler -> Toolchain executables 里手动把编译器的安装目录改成新版 MinGW 所在目录，同时把 Program Files 里那个老路径删掉，否则编译时总有一个隐藏的 gcc 在捣乱。
3.3 PATH 环境变量配置的完整过程
环境变量配置是整个安装过程里最容易被忽略、却最常见报错的一步。无论你是先用 Win+R 打开 cmd 再输入 gcc --version 也好，还是直接在 VS Code 里打开终端编译也好，系统只会从 PATH 变量指定的目录找 gcc.exe。如果没配置，终端会报“gcc 不是内部或外部命令”，但很多人第一反应是重新下载编译器——完全没必要。
正确步骤如下：
右键“此电脑” -> 属性 -> 高级系统设置 -> 环境变量。
在“系统变量”或“用户变量”里找到 Path，双击编辑。
点“新建”，填入你解压 MinGW 的完整路径，注意要写到包含 gcc.exe 的那一层，也就是 ...\mingw64\bin。
确定保存后，关闭并重新打开所有终端窗口。
命令行输入 gcc --version，看到输出类似 gcc (MinGW-W64 ...) 15.0.0 就说明配置成功。
这里有一个非常容易踩的隐藏坑：如果你用了 MSYS2 的 MinGW-w64 环境，那你应该配置的路径是 C:\msys64\mingw64\bin，而不是 C:\msys64\usr\bin。后者是 MSYS2 自身的 Unix 工具链，gcc 也许存在，但它编译出来的目标格式和 Windows 原生程序可能有差异，行为完全不一样。
另一个容易踩的坑是 PATH 里同时存在多个 MinGW 目录。我之前装过 WinLibs 和 MSYS2，两个 bin 都在 PATH 里，结果终端里的 gcc 是旧版本，VS Code 里却调用新版本，两个版本混着用，链接时报了一堆莫名其妙的重定义错误。建议只保留一个 MinGW 的 bin 路径，其他全部删掉。
4. VS Code 配置 MinGW-64：从新建文件到跑通 Debug
4.1 安装 C/C++ 扩展和编译流程
VS Code 本身只是个壳，配置 MinGW 需要装微软官方提供的 C/C++ 扩展。打开扩展面板，搜索 C/C++，安装那个发布者名为 Microsoft、图标蓝色带 C++ 字样的插件即可。
装完扩展后，新建一个 test.cpp 文件，写一段最简单的代码，然后按 Ctrl+Shift+B 触发构建任务，VS Code 会询问你选择编译器，选择 g++ 对应的选项。这里实际上会自动生成一个 tasks.json 文件。如果你想手动控制编译参数，可以在项目根目录建 .vscode/tasks.json，里面配置如下内容：
JSON
复制
1
{
2
"version": "2.0.0",
3
"tasks": [
4
{
5
"label": "C++ 编译",
6
"type": "cppbuild",
7
"command": "C:/mingw64/bin/g++.exe",
8
"args": [
9
"-fdiagnostics-color=always",
10
"-g",
11
"${file}",
12
"-o",
13
"${fileDirname}/${fileBasenameNoExtension}.exe"
14
],
15
"options": {
16
"cwd": "${fileDirname}"
17
},
18
"problemMatcher": ["$gcc"],
19
"group": {
20
"kind": "build",
21
"isDefault": true
22
}
23
}
24
]
25
}
注意 command 里的路径要和你的 MinGW 安装路径一致。如果刚才 PATH 配置正确，其实可以直接写 "command": "g++"，让系统去 PATH 里找，这样切版本的时候不用改配置文件。但是写在绝对路径里也有个好处：即使终端环境没加载 PATH，VS Code 任务依然能找到编译器。我推荐项目固定的话用绝对路径，多项目切换用 PATH。
4.2 配置调试器：launch.json 和 gdb 的关系
编译不是终点，你大概率还要调试。配置调试同样在 .vscode 下建 launch.json，核心配置是让 VS Code 调用 gdb.exe 加载编译出来的 exe。一个可以拿来就用的最小配置如下：
JSON
复制
1
{
2
"version": "0.2.0",
3
"configurations": [
4
{
5
"name": "C++ Debug",
6
"type": "cppdbg",
7
"request": "launch",
8
"program": "${fileDirname}/${fileBasenameNoExtension}.exe",
9
"args": [],
10
"stopAtEntry": false,
11
"cwd": "${fileDirname}",
12
"environment": [],
13
"externalConsole": false,
14
"MIMode": "gdb",
15
"miDebuggerPath": "C:/mingw64/bin/gdb.exe",
16
"setupCommands": [
17
{
18
"description": "启用 gdb 美化打印",
19
"text": "-enable-pretty-printing",
20
"ignoreFailures": true
21
}
22
],
23
"preLaunchTask": "C++ 编译"
24
}
25
]
26
}
miDebuggerPath 同样要改成你本机 gdb 的路径。externalConsole 建议设为 false，不然每次调试都弹一个独立的黑窗口，在老版本 Windows 上偶尔还会出现输入焦点丢失的问题。
4.3 VS Code 配置中的高频报错和对应解法
在实际操作中，我见过最多的 VS Code + MinGW 报错基本集中在四类。
第一类是“无法打开 sources 文件，无法识别 __int64”。这种通常是编译器路径选择错了，VS Code 的 C/C++ 插件没有正确找到 gcc，导致它用了内置的默认配置去解析系统头文件。解决方法是打开命令面板（Ctrl+Shift+P），输入 C/C++: Edit Configurations (JSON)，在 c_cpp_properties.json 里手动指定 compilerPath 为 C:/mingw64/bin/gcc.exe，并设置 intelliSenseMode 为 windows-gcc-x64。
第二类是“任务里找不到 g++”。这个基本上是 PATH 环境变量没生效，或者 VS Code 里的终端是旧终端。重启 VS Code 而不是只关掉终端窗口能解决大多数情况。
第三类是“undefined reference to WinMain@16”。这个报错发生在你写的是控制台程序，但编译器链接的是 Windows 窗口程序入口。原因是你没写 int main()，写了 WinMain；或者你的源文件是 .c，但编译命令用了 g++，然后命名空间和入口函数混淆。解决办法是确认 main 函数签名是 int main() 或者 int main(int argc, char* argv[])。
第四类是“program not found”或者调试时一启动就退出。多半是因为 launch.json 的 program 路径写错了，或者 exe 文件名和编译输出不一致。一个通用的做法是打开终端，运行 ls 看一下当前目录下到底生成了什么名字的 exe，再回过去对齐路径。
5. Qt 项目报错“error while building/deploying project”的完整排查链路
5.1 报错产生的真实原因：Kit 与编译器不匹配
热搜词里有一条非常典型：error while building/deploying project qtmodbus (kit: desktop qt 5.9.9 mingw)。这个报错几乎是每个用 Qt Creator 的人都会碰到的。很多人一看到“building/deploying project”就以为代码写错了，其实绝大多数时候并不是源码问题，而是 Qt Creator 里的 Kit（构建套件）没有正确匹配到 MinGW 编译器。
所谓 Kit，是 Qt Creator 为项目绑定的一套环境组合，里面包含三样东西：编译器（C/C++ 各一个）、调试器（可选）、Qt 版本路径（qmake.exe 所在位置）。三样必须匹配，你用的 Qt 5.9.9 如果是 mingw 版，那编译器就必须是 MinGW 系列，不能是 MSVC；如果编译器选错了，Qt Creator 会尝试用 MSVC 编译一个 MinGW 版的项目，链接时绝对过不去，最终表现为“构建失败但不报具体错”。
所以第一步永远是：打开 Qt Creator，选择“工具 -> 选项 -> Kits”，找到报错的 Kit（比如 Desktop Qt 5.9.9 MinGW），检查它的 Compiler 一栏是不是空的，或者指向了不存在的 gcc.exe 路径。如果是空白的，说明 Qt Creator 没有自动识别到 MinGW。点开编译器旁边的小按钮，手动添加。编译器路径要精确到 bin/g++.exe，调试器路径到 bin/gdb.exe。
5.2 手动配置 Kit 和调试器的具体操作
在 Qt Creator 里手动添加 MinGW 的过程很直接，但里面有几个细节不能漏。
在“编译器”选项卡，点“添加 -> GCC -> C++”，填写名称（例如“MinGW-GCC-13”），然后在“编译器路径”里选择 C:/mingw64/bin/g++.exe。如果你要编译纯 C 项目，还要再添加一个 C 编译器，选择 gcc.exe。
在“调试器”选项卡，点“添加 -> GDB”，选择 C:/mingw64/bin/gdb.exe。这里要注意，老版本 Qt Creator 需要调试器和编译器都属于同一个 MinGW 工具链版本，不然运行时会有 ABI 识别警告。
在“Qt 版本”选项卡，检查 qmake 路径是否为 Qt 5.9.9 的 mingw 版，比如 C:/Qt/5.9.9/mingw53_32/bin/qmake.exe 或者 64 位版本。很多错误其实出在 Qt 版本是 MSVC 编译出来的，但你在 Kit 里强行配了 MinGW 编译器，qmake 内部会崩溃。
5.3 构建脚本和部署步骤里容易忽略的坑
即使 Kit 配置正确，报错偶尔还是会从构建或者部署阶段冒出来。我遇到过三种细节问题。第一种是构建目录里残留了之前 MSVC 生成的 Makefile 和 .o 文件，用 MinGW 重新构建时 Makefile 混乱，报错信息千奇百怪。解决方法是清理整个构建目录，重新 qmake + make。第二种是 Qt Creator 的部署步骤试图调用 windeployqt.exe，但路径没找到。这个时候报错信息里会出现“Cannot find windeployqt”或者“deploy step failed”，你需要确认 Qt 安装目录下真的有这个 exe，并且把路径加进 Kit 里对应的 Qt 版本配置中。第三种是 MinGW 编译器和 Qt 版本之间存在线程模型不一致，例如 Qt 是 win32 模型构建的，而你编译器是 posix 模型，链接时会出现 undefined reference to std::thread 或者反过来的错误。这个比较阴，表面看起来是代码问题，实际是工具链之间不兼容。
如果你的报错信息里带着“cannot find -lxxx”，那就又是另一个方向了——链接器找不到依赖库。Qt 项目里常用 LIBS += -lws2_32 这种写法，MinGW 在搜索库时除了系统目录，还要依赖 Qt 的 lib 目录。检查 .pro 文件或者 CMakeLists 里的库路径有没有写对，以及库文件是否是在网上下载的“prebuilt .a 文件”。这里尤其要警惕下载的库是用 MSVC 编译的 .lib，你用 MinGW 链接，符号格式不同，永远链接不上。
6. 版本兼容性心得与长期维护经验：这些坑我不希望你踩
6.1 多个 MinGW 版本并存是常态，不是特例
我目前电脑里至少躺着三个版本的 MinGW-w64：GCC 5.3 用于老的 Qt 5.9.9 项目，GCC 8.1 用于那些用到了老 Gnu 扩展的 C++ 代码，GCC 14 用于日常新项目。很多人觉得“装最新的不好吗”，但现实是编译器和库是深度绑定的，老项目用的是老标准甚至非标准语法，新版 GCC 默认将 C++ 标准提高到 C++17，编译时会疯狂报警告甚至报错。最典型的就是 Qt 5.9.9 这类老版本 Qt，本身是围绕老标准写的，用 GCC 14 去编译，一堆头文件内部的 deprecated 警告直接拉满，有些还会升级为 fatal error。所以我的建议是：压缩包形态的 MinGW 便宜就便宜在“绿色”上，你在 C 盘根目录建三个文件夹，比如 C:\mingw53、C:\mingw81、C:\mingw64，用哪个项目就切哪个 PATH。
6.2 现有的编译产物和库文件怎么匹配
如果你拿着一个编译好的 exe，里面链接了某个库，而这个库是用另一个版本的 MinGW 编译的，使用方式就得非常小心。MinGW 的二进制兼容性在 GCC 版本之间并不总是向后兼容，尤其是 C++ 项目的 ABI 在 GCC 5 从旧版 ABI 切换到新版 ABI 后，老库和新编译器之间的链接会报错。遇到这种问题，优先方案是找同一编译器版本下重新编译的库；次优方案是切到对应老版本的编译器；最差方案才是去改代码绕过 ABI，那通常是条死路。
另外还有一个实战技巧：新下载的 MinGW 包，解压后建议先运行一遍 gcc -v、g++ -v、gdb -v，把版本号记录下来。以后出现任何诡异的问题，第一件事就是先检查 gcc --version，确认当前终端里到底用的是哪个版本。很多“玄学报错”最后查出来就是 PATH 里混了多个版本，编译器被狸猫换太子了。
6.3 关于 2026 年版本选择的最终结论
选版本这件事，与其追新，不如追稳。新 GCC 当然带来更好的 C++20/23 支持、更快的编译速度、更详细的诊断信息，但代价往往是要在第三方库上花大量时间调兼容性。我的使用原则是：现有项目不动，新项目用新编译器；下载时优先选 WinLibs 提供的最新稳定版，也就是 GCC 14/15 这一档，压缩包带 GDB 和 make；只有明确要复现老环境时才回退老版本。
最后再分享一个日常小技巧。下载完 MinGW 压缩包后，不管解压到哪个目录，都建议立刻创建一个 add-to-path.bat 脚本放在根目录，内容就一行：setx PATH "%PATH%;C:\你的路径\mingw64\bin"。这样以后在任何新电脑上配置环境，双击一下脚本然后重启终端，环境就全好了。比每次手动去系统设置里点半天可靠得多。别问我是怎么想到写这个脚本的——问就是被重装系统坑过太多次了。