简介面向Windows平台的MinGW 64位离线安装包内置GCC 13.1.0编译器面向需要在64位Windows环境中编写C/C程序的开发者尤其适合网络不稳或希望快速一键部署完整GNU工具链的用户可直接替代在线安装器。压缩包共含18725个文件主要类型包括h/hpp头文件、a/lib库文件、exe/dll可执行与动态库以及py/pyc辅助脚本、html/txt说明文档等分别用于源码引用、链接解析、程序运行和查阅指引整体约68.89MB结构清晰便于离线使用。目前已有1647人学习下载具有较高的实用参考价值。解压后即可获得完整mingw64目录bin、include、lib等核心组件齐备基于posix-seh-ucrt配置支持最新C标准与UCRT通用运行时无需网络依赖即可完成从编写到编译的整个流程特别适合快速搭建Windows原生应用开发环境。1. 装 MinGW 的坑一半踩在版本号上接触过 MinGW 64 位环境的人应该都有同感折腾大半天的配置问题最后发现根子全出在版本号上。官网下载页列着一排长到不像话的包名x86_64、posix、seh、ucrt、rt-v11 摞在一起没人解释每一段到底管什么。装的时候顺手点下去等到编译时std::thread报 undefined reference或者生成的 exe 拷到别的机器上缺 DLL才意识到 Typora 里写不了代码只能回头挨个版本试。这篇笔记记录的是我实际装过的这套 MinGW 64 位离线安装包 —— x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r对应 GCC 13.1.0POSIX 线程模型SEH 异常处理UCRT 运行时。选这个组合是因为它是目前 Windows 上做 C/C 桌面和本地工具开发最省心的配置能正常用 C11 及以后的标准库线程64 位下异常处理性能没有短板而且不依赖旧版 VC 运行时。内容从版本号拆解讲起覆盖解压安装、环境变量配置、VS Code 衔接最后一章给一套完整的编译验证流程。Windows 上用命令行编译器做过事的人比如搭过某种跨平台构建环境、编译过本地依赖库会觉得很对味如果第一次接触 MinGW照着走也能把环境跑通不踩我踩过的那些坑。2. 版本号拆解x86-64、posix、seh、ucrt 到底在说什么x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r这个包名不是随便拼的每一段都对应一个会影响编译结果的选项。Binutils、GCC 内核、线程模型、异常处理模型、C 运行时五件事都定死了编译出来的行为才稳定。我见过太多人在这一步随手选错后边排查到怀疑人生。2.1 线程模型posix 与 win32 的差别直接决定 std::thread 能不能用MinGW-w64 的 GCC 有两种线程模型posix 和 win32。这个选项影响的是 C 标准库thread、mutex、future等组件能否正常链接和运行。选择 win32 模型的 GCC 时标准库线程相关功能可能只是部分可用或直接不可用链接的时候经常抛 undefined reference选择 posix 模型标准库内部会通过 winpthreads 这个库打包里对应libwinpthread-1.dll来实现线程接口std::thread、std::async 这些才真正可用。这里有个理解误区posix 模型并不代表程序必须在 POSIX 系统上跑它只是标准库用 POSIX 线程接口做了一层适配底层仍然是 Windows 线程。换句话说在 Windows 上用 posix 模型编译出的程序依然调用的是CreateThread那一套但对外暴露的是符合 C 标准的线程语义。你要是写多线程程序比如用std::async做并行计算选 posix 基本是唯一稳妥的选择。这个包名里的posix就是这个线程模型配套的动态库 libwinpthread-1.dll 会在之后的 bin 目录里出现。如果哪天把 exe 拷到别的机器记得带上这个 DLL或者编译时加-static把它静态链进去。2.2 异常处理64 位环境选 seh 就够了异常处理模型有 sjljSetJump/LongJump、sehStructured Exception Handling和 dwarf 三种。32 位环境下各有取舍但在 64 位环境下seh 是 Windows 原生支持的异常处理方式性能和代码体积都优于 sjlj而且不涉及跨平台的兼容性问题。这个打包版本号里的seh指的就是这个。很多教程默认推荐 posix-seh 这个组合不是没有道理posix 解决标准库线程问题seh 解决异常处理性能和兼容性问题两者之间没有冲突在 64 位 Windows 上是当下最优解。反过来如果你拿到一个包名带sjlj的版本通常是为了兼容旧场景或者某些调试器但性能和栈展开表现确实一般。做生产工具链我一般直接排除。2.3 C 运行时ucrt 和 msvcrt 的关系以及和 VC 运行时的兼容ucrt指的是 Universal C Runtime。Windows 10 开始系统内置 UCRT它是 Windows 系统组件的一部分就像kernel32.dll一样是系统自带的。MinGW-w64 的 ucrt 版本编译器生成的代码依赖的是ucrtbase.dll这个 DLL 在 Win10 和 Win11 上开箱即用不需要额外装任何 VC 运行库。与之相对的旧版是 msvcrtmsvcrt.dll对应的是更早的 Visual C 运行时。msvcrt 的坑在于它太老了很多新函数和规范行为支持不到位而且混合使用时会和系统其他组件打架。新版 GCC从 GCC 13.x 开始主流发行版普遍转向 UCRT基本都推荐 ucrt 模型因为它在标准合规性、字符编码处理比如对 UTF-8 的支持上更接近现代 Visual Studio 的运行时环境。这套离线包选择 ucrt 还有一个实际收益以前编译出来的程序在别人电脑上跑经常提示缺VCRUNTIME140.dll或MSVCP140.dll而 ucrt 版本基本不会出现这种问题因为系统本身就有。这也是我后来固定用 ucrt 版本的原因。2.4 另一个决策离线包为什么比在线安装器省心离线安装包和官网在线安装器的区别在初次体验上就能感知到。官网的在线安装器需要联网挑选组件步骤多下载过程一旦中断就得重来离线包则是解压即用本质上就是一个便携的编译器工具集。对于内网环境、虚拟机、或者网络状况不稳定的场景离线包的价值很明显。这里要提一个常见的误解有的人以为离线包是“绿色版”其实它只是不需要安装向导但你仍然要把它的目录加进 PATH 环境变量编译器才能被命令行工具找到。这一步没做gcc 敲下去系统还是不认识命令。3. 解压与目录规划装在哪、怎么装、目录里有什么3.1 解压到指定目录规划好空间拿到这个离线包之后的第一步是解压。我不建议直接解压到桌面或者下载文件夹因为后续配置环境变量、给 VS Code 指定编译器路径时路径里夹带中文名或者空格都会增加不可控变量。常见做法是把工具链统一放到一个没有中文字符、路径尽量短的目录下比如C:\mingw64或者D:\dev\mingw64。解压方式没有特殊要求Windows 自带的资源管理器选中压缩包右键“解压到...”或者用命令行都行。命令行习惯的话可以用 tar 解压Windows 10 1803 以上自带 tartar -xf x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r.7z -C C:\mingw64提示如果系统提示 tar 不认识 7z 格式就用压缩软件解压大同小异。解压完成后确认C:\mingw64\bin这个目录真实存在再继续。解压后的根目录层级如下C:\mingw64\ ├── bin\ ├── include\ ├── lib\ ├── libexec\ ├── share\ └── x86_64-w64-mingw32\每一步都对应明确用途bin存可执行程序include存头文件lib存静态库和导入库x86_64-w64-mingw32是目标平台专属的库和头文件目录。明白这些结构后面配置环境变量时才不会把路径搞混。3.2 目录里的可执行文件bin 下到底有哪些打开bin目录里面躺着一堆 exe其中高频用到的是这几个文件名作用gcc.exeC 编译器g.exeC 编译器gdb.exe调试器mingw32-make.exe构建工具make 的 MinGW 变体ld.exe / ar.exe / objcopy.exe链接器和二进制工具这里有个容易困惑的点bin下没有make.exe只有mingw32-make.exe。原因在于 MinGW 的构建工具为了不和系统里其他同名工具冲突特意加了前缀。如果你在命令行敲make报找不到命令而项目文档又要求用 make 构建解决方案在后面避坑章节会详细给。3.3 GCC 13.1.0 的标准支持能用哪些语言特性GCC 13.1.0 对 C 标准的支持比较新C17 完整支持C20 大部分特性已落地C23 的部分新特性也能试用。这意味着你可以放心写std::expectedC23 早期版本、std::string_view、if constexpr这类现代语法不需要为了编译器版本去改写代码。实际项目里如果是从旧版 GCC比如 8.x、9.x迁移上来最需要留意的是新版本对头文件组织方式的调整、以及部分旧写法在 C17 之后产生的弃用警告。比如std::auto_ptr已经在 C17 移除、std::binary_function也被删除老代码里若有这些用法开-stdc17编译时会直接报错而不是警告。编译标准用-stdc17或-stdgnu17都比较常规。4. 配置环境变量三个容易写错的路径解压完只是第一步编译器还不能直接用。接下来的环境变量配置是新手最容易出错的地方我见过把C:\mingw64\bin写错成C:\mingw64的也见过为了省事把整个x86_64-w64-mingw32目录加进 PATH 的。每一步都值得仔细核对。4.1 PATH 配置只加 bin不要多也不要少第一个要配的是 PATH这是让命令行能找到gcc.exe、g.exe、gdb.exe的关键。在 Windows 的“环境变量”界面里WinR 输入sysdm.cpl或在设置里搜“环境变量”找到用户变量的Path这一行编辑新增一行C:\mingw64\bin提示用户变量就行不需要动系统变量。系统 PATH 的改动影响全局误操作风险高用户变量只对当前用户生效足够日常开发用。这里有个反直觉的坑MinGW 的库文件比如libgcc_s_seh-1.dll并不在C:\mingw64\lib而是在C:\mingw64\bin里。编译器生成的可执行文件运行时是优先在可执行文件所在目录找 DLL然后第二顺位就是 PATH 里的目录。如果只配了 lib 没有配 bin编译能通过运行 exe 时会提示缺 DLL。所以 PATH 必须指向 bin。4.2 头文件与库路径C_INCLUDE_PATH、CPLUS_INCLUDE_PATH 和 LIBRARY_PATHPATH 配好之后多数场景编译器能工作但还是建议把下面的环境变量也配齐尤其是你计划通过命令行或者 Makefile 引入第三方库的时候C_INCLUDE_PATHC:\mingw64\include;C:\mingw64\lib\gcc\x86_64-w64-mingw32\13.1.0\include CPLUS_INCLUDE_PATHC:\mingw64\include;C:\mingw64\lib\gcc\x86_64-w64-mingw32\13.1.0\include\c LIBRARY_PATHC:\mingw64\lib;C:\mingw64\x86_64-w64-mingw32\lib这三个变量分别对应 C 头文件搜索路径、C 头文件搜索路径、库文件搜索路径。GCC 有内置的默认搜索路径其实不配这些也能编译简单程序但配齐的好处是引入第三方库比如 OpenSSL、SDL时头文件和 lib 能直接命中不用每个编译命令都写一长串-I和-L。需要注意include\c目录下有多个子目录比如 13.1.0、x86_64-w64-mingw32这属于 GCC 的多版本并存结构不用管编译器自己知道该选哪个。4.3 配置完成后必做验证g 和 make 双重确认环境变量改完之后配置不会立刻生效。如果是在已打开的终端里测试需要先关掉重开如果是重新打开的终端可以直接验证。gcc --version g --version gcc -dumpmachine第一条和第二条命令用来确认 gcc 和 g 的版本输出里应该看到gcc.exe (Rev1, Built by ...) 13.1.0这样的信息。第三条gcc -dumpmachine是用来确认目标平台的输出x86_64-w64-mingw32就说明 64 位交叉目标正确如果你看到i686之类的字样说明装错包了这是 32 位。再验证一下基础编译能力echo int main(){return 0;} test.cpp g test.cpp -o test.exe test.exe这样一套下来编译器本体就算通了。正常情况命令不会报错环境变量配置到此结束。4.4 VS Code 场景下的编译器与配置很多开发者的编辑环境是 VS Code。VS Code 本身不带编译器它只是调用外部工具链。如果你打算在这套环境里写代码C/C 扩展装好之后就涉及两个配置文件c_cpp_properties.json用来告诉 IntelliSense 编译器路径和头文件路径和tasks.json用来定义编译任务。c_cpp_properties.json里的 compilerPath 要指向C:\mingw64\bin\g.exeintelliSenseMode 设置为windows-gcc-x64。这里我最常碰到的问题是 IntelliSense 报红但命令行编译正常根源多半是 includePath 没有配把 4.2 节那组 include 路径填进去就好。tasks.json的一个最小配置示例{ version: 2.0.0, tasks: [ { label: build, type: cppbuild, command: C:\\mingw64\\bin\\g.exe, args: [ -stdc17, -g, -o, ${fileDirname}\\output\\${fileBasenameNoExtension}.exe, ${file} ], group: build, problemMatcher: $gcc } ] }-stdc17声明语言标准-g生成调试信息${fileDirname}和${fileBasenameNoExtension}是 VS Code 的变量分别指代当前文件的目录和文件名不带扩展名。配置完成后按CtrlShiftB触发编译输出目录会生成 exe这一步通了这个环境就开始趁手了。5. 离线环境避坑指南五个踩过的实际问题每个装 MinGW 的人都会栽几个跟头。这一章记录的是我实际踩过的五个问题按“现象→原因→解决”的格式整理遇到相同情况可以直接照着救。5.1 编译通过、运行时缺 libgcc_s_seh-1.dll现象g 编译过程没有任何报错生成 exe 后在当前机器上运行提示“由于找不到 libgcc_s_seh-1.dll无法继续执行代码”。原因MinGW 生成的程序默认动态链接 GCC 运行时。libgcc_s_seh-1.dll在C:\mingw64\bin下如果你的 PATH 没有包含这个目录或者 exe 被拷贝到了没装 MinGW 的机器上运行时就找不到这个 DLL。很多人在其他电脑上跑编译好的程序碰到这个问题就是这样来的。解决开发机上把C:\mingw64\bin加入 PATH见 4.1 节如果要拷贝 exe 到别的机器用静态链接g -static-libgcc -static-libstdc main.cpp -o main.exe或者干脆用-static全静态链接这样生成的 exe 就不依赖外部工具链的 DLL。注意-static会让 exe 体积变大但换来的是环境无关性。5.2 std::thread 链接报错 pthread_create 未定义现象代码写了std::thread t([](){})编译命令用了-stdc17链接阶段报undefined reference to pthread_create。原因这个报错几乎可以断定你用的是 win32 线程模型的编译器。win32 模型下C 标准库的线程接口没有完整实现链接时找不到底层 pthread 符号。解决换成 posix 线程模型的版本比如x86-64-13.1.0-release-posix-seh-ucrt-rv11-r这套。另外也可以给编译命令加上-pthread选项把 pthread 符号显式链接进来有时能绕过部分问题。但最干净的方案还是换 posix 版本因为 win32 版本在整个标准库的多线程组件上都不完整越往后碰到的怪问题越多。5.3 make 命令不存在mingw32-make 和 make 的区别现象打开终端敲make系统提示“不是内部或外部命令”。原因MinGW-w64 的包里只带mingw32-make.exe没有make.exe。两者功能一致只是命名不同。系统不认识make是因为根本没有这个名字的可执行文件。解决第一种做法是把命令改成mingw32-make在很多项目 Makefile 里照常工作。第二种做法是自己复制一份改别名copy C:\mingw64\bin\mingw32-make.exe C:\mingw64\bin\make.exe这样make命令就能用了。需要注意如果系统里已经装了其他 make比如 Git 自带的 makePATH 顺序会决定先用哪个最好用where make查一下实际命中的路径。5.4 找不到头文件或 include 路径错乱现象编译时报fatal error: stdio.h: No such file or directory或者自定义头文件#include myheader.h搜不到。原因一部分情况是环境变量C_INCLUDE_PATH和CPLUS_INCLUDE_PATH没配对另一部分情况是 VS Code 的 c_cpp_properties.json 里 includePath 写错IntelliSense 找不到但命令行编译是正常的。解决命令行报错时确认 4.2 节的变量是否配置且终端是否是新开的VS Code 报错时检查c_cpp_properties.json的 includePath 是否包含C:\mingw64\include。还有一种隐蔽原因项目里用了相对路径#include xxx/header.hGCC 默认从源文件所在目录开始找引号形式的头文件如果文件目录被移动过相对路径就断了。这种就要检查源码里 include 的路径写法。5.5 和 Visual Studio 的库混用导致的奇怪崩溃现象程序在开发机上正常拿给同事用 Visual Studio 编译的库来链接运行时莫名其妙崩溃报各种无法理解的堆栈错误。原因MinGW 工具链和 Visual Studio 工具链使用的是不同的 C 运行时MinGW 用的是 libstdcVisual Studio 用的是 MSVC CRT。C 标准库对象的内存布局和内部机制不互通两边混用会破坏 ABI 兼容性。解决整个项目统一工具链。MinGW 编的程序只依赖 MinGW 的导入库也就是 4.2 节 LIBRARY_PATH 里的那些 .a 文件对应生成的 DLL。如果你的依赖库来自 Visual Studio 构建发布时会带 .lib 和 .dll优先找该库有没有提供 MinGW 可用的构建或者直接用 MSVC 工具链编译整个项目。这个问题没有绕过方法只能在项目开始时选定一条路走到底。6. 装完怎么验证跑通一套完整的编译验证清单环境装好、配置完成、坑也排过了最后一步是用一套完整的验证流程确认这套 MinGW 工具链真的可用。不是跑个 hello world 就完事而是要覆盖标准库线程、异常处理、文件 IO、静态链接这几个关键点。6.1 单文件冒烟测试hello world 和标准库验证先在临时目录建一个verify.cpp内容覆盖 C11 以上的核心特性#include iostream #include thread #include vector #include exception #include atomic int main() { // 验证控制台输出 std::cout MinGW 64bit toolchain works std::endl; // 验证线程和原子操作 std::atomicint counter{0}; std::vectorstd::thread threads; for (int i 0; i 4; i) { threads.emplace_back([counter]() { for (int j 0; j 10000; j) counter.fetch_add(1); }); } for (auto t : threads) t.join(); std::cout counter counter.load() std::endl; // 验证异常处理 try { throw std::runtime_error(exception test); } catch (const std::exception e) { std::cout e.what() std::endl; } return 0; }编译命令g -stdc17 -Wall -Wextra verify.cpp -o verify.exe verify.exe输出三行信息分别对应输出流、线程累加结果应为 40000、异常捕获三行都正常就说明标准库核心组件在这个版本上没毛病。-Wall -Wextra是推荐常开的警告选项能提前发现类型不匹配、未使用变量之类的隐患。6.2 多文件工程验证用 Makefile 走一遍真实构建单文件能跑还不够实际项目里你不会把所有代码塞进一个文件。用 Makefile 管理构建是 MinGW 环境下的常见做法下面这个验证用例模拟真实的编译、链接流程。CXX g CXXFLAGS -stdc17 -Wall -O2 TARGET demo.exe OBJS main.o util.o $(TARGET): $(OBJS) $(CXX) $(CXXFLAGS) -o $(TARGET) $(OBJS) main.o: main.cpp util.h $(CXX) $(CXXFLAGS) -c main.cpp -o main.o util.o: util.cpp util.h $(CXX) $(CXXFLAGS) -c util.cpp -o util.o clean: del /Q $(OBJS) $(TARGET)mingw32-make如果前面按 5.3 节做了make.exe的别名这里直接敲make也行。Makefile 里我固定写CXX g而不是写死绝对路径这样换编译器版本比如以后升级到 GCC 14时不用改 Makefile只要 PATH 指向新版本即可。del /Q是 Windows 的删除命令和 Linux 的rm -f对应跨平台项目里要注意区分。6.3 静态链接验证生成不依赖外部 DLL 的可执行文件最后一个验证点考查的是运行时独立性。MinGW 默认动态链接 GCC 运行时和 winpthreads意味着生成的 exe 依赖C:\mingw64\bin下的 DLL。把 exe 拿到没有安装 MinGW 的机器上这一步经常让它直接罢工。所以验证完动态链接后还值得验证一下静态链接g -stdc17 -static -static-libgcc -static-libstdc verify.cpp -o verify_static.exe加-static之后生成的 exe 体积会比动态版大不少通常从几十 KB 涨到几 MB这是静态链接把 C 运行时库塞进了 exe 里的正常现象。测试办法是把verify_static.exe拷到一个干净目录临时把 PATH 清空再运行或者直接在装了 MinGW 的机器上确认程序运行时不依赖 MinGW 目录——用 Process Explorer 或任务管理器看加载的 DLL 列表是否干净。# 检查生成的 exe 依赖哪些 DLL在 MinGW 环境里 objdump -p verify_static.exe | grep DLL Name通过这个命令可以看到动态链接版的输出依赖KERNEL32.dll、msvcrt.dll或ucrtbase.dll、libgcc_s_seh-1.dll、libstdc-6.dll、libwinpthread-1.dll静态链接版应该只剩系统 DLL外部工具链的 DLL 一个都不该出现。从那以后我每次装完 MinGW都会把这一整段流程强制走一遍冒烟测试、多文件构建、静态链接验证缺一不可。踩过的 DLL 缺失和线程链接报错太多回验证能提前把九成问题暴露出来。整套流程走下来环境基本上就踏实了。希望这组笔记能帮你少走一段弯路把时间留给真正要写的代码。本文还有配套的精品资源点击获取