简介MinGW 64位最新版离线安装包内含GCC 13.1.0完整工具链面向Windows平台C/C开发者尤其适合无法便捷联网下载、需要一键部署编译环境的用户。压缩包共18725个文件包含大量C/C头文件h/hpp、静态库与动态库a/lib/dll、编译器及链接器等可执行程序exe同时提供Python辅助脚本py/pyc/pyd和HTML文档可满足编译、调试及二次开发等多样化需求包体采用7z格式仅68.89MB。该版本基于POSIX线程模型、SEH结构化异常处理及UCRT通用运行时解压后即为标准MinGW目录布局bin、lib、include等无需网络即可配置环境并能快速嵌入常见IDE工作流。目前已有1642人学习下载。使用这一离线包开发者可以直接获得GCC 13.1.0带来的最新语言特性和优化支持快速搭建原生64位Windows开发环境顺利推进跨平台或本地应用开发同时完整目录结构也为研究GNU工具链、理解编译流程提供了理想的参考样例。1. MinGW 64位离线安装包被 MSVC 卡住时我换成了这条工具链如果你在 Windows 上搞 C/C大概率经历过这种时刻Visual Studio 的安装器卡在网络请求上转圈CMake 提示找不到编译器内网机器又没法在线拉 MinGW。这个x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r离线安装包就是拿来解决这种尴尬的——它把 MinGW-w64 对 GCC 13.1.0 的完整构建打包好解压即用不依赖安装器也不要求管理员权限。64 位、POSIX 线程模型、SEH 异常处理、UCRT 运行时这四个参数决定了它跟现代 Windows 开发环境的兼容度。适合三类人内网或弱网环境下做 C/C 开发、用 CMake 但不想碰 MSVC、以及希望在 VSCode/Code::Blocks 里有一条干净gcc命令链的从业者。它不是什么玄学神器但确实能省掉一晚上的下载和配置时间。2. 版本命名不是玄学把 13.1.0 / posix / seh / ucrt / rt-v11 一次讲清2.1 x86-64 与 MinGW-w64 的位置关系MinGW 最初是面向 32 位 Windows 的 GCC 移植项目后来社区分裂出 MinGW-w64支持生成 64 位程序现在你看到的绝大多数“MinGW 下载”其实都是 MinGW-w64 的产物。标题里的x86-64明确告诉我们这是 64 位目标平台不能用它编出 32 位 exe想编 32 位得去下 i686 版本。13.1.0是 GCC 编译器的版本号。GCC 13 对应完整的 C20 支持std::ranges、std::format这类特性都能直接用。如果你项目里有依赖老语法或老 ABI 的第三方库装完先用gcc --version确认版本避免拿新版编译器去编译只适配 GCC 9 以下的代码。这串名字的解析规则是编译器版本-发布类型-线程模型-异常处理-运行时库-runtime 版本。后面几个参数才是真正决定“这个包能不能在你的项目里跑”的关键。2.2 posix vs win32 线程模型多线程代码翻车的高发区线程模型影响的是std::thread、std::async、OpenMP 这类并发设施能否正常工作。MinGW-w64 提供两个分支win32和posix。对比项posixwin32pthread API自带 winpthreads 实现不提供C11 std::thread支持良好部分版本编译报错第三方库依赖 pthread可直接链接常需手工适配体积略大略小posix版本里内置了 winpthreads本质是把 Windows 的线程 API 包装成 POSIX 接口。大多数开源库在 Windows 上的预编译包比如 libcurl、boost 的一些组件都默认按 pthread 方式链接。我一般无脑选 posix多花几 MB 磁盘省掉一堆 “undefined reference to pthread_create” 的排查时间。2.3 seh vs dwarf vs sjlj64 位下异常处理的唯一正解异常处理模型解决的是try/catch在底层如何展开调用栈。32 位 MinGW 通常有dwarf、sjlj、seh三种选择64 位平台则基本只提供seh。seh是 Windows 的结构化异常处理AMD64 的 ABI 强制要求使用它所以 x86-64 构建里选 seh 是唯一合理选项。dwarf是 GCC 在 32 位 Linux 上的经典方案到 64 位 Windows 上直接不可用sjlj是兼容性最广但性能最差的方案主要在 32 位老场景里兜底。看到posix-seh组合说明这个包在现代 Windows 上的异常处理和线程行为都接近原生不用再为跨平台异常机制担忧。2.4 ucrt vs msvcrt运行时库决定你的 exe 能在哪些系统跑ucrt指 Universal C Runtime是微软在 VS2015 之后重构的 C 运行时Windows 10/11 系统自带Win7 上需要系统更新补丁。msvcrt是远古的 Visual C 运行时很多老闭源库依赖它。选ucrt的实际收益在于它能与 MSVC 2015 以后编译出的.lib文件进行 ABI 互操作。你在 Windows 上做开发迟早会遇到“MinGW 项目要用某个 MSVC 编译的第三方库”的情况比如 Qt 的某些商业插件。运行时统一成 UCRT 后链接冲突会少很多。msvcrt 和 mingw 混用导致的诡异崩溃往往就出在两边拿不同版本的 CRT 各自管理堆内存。2.5 rt-v11 与离线包为什么比在线安装器省心rt-v11是 MinGW-w64 runtime 的第 11 版修订对应一批头文件和导入库的更新。release 版本相对更稳定不是 nightly 构建。官网下载点通常在 SourceForge 和镜像站之间跳转网络差时挂一晚上都不一定跑完离线安装包的好处是拿 U 盘拷一次以后每台机器都能用。安装目录的规划我放在下一章先把命名吃透后面配置环境变量时你就知道每个参数对应什么了。3. 五步落地解压、Path、验证、编译第一个程序3.1 离线包的解压与目录规划这个离线包通常是.7z或.zip压缩格式解压后得到一个mingw64文件夹。关键是别把它解压到C:\Program Files——路径里的空格会影响一部分老 Makefile 的解析也别放桌面容易被误删。我习惯统一放D:\dev\或C:\dev\这类无空格路径。# 示例把离线包解压到 D:\dev C:\ 7z x x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r.7z -oD:\dev-oD:\dev是 7-Zip 的输出目录参数注意-o后面不能有空格。解压完成后确认D:\dev\mingw64\bin目录下能看到gcc.exe、g.exe、gdb.exe。3.2 配置环境变量GUI 与 PowerShell 两种方式要让命令行能直接调用gcc需要把mingw64\bin加进Path。图形界面做法是此电脑 → 属性 → 高级系统设置 → 环境变量 → 在用户变量或系统变量的 Path 中新建一行填入D:\dev\mingw64\bin。建议直接加在系统变量里因为有些工具比如通过服务启动的构建进程不读用户变量。命令行方式我推荐用 PowerShell而不是setx# 追加到当前用户的 PathPowerShell [Environment]::SetEnvironmentVariable(Path, $env:Path ;D:\dev\mingw64\bin, User)这里用[Environment]::SetEnvironmentVariable可以精确控制是写用户级User还是系统级Machine并且不会像setx那样把整个 Path 读出来覆盖回去导致截断。用setx踩过坑的人应该明白——它会把变量长度截到 1024 字符改完直接把你原来的 Path 后半段吃掉属于典型的后悔药都没得吃。提示加完环境变量后必须重开终端窗口已经打开的 cmd/PowerShell 不会刷新 Path。3.3 验证工具链确认版本和实际调用路径配置完环境变量先做基础验证确认系统调用的确实是这个新装的 GCCgcc --version g --version gdb --version where gccgcc --version第一行会显示类似gcc (MinGW-W64 x86_64-ucrt-posix-seh) 13.1.0的信息。where gcc在 Windows 上会列出所有匹配的 gcc.exe 路径排在最上面的就是实际调用的那个。如果显示的还是旧版路径说明 Path 顺序有问题或终端没刷新后面第 5 章有专门排查。3.4 编译并运行第一个程序新建一个hello.cpp写入一个最简单的入口函数然后按下面流程编译#include iostream int main() { std::cout hello mingw std::endl; return 0; }# 编译开启常见警告并指定 C17 标准 g hello.cpp -o hello.exe -Wall -Wextra -stdc17 # 运行 .\hello.exe-Wall -Wextra打开基础警告集-stdc17指定语言标准-o hello.exe指定输出文件名。如果这步能顺利输出hello mingw说明编译器、链接器、运行时库全部正常。这一步的意义是冒烟测试大多数环境问题都在这里暴露比如缺libstdc-6.dll、Path 没配对、权限不足写不了输出文件。4. 对接 CMake 与编辑器把工具链真正用起来4.1 CMake MinGW Makefiles生成器必须显式指定CMake 在 Windows 上默认去找 Visual Studio 生成器装了 MinGW 却不知道用是新手最常遇到的问题。关键是生成器类型要写MinGW Makefiles同时显式指定编译器# 在项目根目录执行 cmake -S . -B build -G MinGW Makefiles -DCMAKE_C_COMPILERgcc -DCMAKE_CXX_COMPILERg cmake --build build-G MinGW Makefiles让 CMake 生成基于 make 的构建脚本-DCMAKE_C_COMPILERgcc和-DCMAKE_CXX_COMPILERg直接锁定编译器避免 CMake 去检测 MSVC。--build build等价于进入 build 目录执行 make生成的 exe 也在 build 目录里。我一般建议把整条 cmake 命令写进项目的构建脚本里作为固定流程执行而不是靠 IDE 自动探测。4.2 VSCode 里配置 tasks.json一键编译当前文件VSCode 本身不带编译器它只是调用终端里的 g。最简配置是在项目根目录建一个.vscode/tasks.json{ version: 2.0.0, tasks: [ { label: build with g, type: shell, command: g, args: [-g, main.cpp, -o, main.exe, -stdc17], group: { kind: build, isDefault: true } } ] }-g生成调试信息给后续断点用args数组里每一项对应一个命令行参数注意逗号分隔不要把整条命令字符串写进去。配置好后按CtrlShiftB就能直接编译。调试还需要在launch.json里配miDebuggerPath: D:/dev/mingw64/bin/gdb.exe这里不展开。4.3 链接第三方库.a 和 .lib 的兼容边界这是 mingw 与 msvc 区别最明显的环节。MinGW 的静态库是.a或直接.dllMSVC 的静态库是.lib。如果第三方只提供了 MSVC 编译的.lib直接-lfoo大概率报 “file format not recognized”。常见有三种处理找该库的 MinGW 预编译包多数知名库都提供用-Wl,--out-implib配合 DLL 生成导入库如果是 CMake 项目用find_library指定.a文件路径。ucrt运行时在这里能缓解一部分问题MSVC 2015 以后编译出的一些.lib在 ABI 层面可与 MinGW 链接但仅限于 C 接口C 接口因为名字修饰不同基本无解。原则很简单能用 C 接口就用 C 接口不能就换 MinGW 版预编译包别硬闯。4.4 Qt Creator 与 Code::Blocks 的编译器注册Qt Creator 上架一套工具链只需两步工具 → 选项 → Kits → 编译器 → 添加 → GCC然后把编译器路径选到g.exe再在 Kits 里新建或修改已有的 Kit指定 Qt 版本和 CMake 生成器为 MinGW。Code::Blocks 类似Settings → Compiler → Global compiler settings → Toolchain executables把编译器目录改成D:\dev\mingw64。这两步没什么玄学核心就是让它找到gcc.exe和gdb.exe剩下都是自动化检测。5. 常见问题与排查五条真实踩坑记录5.1 配完 Path 仍然提示“不是内部或外部命令”现象手动加完环境变量重开 cmd 执行gcc还是提示无法识别。原因最常见是终端没重开也可能是加到了用户变量而当前终端是管理员权限部分环境下管理员终端不继承用户 Path还有可能是路径里写了中文或空格导致找不到 gcc.exe。解决先echo %Path%看变量是否包含mingw64\bin没有就重开终端依然不行就加到系统变量里用where gcc和dir D:\dev\mingw64\bin\gcc.exe双重确认文件存在。我自己的习惯是直接在系统变量里加省掉权限差异的干扰。5.2 编译通过运行时提示缺少 libgcc_s_seh-1.dll现象hello.exe在自己机器上能跑拷到没有安装 MinGW 的机器上提示缺少libgcc_s_seh-1.dll或libstdc-6.dll、libwinpthread-1.dll。原因GCC 默认动态链接这几个运行时库exe 依赖 MinGW 目录下的 DLL目标机器上没有它们就启动失败。解决分发时把mingw64\bin下的libgcc_s_seh-1.dll、libstdc-6.dll、libwinpthread-1.dll一起拷走或者编译时加静态链接参数g hello.cpp -o hello.exe -stdc17 -static -static-libgcc -static-libstdc-static让链接器尽量静态链接所有库-static-libgcc和-static-libstdc单独控制 GCC 和 C 标准库的链接方式。静态后 exe 体积会从几十 KB 涨到几 MB但部署时不用再带 DLL。做工具类软件我一般直接静态省心。5.3 CMake 明明装了 MinGW却还是去用 MSVC现象执行cmake -S . -B build后输出显示 “The C compiler identification is MSVC”或者直接报找不到编译器。原因CMake 默认生成器是 Visual Studio如果没加-G MinGW Makefiles它优先探测 MSVC另外项目目录里残留的CMakeCache.txt会缓存旧编译器路径干扰新配置。解决删掉 build 目录和CMakeCache.txt重新执行带-G MinGW Makefiles -DCMAKE_C_COMPILERgcc -DCMAKE_CXX_COMPILERg的完整命令。这步常被漏掉很多人反复cmake ..但结果不变就是缓存没清。5.4 多线程代码链接时报 undefined reference to pthread_create现象使用std::thread或链接依赖 pthread 的库时报undefined reference to pthread_create。原因编译器本身是 win32 线程模型没有 winpthreads 实现或者链接命令里没带上-lwinpthread。posix版本虽然自带 pthread 实现但有些链接场景还是需要显式加库。解决先用gcc -v确认 Thread model 那行是posix还是win32。如果是 win32 版本换回 posix 版本如果已经是 posix就在链接参数里补一句g test.cpp -o test.exe -stdc17 -lwinpthread-lwinpthread显式链接 MinGW-w64 打包的 pthread 实现能解决绝大多数这类报错。5.5 装了新版 GCC编译时却用旧版头文件现象gcc --version显示 13.1.0但编译时用的标准库头文件报版本不符或where gcc同时列出多个路径。原因机器上装了多个 MinGW 版本旧版的bin目录靠前的 Position 被优先调用exe 是找到了头文件和库可能被新版本或CPLUS_INCLUDE_PATH环境变量污染。解决把新版路径在 Path 中前移或者干脆删掉旧版环境变量在项目里做验证时用gcc -E -v -x c /dev/null看实际的 include 搜索路径确认指向新版本的include目录。从那以后我每次装新工具链都会强制走一遍“版本号→解压位置→Path 优先级→gcc -v→编译冒烟”五步确认没有路径交叉才接手下一步。6. 进阶技巧静态分发与多版本共存工具链装好后还能进一步优化日常使用。一个实用技巧是把固定参数写进别名或脚本而不是每次敲一长串。比如静态分发项目的编译命令我在 Windows Terminal 的 PowerShell profile 里定义一个函数function build-release($name) { g $name.cpp -o $name.exe -stdc17 -O2 -static -static-libgcc -static-libstdc }-O2开启较高级优化-static系参数保证 exe 不依赖外部 DLL。这样交付给同事时直接拷贝单个 exe 就能跑。多版本共存时我维护一个D:\dev\下的目录约定mingw64-13、mingw-w64-11按版本分目录切换时只改 Path 顺序不卸载旧版本。验证当前生效版本用两行命令交叉确认where gcc ldd main.exewhere gcc确认实际调用的编译器路径ldd列出 exe 依赖的 DLL如果有 DLL 路径指向某个旧版目录就说明链接阶段没走对。这比单纯看gcc --version更可靠因为后者只看编译器自身不反映链接器找的库路径。这个离线包本身没有魔法价值在于把一整条工具链固定在了一个可复现的状态里。确认好版本命名、解压位置、Path 优先级、环境变量刷新、编译冒烟这五步后面所有项目都稳了。希望帮到你。本文还有配套的精品资源点击获取