简介这份资源是面向 Windows 10 64 位系统的 MinGW 安装包版本 V14.12.0适合需要在 Windows 上搭建类 Unix 开发环境、使用 GCC 编译链进行 C/C 开发的初学者与进阶开发者。压缩包采用 7z 格式共收录约 2000 个文件整体大小 79.98MB其中以 918 个 .h 头文件、808 个 .py 脚本、243 个 .hpp 头文件为主另含少量 .c 源码、.sh 脚本、.txt 说明及 .md、.js、.html、.css 等辅助文件覆盖编译器、标准库头文件与配套工具链。目前已有 368 人浏览学习。借助该安装包读者可快速获得完整的 GCC 编译链环境结合头文件与源码示例理解预处理、编译、汇编、链接各环节并参考作者在 CSDN 博客中提供的安装配置教程完成环境变量设置与组件选择减少兼容性与权限问题带来的排错成本。1. 为什么在 Windows 10 上装 MinGW 总翻车从一次编译失败说起有个做嵌入式的朋友上周找我说在 Windows 10 上装了个 MinGW写了个最简单的hello.cgcc一敲就报gcc 不是内部或外部命令。他重装了三次换了两个下载源最后怀疑是系统问题。我远程一看安装路径里带了个空格环境变量配的是C:\Program Files\mingw\bin而实际解压出来的是C:\Program Files\mingw64\bin——差一个64折腾了一下午。这事在 Windows 上太常见了。MinGW 本身不复杂它就是把 GCC 编译链搬到 Windows 上的一套工具集核心是gcc、g、gdb、mingw32-make这几个可执行文件。但 Windows 和 Linux 的差异在于Linux 下apt install一行搞定Windows 下你得自己管路径、管位数、管环境变量。V14.12.0 这个版本对应的是 GCC 14 系列属于比较新的稳定版对 C23 的部分特性支持已经比较完整适合需要新标准又不想上 MSVC 的场景。这份资源适合三类人一是学生或自学者想在 Windows 上跟 Linux 教程学 C/C二是嵌入式开发者需要交叉编译或验证代码在 GCC 下的行为三是偶尔要编译开源库、不想装 Visual Studio 全套的人。如果你只是写写 Python 或前端这东西跟你没关系。但只要你需要在 Windows 上跑gcc命令这篇就是给你写的。2. 拆开这个安装包目录结构、版本号与选型逻辑2.1 解压后到底有什么拿到安装包先别急着双击。MinGW 的发行方式通常是压缩包或安装器V14.12.0 这个版本我拿到的是压缩包形式。解压后根目录下一般有这几个关键文件夹目录作用必须关注bin存放gcc.exe、g.exe、gdb.exe、mingw32-make.exe环境变量指向这里lib静态库、动态库、GCC 内部库链接报错时来这查includeC/C 标准库头文件一般不动libexecGCC 内部调用的子程序别删share文档、locale可忽略bin目录是核心。你敲的每一条gcc命令最终都是调用这里的gcc.exe。它再去libexec找cc1.exe做实际编译去lib找库做链接。所以环境变量只配bin就够了配多了反而容易冲突。2.2 为什么选 V14.12.0 而不是更老的版本GCC 版本号里14 是主版本12 是次版本0 是修订号。选这个版本的理由有三个第一C 标准支持。GCC 14 对 C20 的concepts、ranges、coroutines支持已经稳定C23 的std::print、std::expected也基本可用。如果你跟的教程用的是新标准老版本 GCC 会直接报语法错误那种错误新手根本看不出是编译器版本问题。第二Windows 10 兼容性。GCC 14 系列对 Windows 10 的 UCRT 运行时支持更完整编译出来的 exe 在 Win10 上直接跑不需要额外装运行库。老版本可能依赖msvcrt.dll在某些精简系统上会缺。第三调试体验。这个版本配套的 GDB 对 Windows 的调试信息格式支持更好配合 VS Code 的cppdbg插件断点、单步、查看变量基本不会出现“符号找不到”的玄学问题。2.3 32 位还是 64 位一个必须确认的参数标题写的是“适合 window10 64 位”但 MinGW 有两个体系mingw32和mingw64。这里的 32/64 不是指你系统是 32 位还是 64 位而是指目标程序的位数。mingw32编译出 32 位程序能在 64 位 Windows 上跑但内存受限。mingw64编译出 64 位程序只能用 64 位系统。你系统是 Win10 64 位那就选mingw64体系。但注意mingw64的bin目录下gcc.exe本身也是 64 位的。如果你误装了 32 位版本编译大项目时可能遇到内存不足或链接器崩溃。确认方法很简单解压后进bin看gcc.exe的文件大小64 位版本通常更大或者直接敲gcc -dumpmachine输出里带x86_64就是 64 位带i686就是 32 位。这个命令后面还会用到。3. 从解压到跑通第一个程序环境变量与编译链路3.1 解压路径的硬性要求把压缩包解压到一个纯英文、无空格、无中文的路径。我一般用C:\mingw64。为什么不能有空格因为 GCC 内部调用子程序时路径拼接用的是空格分隔C:\Program Files会被拆成C:\Program和Files两段直接报no such file or directory。中文路径更麻烦某些版本的 GDB 会乱码。解压后确认C:\mingw64\bin\gcc.exe存在。如果解压出来多了一层文件夹比如C:\mingw64\mingw64\bin那就把内层mingw64里的内容移到外层或者环境变量直接指向内层。我建议移平少一层路径少一个坑。3.2 环境变量配置PATH 的加法与减法Windows 10 配环境变量的入口右键“此电脑” → 属性 → 高级系统设置 → 环境变量。在“系统变量”里找到Path编辑新建一条C:\mingw64\bin注意是“新建”不是“替换”。很多人把原来的 Path 全删了只留这一条结果系统命令全挂。配完后必须重启命令行已经打开的 cmd 或 PowerShell 不会自动刷新环境变量。验证gcc --version如果输出gcc (MinGW-W64 x86_64-...) 14.12.0说明 PATH 生效。如果还是“不是内部或外部命令”检查三件事路径有没有写错、有没有重启命令行、bin目录下到底有没有gcc.exe。3.3 编译第一个程序完整命令与参数解释新建hello.c#include stdio.h int main(void) { printf(MinGW GCC 14.12.0 works.\n); return 0; }编译gcc hello.c -o hello.exe -Wall -Wextra -O2逐段解释gcc调用编译器驱动它自己不做编译而是调度cc1、as、ld。hello.c源文件可以跟多个。-o hello.exe指定输出文件名。不写的话Windows 下默认生成a.exe。-Wall -Wextra打开常用警告。新手必加很多逻辑错误编译器会提醒。-O2优化级别。调试时用-O0 -g发布时用-O2。运行.\hello.exe输出MinGW GCC 14.12.0 works.就算通了。3.4 多文件编译与 make 的替代方案实际项目不会只有一个文件。假设有main.c、util.c、util.hgcc main.c util.c -o app.exe -I. -Wall-I.表示头文件搜索路径包含当前目录。如果文件多了手敲不现实用mingw32-make。写个MakefileCC gcc CFLAGS -Wall -Wextra -O2 TARGET app.exe OBJS main.o util.o $(TARGET): $(OBJS) $(CC) $(OBJS) -o $(TARGET) %.o: %.c $(CC) $(CFLAGS) -c $ -o $ clean: del $(OBJS) $(TARGET)注意Makefile里缩进必须是Tab空格会报missing separator。这是新手翻车率最高的一条。运行mingw32-makemingw32-make是 MinGW 自带的 make 工具和 Linux 的make用法一致只是名字不同避免和 Windows 其他工具冲突。4. 避坑与排查五条血泪经验4.1 现象gcc能跑但g报错找不到头文件原因只装了 C 编译器没装 C 组件。MinGW 的完整包应该同时包含gcc.exe和g.exe。有些精简包只留了 C。解决检查bin下有没有g.exe。没有就换完整包。有的话敲g --version看是否正常。如果g存在但编译 C 报iostream: No such file说明include/c目录缺失同样是包不完整。4.2 现象编译通过运行时报libgcc_s_seh-1.dll缺失原因动态链接了 GCC 运行时库但 exe 被复制到别的机器或别的目录找不到 dll。解决两个方案。一是把C:\mingw64\bin下的libgcc_s_seh-1.dll、libstdc-6.dll、libwinpthread-1.dll复制到 exe 同目录。二是静态链接gcc hello.c -o hello.exe -static -static-libgcc -static-libstdc-static把运行时库打进 exe文件变大但独立运行。发布程序时我一般用这个。4.3 现象mingw32-make报missing separator原因Makefile里用了空格缩进make 要求 Tab。解决用编辑器把缩进改成 Tab。VS Code 右下角可以切换“空格: 4”为“Tab 缩进”。或者用sed批量替换但 Windows 下没 sed手动改最稳。4.4 现象GDB 调试时断点不生效提示No symbol table原因编译时没加-g或者加了-O2导致优化后代码行号错乱。解决调试专用编译命令gcc -g -O0 main.c -o main.exe-g生成调试信息-O0关闭优化。两者必须同时用。发布时再换-O2去掉-g。4.5 现象中文输出乱码原因Windows 控制台默认代码页是 GBK而 GCC 编译出的程序按 UTF-8 输出。解决在程序开头加SetConsoleOutputCP(65001);需要#include windows.h。或者编译时加-fexec-charsetGBK让编译器把字符串转成 GBK。我一般用前者不动编译参数代码里控制。5. 进阶技巧用 VS Code 把 MinGW 变成顺手的开发环境5.1 配置 tasks.json 实现一键编译VS Code 里按CtrlShiftP输入Tasks: Configure Task选Create tasks.json file from template→Others。替换为{ version: 2.0.0, tasks: [ { label: build with gcc, type: shell, command: gcc, args: [ -g, -O0, -Wall, -Wextra, ${file}, -o, ${fileDirname}\\${fileBasenameNoExtension}.exe ], group: { kind: build, isDefault: true }, problemMatcher: [$gcc] } ] }${file}是当前打开的源文件${fileDirname}是所在目录${fileBasenameNoExtension}是不带后缀的文件名。按CtrlShiftB直接编译错误会显示在“问题”面板点击跳转到行。5.2 配置 launch.json 实现断点调试按F5选C (GDB/LLDB)生成launch.json改program和miDebuggerPath{ version: 0.2.0, configurations: [ { name: GDB debug, type: cppdbg, request: launch, program: ${fileDirname}\\${fileBasenameNoExtension}.exe, args: [], stopAtEntry: false, cwd: ${fileDirname}, environment: [], externalConsole: true, MIMode: gdb, miDebuggerPath: C:\\mingw64\\bin\\gdb.exe, setupCommands: [ { description: enable pretty printing, text: -enable-pretty-printing, ignoreFailures: true } ], preLaunchTask: build with gcc } ] }preLaunchTask必须和tasks.json里的label一致这样按 F5 会先编译再调试。externalConsole设为true可以避免 VS Code 内置终端对scanf的兼容问题。5.3 验证工具链是否完整最后跑一遍完整检查确认gcc、g、gdb、mingw32-make四个都能用gcc --version g --version gdb --version mingw32-make --version四个命令都输出版本号且gcc -dumpmachine输出x86_64-w64-mingw32说明这套 V14.12.0 在 Win10 64 位上是完整可用的。从那以后我每次配新机器都先跑这四条命令确认无误再开始写代码。希望帮到你。本文还有配套的精品资源点击获取