简介MinGW for Win64 是一套面向 Windows 64 位系统的开源 GNU 编译器工具集专为需要在 Windows 环境中编写、编译和调试 C 程序的开发者准备尤其适合不依赖大型集成开发环境的初学者、课程实验与小型项目实践。压缩包以 zip 格式发布整体体积约为 156.05MB核心内容为 TDM-GCC-64 工具链包含 64 位 GCC 编译器、C 标准库实现、Binutils 链接与汇编工具、make 自动化构建工具以及开发所需的头文件和静态/动态链接库。其中C 标准库覆盖容器、迭代器和算法等常用功能GCC 编译器支持从 C11 到 C17 的多种标准并能生成原生 64 位 Windows 应用程序。目前该资源已有 115 人学习下载。借助这套资源读者可在本地快速建立轻量级命令行编译环境观察从源码到可执行程序的完整构建过程同时由于采用 GNU 工具链代码在跨平台迁移时也更具兼容性。相比 Visual Studio 等大型 IDEMinGW 启动速度更快、内存占用更低适合日常编程练习、算法测试和教学演示等场景。 很多人在 Windows 64 位环境下做 C/C 开发第一步就卡在工具链选择上。装个 Visual Studio 吧动不动几个 GB而且 MSVC 那套编译参数和 Linux 下完全是两个世界用 Cygwin 呢又觉得太重而且默认生成的东西依赖 POSIX 模拟层看着就不够“原生”。如果你也在这个阶段纠结过那么 MinGW for Win64 就是你绕不开的一个选项。这篇内容不是什么官方文档翻译而是我这些年实际使用 MinGW-w64 的经验记录。我会从它到底是什么、和 MSVC 的核心差异在哪里到怎么下载、怎么安装、怎么一口气把 OpenSSL、FreeGLUT 这些常用库编译通过以及和 CodeBlocks、VS 2022 怎么配合使用都完整走一遍。不管你是刚入门的学生、在 Linux 和 Windows 之间横跳的全栈开发者还是需要给客户交付原生 Windows 程序的工程师这篇文章应该能帮你省下不少折腾时间。1. 为什么我在 Win64 上选择 MinGW 而不是 MSVC1.1 MinGW 和 MinGW-w64这两个名字别再搞混了先理清一个基本概念。网上搜索“MinGW 下载”出来的结果很乱有人下到的是 32 位的老版本有人下的文件名叫 mingw-get-setup.exe还有个叫 MinGW-w64 的东西。这三者不是一回事。原始的 MinGW 项目其实已经很久没有大版本更新了它主要面向 32 位 Windows编译器是 32 位输出的。你现在看到绝大多数教程、开源项目都在用的其实是 MinGW-w64 这个分支项目。MinGW-w64 是从原 MinGW 分叉出来的它的目标很明确同时支持 32 位和 64 位 Windows 目标而且维护非常活跃像 GCC 13、GCC 14 这些新版本编译器它都能及时跟进。所以在 Win64 平台上做开发你要装的应该是 MinGW-w64而不是传统意义上的 MinGW。很多教程标题还写着“MinGW 安装教程”打开链接一看内容全是 MinGW-w64 的界面这是因为写教程的人自己也默认了这一点。1.2 MSVC 和 MinGW 的核心差异一张表看懂MSVC 和 MinGW 的区别不是简单的“两个编译器”而是两套完全不同的生态。我用一个生活化的类比解释一下MSVC 像是一个精装修的公寓所有东西都是开发商统一配置的门窗、水电、墙体都是同一套标准你只能在里面住想拆承重墙是不行的MinGW 像是一套毛坯房水电管线也是接好的Windows API 层面的兼容但是墙体怎么砌、里面怎么装修你自己说了算。对比维度MSVC (Visual Studio)MinGW-w64底层运行时MSVCRT / UCRT微软官方维护默认 msvcrt新版也支持 UCRTC 标准库Microsoft STLlibstdc (GCC 自带)二进制兼容性与自身生态兼容好和 MSVC 编译的 obj/lib 互不兼容Linux 代码迁移成本较高POSIX API 缺失多较低很多 Linux 代码改改就能编体积单个组件动辄几个 GB压缩包几百 MB解压即用许可协议闭源社区版受限GCC 的 GPL 运行库例外命令行体验PowerShell cl.exe参数比较繁琐GCC 风格跟 Linux 下几乎一致结合我的实际体验来说如果你只是做 Windows 平台商业软件且重度依赖 Visual Studio 的调试器、性能分析器、还有那一堆可视化设计器那你就老老实实用 MSVC但如果你跟我一样主要工作在 Linux 服务器上偶尔需要把同一套 C/C 代码编译成 Windows 可执行文件给同事或客户用那 MinGW-w64 的体验是碾压 MSVC 的——因为 Makefile、CMakeLists 基本不用怎么改编译器参数也完全一样。1.3 什么时候必须选 MinGW什么时候别碰选 MinGW 之前先搞清楚自己的需求边界。我个人的判断标准是这样必须选 MinGW 的场景代码里大量使用了 POSIX APIpthread、fork、unistd.h 相关虽然 MinGW 没有完整实现 POSIX但它提供了 winpthreads 等替代方案迁移成本比 MSVC 低很多项目依赖了很多 Linux 生态的开源库比如 libcurl、OpenSSL、SDL2这些库的官方构建指南里都有 MinGW 的交叉编译示例你要用 Qt 做 Windows 桌面应用Qt 在 Windows 下对 MinGW 的支持非常成熟很多开源项目就是这么干的别选 MinGW 的场景项目需要和 C#/VB.NET 混编那必须用 MSVC 编译成托管 C 才能方便调用需要用到微软的最新 C 标准库实现MSVC 对新标准的支持进度有时比 GCC 快你希望直接用 /MT、/MD 这种编译选项控制运行时库的静态动态链接MSVC 的机制更清晰MinGW 在这方面处理方式完全不同看清楚这几点后面你就不会走弯路。2. Win64 下的 MinGW 版本那么多怎么选不踩坑2.1 32 位和 64 位版本的坑我替你踩过MinGW-w64 的下载页面里有一个选项是“架构”很多人懵在这里。注意这里说的是编译器生成的目标平台架构不是说你系统是 64 位就得装 64 位编译器。我举个例子你就明白了。你在 64 位 Windows 上装 32 位 MinGW编译出来的 exe 是 32 位的只能跑在 WoW64 模拟层上。但反过来如果你要做一个供 32 位程序调用的 DLL那你必须用 32 位编译器否则接口对不上。而且 32 位 exe 无法加载 64 位 DLL反之亦然。大多数情况下我建议你直接选择 x86_64 版本。因为 64 位编译出的程序能跑在 64 位系统上而且对内存的使用没有 4GB 限制性能也更优。如果你是做嵌入式或者兼容老系统才需要考虑 i68632 位版本。另外注意一下线程模型Win64 下建议选择 winpthreads 线程模型它是 MinGW-w64 项目自己维护的 pthread 实现比 msvcrt 模型的兼容性好很多。2.2 个人开发和持续交付场景下的选择策略不同的使用场景下载的版本可能完全不一样。这里分享两个我自己实际踩过的选择方案个人开发场景我推荐直接用 WinLibs 或者 MSYS2 这两个发行版。WinLibs 提供的就是便携版解压到某个目录不写注册表环境变量手动指一下就行想换版本直接删文件夹方便到了极点。MSYS2 则自带软件包管理器你可以在它的 shell 里直接 pacman -S mingw-w64-x86_64-gcc 来安装后续升级也方便但用起来会比便携版绕一层。持续交付、需要工具链版本可控的场景建议从 MinGW-w64 官方仓库或者 GitHub Releases 页面下载固定的 GCC 版本比如 GCC 13.2.0。因为在 CI/CD 环境里工具链的版本必须锁定不然今天编译出来的东西明天可能行为就变了。我之前的团队就吃过这个亏本地用的是 GCC 12 编译CI 环境自动拉了个 GCC 13结果一段依赖旧版本未定义行为的代码跑出来的结果完全不一样排查了一个下午。2.3 顺手检查一下环境变量别让 PATH 背锅下载解压 MinGW-w64 之后第一个要做的就是把 bin 目录加到系统 PATH 里。这一步看着简单坑却不少。不要直接把整个 MinGW 目录加进 PATH要加到 bin 子目录。bin 目录里才是 gcc.exe、g.exe、gdb.exe、mingw32-make.exe 这些可执行文件。重启终端再验证。Windows 的终端环境变量是启动时读取的改完 PATH 不重启终端你敲 gcc --version 大概率还是提示找不到命令。在 PowerShell 里验证的时候建议用 gcc --version 而不是直接用 gcc -v前者输出的版本信息更容易辨认后者会把一堆编译器的内部配置路径刷屏出来新手很容易看懵。验证成功之后你应该能看到类似这样的输出gcc (MinGW-W64 x86_64-ucrt-posix-seh) 13.2.0看到这行说明你的 MinGW 已经可以干活了。3. 从零开始Win64 环境下的 MinGW 安装与配置实操3.1 下载安装包的具体步骤与注意点这里有一个比较尴尬的点MinGW-w64 官网提供的是源码仓库和指向各发行版的链接本身不直接给一个打包好的 exe。所以在实际下载时你一般走下面这条路打开 WinLibs 官网在 Releases 页面找到最新版本的条目根据自己的需要选择文件。文件名里通常有这样的字段win64目标架构、ucrt运行时库、posix线程模型、seh异常处理模型下载那个带portable或者不带 install 字样的压缩包一般是.7z格式。如果你的电脑没装 7-ZipWinRAR 也能解压就是慢一点解压到一个不含中文和空格的路径下比如D:\dev\mingw64。这个路径后面使用频率很高最好固定下来补充一点很多文章会推荐你去 SourceForge 下载。SourceForge 上确实有 MinGW-w64 的官方项目页但下载按钮容易点到广告而且体验时好时坏。相较之下WinLibs 和 MSYS2 的下载链接更干净我更推荐。3.2 配置环境变量的完整流程和验证标准配置环境变量的过程很啰嗦但只要你走完一遍后面所有工具链都能复用同样的套路。这里我写一套适合新手照着做的完整流程在桌面右键“此电脑” → 属性 → 高级系统设置点击“环境变量”在下方的“系统变量”区域找到Path那一行双击进去点击“新建”输入D:\dev\mingw64\bin换成你自己的实际路径一路点“确定”保存然后关闭当前终端窗口并重新打开一个新的终端在新终端里依次执行gcc --version、g --version、gdb --version、mingw32-make --version四个命令都能输出版本号说明配置成功这里我特别想提醒一个细节mingw32-make这个名字有点误导。你在 MinGW 的 bin 目录里找不到make.exe只有mingw32-make.exe。因为make这个名字在 Unix 系统上是约定俗成的但在 Windows 上可能和别的软件冲突所以 MinGW-w64 特意把它改了名。如果你用的是 CMake那无所谓CMake 会自动找到它直接用 Makefile 的话注意命令名要写成mingw32-make或者你建一个软链接把make指到mingw32-make上省得每次打那么长一串。3.3 第一个测试程序验证工具链真的能干活配置完环境变量后我强烈建议你立刻写一个小的测试程序验证整个编译链路是通的。新建一个test.cpp内容填最简单的 Hello World 或者类似的逻辑#include iostream #include vector #include thread int main() { std::thread t([]() { std::cout thread is running std::endl; }); t.join(); std::vectorint v {1, 2, 3}; for (auto x : v) { std::cout x ; } std::cout std::endl; return 0; }为什么这次测试要刻意加入std::thread很多人在第一步 Hello World 编译通过之后就兴高采烈结果后面写多线程的时候发现直接报错“undefined reference to pthread_create”。这是因为 MinGW-w64 的线程模型如果选的 win32 而非 posix那标准库的thread头文件虽然存在但链接时找不到对应的实现。上面的测试程序一跑就能提前暴露这个问题不用等到项目里才炸。编译命令如下g -stdc17 -O2 test.cpp -o test.exe test.exe如果程序正常输出说明你的编译器、标准库、线程支持、运行动态链接都是通的。4. 用 MinGW-w64 编译 OpenSSL、FreeGLUT 等常用库的真实记录4.1 编译 OpenSSL 的过程和参数选择依据热搜词里出现了“win64 openssl v1.1.1 light”说明不少人在 Win64 平台上装 OpenSSL 的时候遇到了疑惑——到底要不要自己编译我的看法是如果你只是开发用的开发库用预编译包省事得多但如果你想搞明白 OpenSSL 怎么和 MinGW 协作或者你生产环境有特定的编译选项需求那自己编译是值得的。用 MinGW-w64 编译 OpenSSL 的具体步骤是这样的# 先配置指定 MinGW 的交叉编译环境 perl Configure VC-WIN64A # 如果你是 MSVC 环境才用这个 perl Configure mingw64 --cross-compile-prefixx86_64-w64-mingw32- --prefix/d/openssl-build # 正式编译 (如果是多核CPU可以用 nmake/msbuild 之外的 mingw32-make) mingw32-make -j8 # 安装到指定目录 mingw32-make install_sw注意OpenSSL 的编译系统对于不同的编译器走的是完全不同的配置路线。VC-WIN64A是给 MSVC 用的mingw64是给 MinGW-w64 用的。如果你看到网上教程让你用前者但你自己装的是 MinGW那多半是复制粘贴错环境了。编译完之后你会得到一个包含 include、lib、bin 三个子目录的安装目录。用 MinGW 链接 OpenSSL 的时候编译参数大概是这样的g -o myapp.exe myapp.cpp -I/d/openssl-build/include -L/d/openssl-build/lib -lssl -lcrypto很多人在这里又会被坑MinGW 的库名一般是libssl.a和libcrypto.a但链接参数却是-lssl -lcrypto这是 GCC 链接器的默认命名规则——-lssl会自动去找libssl.a静态库或者libssl.dll.a动态库的导入库。如果你自己去翻目录看到libssl.dll.a这个文件那就是给动态链接用的链接的时候同样用-lssl就行不需要额外加.dll.a后缀。4.2 FreeGLUT for MinGW 的 32 位版本问题热词里提到“freeglut mingw 32位版本”这又是一个经典历史遗留问题。FreeGLUT 官方虽然提供 Windows 预编译二进制但那个包里只附带 MSVC 版的 .lib 和 .dllMinGW 开发者拿着那个包往往一头雾水——MinGW 的 GCC 链接器认的是.a后缀的库文件或者.dll.a而.lib文件虽然是微软的导入库格式GCC 不一定能直接吃。解决思路有两个方案一从 FreeGLUT 源码编译。下载源码后用 CMake 配置指定生成器为 “MinGW Makefiles” 或者直接用命令行cmake -G MinGW Makefiles -DCMAKE_BUILD_TYPERelease -DFREEGLUT_BUILD_DEMOSOFF ../freeglut-3.4.0 mingw32-make -j8这样生成的就是 libfreeglut.a 和 freeglut.dll完美匹配 MinGW。方案二下载别人已经为 MinGW 打包好的 freeglut。国内很多开源社区和博客里分享过百度云链接但我真心不建议你从那里下载——第一版本可能很旧第二你没法确认那个 exe/dll 里有没有夹带私货。自己编译一次以后你会对工具链的理解上一个台阶。顺便说个技巧FreeGLUT 在 CMake 构建时注意 CMake 的“选择编译器”步骤千万不要跳到 VS 的编译器去了。最简单的方式是直接在开始菜单里打开“MinGW-w64”提供的MinGW-w64 终端因为那个终端已经自动把 GCC 的路径加进环境变量了CMake 检测编译器时不会跑偏。4.3 那些“win64 的 instant client 19.23 basic 包”到底干什么用的你可能注意到了热搜词里还有一个“win64 的 instant client 19.23 basic 包”。这其实是 Oracle 官方给 Windows 64 位提供的数据库客户端库就是让 C/C 程序能直连 Oracle 数据库的一组 DLL 和头文件。为什么它会和 MinGW 一起出现因为很多业务系统用的是 Oracle 数据库而程序本身是用 MinGW 编译的。Instant Client 本身是一套纯 C 接口的库理论上 C 接口的库是可以跨编译器调用的只要你保证调用约定一致即可。所以实践中用 MinGW 编译的程序在运行时只需要把 Instant Client 解压到一个路径然后把这个路径加到 PATH 里程序里调用 OCI API 就能正常连库了。但这里有一个很微妙的坑OCI 的头文件里有些类型定义、宏定义和 MSVC 平台的默认行为有关。MinGW 的 GCC 在某些边界情况下比如#pragma pack或者 64 位指针的对齐方式上如果没处理好结构体布局会和 OCI 期待的不一致。这就可能导致程序在某些场景下莫名其妙崩溃要么内存读取错误要么参数解析失败。遇到这种问题时我建议你用 GCC 的-fpack-struct或者手动调整结构体对齐才能和 OCI 头文件里的布局保持一致。5. 让 MinGW 和 CodeBlocks、VS Code、VS 2022 配合起来5.1 CodeBlocks 25.03 自带 MinGW setup.exe 的真相热搜词“codeblocks 25.03 mingw setup.exe”其实就是 CodeBlocks 官方为了降低新人入门门槛直接把一个指定版本的 MinGW 工具链打包进了安装包。你只要下载带mingw字样的 CodeBlocks 安装包装完之后它会自动把 MinGW 配置到 CodeBlocks 里面你新建 C/C 项目的时候编译器那栏就是灰的啥都不用改就可以编译运行了。我自己经验是这种一站式方案非常适合教学场景和完全零基础的新手。但对老手来说这个内置的 MinGW 版本的更新速度通常落后于 WinLibs / MSYS2 的版本而且和 CodeBlocks 的安装目录深度绑定——如果你想用更新的 GCC 14 编译器就得自己手动去改 CodeBlocks 的“编译器设置 → 全局编译器设置 → 工具链可执行文件”里的路径。所以我的建议是新手先靠 CodeBlocks 自带的 MinGW 跑通基础流程等你玩熟了工具链配置再考虑用独立安装的 MinGW-w64 替换默认的编译器。5.2 VS Code 里的最佳实践tasks.json 和 launch.json 的配置思路VS Code 做 C/C 开发已经非常流行了但默认情况下微软官方的 C/C 扩展更偏 MSVC 和 GCC on Linux。要在 VS Code 里把 MinGW 当作编译器用起来你主要得配两个文件。tasks.json负责编译我常用的配置这样写{ version: 2.0.0, tasks: [ { label: mingw-g build, type: shell, command: g, args: [ -stdc17, -g, -O0, ${file}, -o, ${fileDirname}\\${fileBasenameNoExtension}.exe ], group: { kind: build, isDefault: true } } ] }launch.json负责调试把program指向刚才生成的 exemiDebuggerPath指向 gdb.exe 的位置{ version: 0.2.0, configurations: [ { name: MinGW Debug, type: cppdbg, request: launch, program: ${fileDirname}\\${fileBasenameNoExtension}.exe, args: [], stopAtEntry: false, cwd: ${fileDirname}, environment: [], externalConsole: false, MIMode: gdb, miDebuggerPath: D:/dev/mingw64/bin/gdb.exe } ] }配置完成后CtrlShiftB 编译F5 调试体验和 Visual Studio 相比差距不大但这套组合拳有一个最大的优势跨平台完全一致。你在 Linux 上写的 tasks.json / launch.json到了 Windows 上只需改一下command和miDebuggerPath的路径就行。5.3 VS 2022 进行 MinGW 编译一个冷门的打开方式很多人不知道VS 2022 其实也能结合 MinGW 使用。虽然 IDE 的主线程是围绕 MSBuild/MSVC 设计的但你可以在 VS 里打开一个“文件夹”项目Open Folder然后配置 C 的 CMake 设置指定 CMake 工具链为 MinGW。具体方法是在 VS 的 CMakeSettings.json 里加一个配置{ configurations: [ { name: x64-MinGW-Debug, generator: Ninja, configurationType: Debug, buildRoot: ${projectDir}\\out\\build\\${name}, cmakeExecutable: D:/dev/cmake-3.27.0/bin/cmake.exe, cmakeToolset: , inheritEnvironments: [ mingw64 ] } ] }注意那个inheritEnvironments: [ mingw64 ]这个值不是随便写的。VS 2019/2022 自带了一个名为mingw64的伪环境里面预设了常见的 MinGW bin 路径如果你的 MinGW 不在标准位置你得先手动把它加进系统 PATHVS 才能识别到。用 VS 2022 的意图很明显你既要享受 VS 的代码浏览、智能提示、Git 集成这些 IDE 功能又要用 GCC 编译以保证和 CI/CD 环境的一致性。这种混搭方式不常见但确实有人这么干而且用得很舒服。6. 常见问题与排查技巧实录6.1 几个让我记忆深刻的编译报错错误 1undefined reference to__imp___iob_func这个错误基本是 OpenSSL 或者一些老 C 库在 MinGW 下编译时的疑难杂症。原因是 MSVCRT 的 stdin/stdout/stderr 在 GCC 10 之前和 GCC 10 之后的符号导出规则不一样。解决方案有现成的补丁代码网上搜“__iob_func MinGW 补丁”能找到但更建议你直接升级 OpenSSL 到新版或者改用 UCRT 运行时库。错误 2fatal error: bits/stdc.h: No such file or directory在 MinGW 下bits/stdc.h这个万能头文件不一定存在。这是 GCC 在 Linux 上自带的私有头文件MinGW-w64 的发行版有好几种分支我实测 WinLibs 的包默认没有这个头文件遇到这个的解决方式有两个一是自己手动下载一个放进 include 目录二是在代码里别再图省事写这一个头文件了该写啥写啥。长期来看第二种更健康因为bits/stdc.h本身就包含了大量不必要的头文件拖慢编译速度。错误 3crt0.o: No such file: No such file or directory如果你在 MinGW 的 bin 目录里能看到 gcc.exe但一编译就报缺 crt0.o说明你多半是把编译器路径和启动文件路径搞乱了。MinGW-w64 编译器必须让它的 lib/gcc 目录和自身安装目录保持相对结构不能只拷贝 gcc.exe 单独用。遇到这个直接把整个压缩包重新解压别自己手动搬运文件。错误 4Mingw 编译的 exe 在别的电脑上缺少 libgcc_s_seh-1.dll默认情况下MinGW-w64 编译出来的程序是动态依赖libgcc_s_seh-1.dll、libstdc-6.dll、libwinpthread-1.dll这三个运行时库的。你开发机上能跑是因为你的 PATH 里有 MinGW 的 bin 目录但客户机器上没有。解决思路有两个把这三个 DLL 复制到 exe 同目录下一起分发编译时加-static-libgcc -static-libstdc -static-libwinpthread把这些运行库静态编进 exe 里我个人在交付工具类程序时几乎总是选择静态链接因为这样产出的就是一个单文件丢给谁都能直接跑省得客户那边报“找不到 xxx.dll”。缺点是 exe 体积会变大 1~3MB但现在硬盘和带宽都便宜这点体积真不算什么。6.2 排查编译问题的底层思路编译报错特别是链接报错很多新手一看红字就懵。这里我分享一套我自己用的排查口诀**先分“编译期”还是“链接期”再分“头文件”还是“库文件””。“编译期”报错一般定位到源码和头文件层面。报错信息里有.cpp:fatal error或者.h:No such file那是 include 路径没配对重点查-I参数和环境变量。“链接期”报错一般定位到库和符号层面。报错信息里有undefined reference to说明编译生成了目标文件但在链接阶段找不到对应实现。这时就要检查你-L参数指向的库目录里有没有正确的库文件以及链接参数-lxxx的顺序。MinGW 的链接器对库的依赖顺序是敏感的。-lssl -lcrypto和-lcrypto -lssl结果可能完全不一样如果你的库之间互相依赖建议多试几种顺序。这套思路不仅适用于 MinGW其实在任何有 GCC 的环境里都通用。把问题归类清楚一半以上的报错你都能自己解决不用复制粘贴去问别人。6.3 常见问题速查表建议收藏现象大概率原因直接解决方案gcc 找不到PATH 没配好或没重启终端确认 PATH 指向 bin 目录关掉终端重开编译正常双击 exe 无反应缺少运行时 DLL静态链接运行库或把 DLL 放 exe 同目录链接时报一堆 pthread 错误MinGW 线程模型选错重新安装选 posix 版本的 MinGW-w64gdb 无法设置断点编译时没加 -g 参数编译命令加上-gexe 在某些中文路径下启动失败路径编码不兼容项目路径不要用中文代码里也不要硬编码中文路径编译很慢CPU 占用却低没有并行编译mingw32-make 时加-j$(nproc)或-j8最后再分享几个我这些年的体感MinGW-w64 这套工具链我前前后后用了快五年从最开始只会用 CodeBlocks 里的内置编译器到后来自己手动管理多个 GCC 版本、给 OpenSSL 打补丁、调整 CMake 工具链走过的弯路真的不少。如果你现在刚开始接触我希望你能沉住气把环境配置这一步做扎实——不要在一个旧教程上下载了过时的包然后吐槽gcc版本太低也不要在报错时第一反应是卸载重装——花十分钟把报错信息复制到搜索引擎找到原因再动手改这个习惯比任何工具链都值钱。如果你只是在 Windows 上做一个低门槛的 C 语言学习者CodeBlocks 自带 MinGW 足以但如果你已经到“要自己编译第三方库”的阶段请直接拥抱 WinLibs 或 MSYS2并且从这一刻起学着用命令行、用 CMake、用 GCC 原生的参数——因为这些技能在 Linux 上同样有效。等你在 Win64 上把这一整套流程跑通了再切回 Linux 开发时你会发现一切都似曾相识因为你掌握的从来不是某个 IDE 的按钮位置而是工具链背后那套通用的逻辑。本文还有配套的精品资源点击获取