1. Windows 上跑 GCC，先得把几组概念理清楚
每次在群里看到有人说“我要装个 MinGW”，我就习惯性追问一句：你说的是哪个 MinGW？这不是抬杠，是因为这个词在 Windows 上指代的东西已经乱了很多年。原生 MinGW 项目早就停在 GCC 3.4 那个年代，只支持 32 位，连 C++11 都啃不动；后来社区拉出的 MinGW-w64 才是今天真正的继任者，支持 64 位、支持新标准、维护到现在；TDM-GCC 是在 MinGW-w64 基础上重新打包、加了点补丁的一体化安装包；MSYS2 则是一整套 POSIX 环境加 pacman 包管理，里面挂着好几套彼此隔离的 GCC 工具链。这四者经常被混为一谈，选型时一糊涂，后面编译报错、DLL 丢失、调试器对不上号，全是连锁反应。
这篇东西我打算把自己这几年在 Windows 上折腾 GCC 的实际记录整理一遍，从概念谱系、运行时库差异、异常模型代价，一直写到三套环境的具体搭建步骤、实测对比数据、以及那些文档里不会写、只有把构建跑崩几次才能记住的坑。适合两类人看：一类是刚接触 Windows 原生编译、搞不清 MinGW 和 MSYS2 到底谁是谁的；另一类是在做跨平台 C/C++ 工程，需要在 Windows 上维护一套稳定、可复现的 GCC 构建链路的。哪怕你现在只用 Visual Studio 那一套，看完也会对“为什么同一份代码换个编译器就跑不起来”有更具体的感觉。
我先把一个最容易被忽略的前提摆出来：GCC 编译器本体和它在 Windows 上的发行版是两码事。GCC 上游只提供源码，谁把它编成 Windows 上能跑的二进制、顺手附带哪些运行时和头文件、用什么方式分发包，这些全由发行方决定。所以“GCC 版本号一样”不等于“工具链行为一样”，差别往往就藏在打包方式里。
1.1 一条时间线，把四个名字的辈分理顺
原生 MinGW（mingw.org 那个）是 Windows 上最早的一批 GCC 移植，靠一套 msvcrt.dll 的导入库加 Windows API 的头文件，让 GCC 生成的 PE 程序能直接调用系统 DLL。它的历史贡献很大，但后来卡在 32 位、卡在老版本 GCC 上，基本等于退役状态。今天你如果在某个教程里看到“下载 MinGW，解压到 C:\MinGW”，八成是十年前的帖子。
MinGW-w64 是另一拨人从 MinGW 分出来的分支，目标一开始就很明确：支持 64 位、跟进上游 GCC 版本、补齐 Windows API 覆盖。它同时提供 32 位和 64 位两套目标，也是现在所有主流方案共同的上游——TDM-GCC 基于它，MSYS2 里那几个 mingw 环境的编译器也基于它。
TDM-GCC 的定位是“开箱即用”。作者把 MinGW-w64 的工具链重新编译，做成一个 Windows 安装程序，点几下就能用，不需要额外准备 shell 或者包管理器。它在学生群体和教学场景里流行过一阵子，因为安装门槛低。缺点是发布节奏跟上游脱节比较明显，版本经常落后好几年，一些新特性用不上。
MSYS2 走的是另一条路。它继承 Cygwin 那套 POSIX 模拟层的思路，但只在/usr这个子树里启用模拟，/mingw64、/ucrt64这些目录里放的是纯 Win32 原生程序，不经过 POSIX 转换。它自带 pacman，包管理和 Arch 那一套很像，装库、升级工具链都是一条命令的事。代价是概念多一点，刚开始容易被“我到底该在哪个终端里敲命令”绕晕。
1.2 为什么这个区分对选型是决定性的
因为这四个名字背后对应的是三种完全不同的工程哲学：一次性安装包、手工可移植目录、包管理驱动的滚动环境。
一次性安装包适合“我就想今天下午把作业编译出来”的场景，装完就能用，但版本锁定，团队里两个人装的包可能不是同一个构建，出了问题很难对齐。手工可移植目录适合把工具链塞进版本库或者随项目分发，好处是可控，坏处是依赖库得自己一个个补，装了十个第三方库之后维护成本陡增。包管理驱动的环境适合长期项目，库依赖一条命令解决，但要求你理解它的目录结构和环境隔离规则，否则很容易出现“明明装了却说找不到头文件”的情况。
我在实际项目里最后落在 MSYS2 上，根本原因不是它性能多好，而是第三方库的获取成本。Windows 上编译一个依赖 zlib、openssl、libpng 的小工具，手工凑依赖库的时间可能比写代码还长，pacman 一句pacman -S mingw-w64-x86_64-zlib就完了。这个差异在 demo 级别看不出来，在真实工程里是压倒性的。
2. 核心差异逐项拆解：选错会在哪里付出代价
真正决定“用哪套”的，不是安装方式，而是几个底层参数：运行时库、异常模型、线程模型、路径语义。这几个东西在编译选项里往往是一两个词，但它们决定了生成的二进制能不能在你目标的机器上跑、跑得对不对、崩了以后调试器能不能给你像样的调用栈。
2.1 运行时库：MSVCRT 与 UCRT 的分水岭
Windows 上的 C 运行时有两条主线。老的叫 MSVCRT，从很早的系统开始就随系统自带，兼容性极好，但实现陈旧，对 C99/C11 的一些细节支持不完整，printf的格式化行为、宽字符处理都有历史遗留问题。新的是 UCRT（Universal C Runtime），从 Windows 10 起随系统提供，对标准的符合度好得多，也算得上是当前 Windows 上 C 运行时的正确选择。
MinGW-w64 两种都支持，编译器前缀上通常体现为x86_64-w64-mingw32（MSVCRT）和x86_64-w64-mingw32ucrt（UCRT）之类的命名差异。MSYS2 里则直接分成了mingw64和ucrt64两个独立环境，各自有完整的工具链和包仓库。
这件事为什么重要？因为它直接决定了你的程序最低能跑在什么系统上。用 UCRT 编译出来的程序，在比较老的系统上可能缺ucrtbase.dll，需要额外分发运行时。反过来，如果你必须支持老旧环境，MSVCRT 那条线更稳妥。我见过有人本地跑得好好的，拷到客户机器上直接弹“缺少 ucrtbase.dll”，就是这个问题。
还有一个隐蔽的坑：同一个进程里混用两个运行时是危险的。如果你的主程序用 MSVCRT，某个第三方 DLL 用 UCRT 编译，两边各自有自己的FILE*结构、自己的堆管理、自己的 locale 状态，fopen出来的句柄传给对方fclose就是未定义行为。这种问题往往不立刻崩，而是在某个随机时刻炸掉，排查起来极其痛苦。所以一旦定了运行时，整条依赖链都得统一。
注意：判定的方法很直接，用
objdump -p your.exe | findstr "DLL Name"看导入表。出现msvcrt.dll就是老运行时，出现api-ms-win-crt-*系列或者ucrtbase.dll就是 UCRT。第三方 DLL 也照这个方法查一遍，别偷懒。
2.2 异常模型：SJLJ、DWARF-2、SEH 的真实代价
这个参数在 Windows 上尤其容易被忽略，因为 Linux 下根本没有这个概念——那边统一走 DWARF 展开。Windows 上因为 ABI 不同，GCC 得自己实现一套异常展开机制，于是有了三个选项。
SJLJ 是最老的做法，用setjmp/longjmp把每个可能抛异常的调用包一层，性能开销最大，但不挑架构，32 位 64 位都能用，异常可以穿越不认识的栈帧。DWARF-2 基于调试信息里的展开表，性能比 SJLJ 好不少，但有个硬伤：异常无法穿过没有展开信息的栈帧，比如系统 DLL 回调进来的那段。SEH 是 Windows 原生机制，零开销表驱动，性能最好，但只有 64 位目标支持。
实测下来的感受是：在正常代码里，三者的差别你基本感觉不到。我做过一个简单的递归 + 异常抛接循环，SJLJ 版本比其他两个慢大概两三成，但那是极端构造。真正有影响的是边界场景——如果你的 C++ 代码要被系统回调，而异常可能一路抛出来，SJLJ 是唯一稳的选择；如果纯 64 位桌面程序，SEH 没理由不用。
默认值方面，64 位目标通常默认 SEH，32 位目标默认 DWARF-2 或 SJLJ，具体看发行版怎么配。MSYS2 的 64 位环境默认是 SEH，这点不用操心。反倒是自己手工拼工具链的时候，选错了模型，编译能过、跑也能跑，但异常一旦跨模块就静默失效，非常难查。
2.3 线程模型：posix 和 win32 不是同一个东西
GCC 的-mthreads背后有两套实现。win32 模型直接用 Windows 原生线程 API 实现std::thread，轻量、直接；posix 模型则是在 Windows 上模拟一套 pthread 接口，std::thread走的是这层模拟。
大部分时候两者对使用者透明，但涉及std::thread和std::condition_variable的代码，posix 版本的实现路径不一样，某些边界行为（比如析构时机、超时精度）会有细微差异。更实际的影响是：posix 模型会引入libwinpthread-1.dll这个运行时依赖。你要是打包发给别人，忘了带这个 DLL，程序直接起不来。
我自己的习惯是编译时显式加-static或者至少-static-libgcc -static-libstdc++ -Wl,-Bstatic -lstdc++ -lwinpthread，把这层依赖吃掉，省得后面为了一个 DLL 反复折腾。代价是二进制大个几百 KB，在今天的磁盘和网络条件下完全不值一提。
2.4 包管理与工具链完整性
这一条其实是 MSYS2 最硬的护城河。除了 GCC 本体，一个能干活的环境还需要：调试器、make 或 ninja、pkg-config、binutils、以及各种第三方库的头文件和静态/动态库。MSYS2 里这些全在一个包体系下，版本互相匹配，升级时一起升。
TDM-GCC 和手工部署的 MinGW-w64 就没这个待遇。调试器要单独下，版本还得和 GCC 对得上；第三方库要么自己编，要么去网上找别人编好的二进制包，版本、ABI、编译选项全靠猜。你有过那种经历吗——辛辛苦苦下了个预编译的库，结果链接时报一堆undefined reference，最后发现对方是用不同异常模型编的。这种坑在没有包管理的情况下是常态。
2.5 路径空间与环境隔离
MSYS2 的目录布局是/、/usr、/mingw64、/ucrt64这么分的。/usr/bin里放的是 MSYS 自己的工具，这些工具是 POSIX 模拟程序，处理路径时会做转换；/mingw64/bin里放的是原生 Windows 程序，不认识/c/Users这种写法。
这个设计本身很合理，但新手最容易在这里翻车：在 MSYS 终端里cd /mingw64/bin，然后跑gcc main.c -I/usr/local/include，结果 gcc 把/usr/local/include当成了 Windows 盘符相对路径，报找不到。原因是 gcc 是原生程序，它对/开头的字符串有自己的解释规则（有时当选项前缀）。
解决办法是养成用cygpath -w转换的习惯，或者在 CMake 里用file(TO_CMAKE_PATH ...)统一。更省事的做法是干脆不写绝对路径，全部用相对路径或者环境变量，让构建系统自己处理。
3. 三套环境的搭建实录
下面是我自己重复过很多次的三套搭建流程，按从简单到复杂的顺序写。每一步我都标了为什么这么做，你要是只想抄作业，跳过解释直接看命令也行。
3.1 MSYS2：从零到能编译
先去项目主页下安装包，装到一个没有空格、没有中文的路径下，比如C:\msys64。这不是强迫症，MSYS2 的部分脚本对空格处理不好，装到C:\Program Files\msys64会遇到各种诡异问题，我曾经为此浪费了一个下午。
装完先更新基础包，这一步不能跳：
pacman -Syu第一次跑完它会让你关掉终端重开，然后再跑一次pacman -Syu把剩下的更新完。这个行为是 MSYS2 的已知设计，别以为是出错了。
接着装工具链。选哪个环境取决于你要 MSVCRT 还是 UCRT：
# UCRT 环境（推荐，新项目首选） pacman -S mingw-w64-ucrt-x86_64-toolchain # 或者传统 MSVCRT 环境 pacman -S mingw-w64-x86_64-toolchain-toolchain是个包组，会一次装上 gcc、g++、gdb、binutils、make、pkg-config 一整套。装的时候会问你要装组里的哪些，直接回车全装就行。
然后必须用对应的启动器打开终端：MSYS2 UCRT64或者MSYS2 MINGW64。用默认的那个MSYS2 MSYS终端是不行的，那里面没有工具链，which gcc会是空的。这一点我见过太多人卡住。
验证：
gcc --version g++ --version gdb --version which gccwhich gcc应该输出/ucrt64/bin/gcc之类的路径。如果输出的是/usr/bin/gcc，说明你进错终端了。
3.2 TDM-GCC：一次性安装包的适用场景
这个最简单，下载安装包，一路下一步，勾选“加入 PATH”（如果你只用这一套工具链的话）。装完开个 cmd 或者 PowerShell，gcc --version应该直接有输出。
它适合的场景其实很窄：单机、单人、不需要复杂第三方库、不想折腾环境管理。比如教学演示、临时的算法验证、给非开发同事准备一个能跑的编译环境。
不适合的场景也很明确：需要多个 GCC 版本共存、需要频繁升级、需要一堆第三方库。它的版本更新慢，我印象里某些版本停留在 GCC 9 甚至更早，用 C++20 的新特性会直接报错。
3.3 精简版 MinGW-w64 手工部署
有些场景你就是不想要整个 MSYS2，比如要做绿色版工具链、要塞进 CI 的容器镜像、要在别人的机器上快速复现。这时候可以下 MinGW-w64 的独立构建包，解压到一个目录，把bin加进 PATH 就行。
关键点是认准构建配置。同一个下载页面会有几十个压缩包，文件名里通常编码了这些信息：架构（i686 / x86_64）、线程模型（posix / win32）、异常模型（sjlj / dwarf / seh）、运行时（msvcrt / ucrt）。选错一个，后面就是无尽的麻烦。
我的选择是：x86_64+posix+seh+ucrt。理由前面说过，64 位下 SEH 性能最好，posix 线程模型兼容性更广（很多跨平台库假设 pthread 语义），UCRT 是当前正确选择。
解压完记得验证一下编译器自带的配置：
gcc -v输出的最后几行会显示Thread model、Target、Configured with等信息，能直接看出这个构建是什么配置。养成看这个的习惯，比看文件名可靠。
3.4 三套并存时的环境变量管理
如果你像我一样机器上同时装着 MSYS2 和别的工具链，PATH 的管理就很关键。Windows 的 PATH 是顺序查找，谁在前面谁生效，很容易出现“我在 A 终端里编译，实际用的是 B 的 gcc”。
我的做法是不在系统 PATH 里放任何 GCC，全部靠启动脚本注入。写几个.bat，内容大致是：
@echo off set PATH=C:\msys64\ucrt64\bin;C:\Windows\System32;C:\Windows set CC=gcc set CXX=g++ cmd /k每个脚本对应一套工具链，需要哪套就点哪个。这样做的额外好处是环境干净，不会因为某个软件装了个老版本 GCC 到 PATH 里，导致构建行为莫名其妙地变。
如果你用 VS Code，可以在工作区的settings.json里给 CMake 指定cmake.generator和工具链路径，效果类似，不用来回切终端。
4. 用一个小工程做横向验证
光说理论没意思，我在一台普通的开发机上用同一份代码跑了三套环境，记录了一些数据。先说清楚，这些数字受机器配置、磁盘类型、杀毒软件策略影响极大，只能看量级和趋势，别当成基准测试。
4.1 测试工程设计
代码是一个约 8000 行的 C++ 小项目，包含 40 多个源文件，依赖标准库的线程、正则、文件系统，另外链接了 zlib 和一个图像解码库。构建用 CMake + Ninja，编译选项统一为-O2 -g，开启-Wall -Wextra。
选这个规模是因为太小了看不出差异，太大了跑一轮要等太久。8000 行这个量级刚好能体现 I/O 和链接阶段的开销。
4.2 编译速度与产物体积
| 环境 | 完整构建耗时（冷缓存） | 增量构建（改 1 个文件） | 可执行文件大小 | 依赖 DLL 数量 |
|---|---|---|---|---|
| MSYS2 UCRT64 | 约 95 秒 | 约 4 秒 | 2.1 MB | 3 个系统 DLL |
| MSYS2 MINGW64 | 约 98 秒 | 约 4 秒 | 2.2 MB | 3 个系统 DLL |
| 独立 MinGW-w64 包 | 约 92 秒 | 约 4 秒 | 2.0 MB | 3 个系统 DLL |
| TDM-GCC（老版本） | 约 140 秒 | 约 7 秒 | 2.4 MB | 5 个（含 libwinpthread 等） |
结论很朴素：编译速度差异主要来自 GCC 版本和链接器，跟发行版关系不大。独立包稍快，大概率是因为它没有被包管理器的额外钩子干扰，也可能只是那一次磁盘缓存状态好。TDM-GCC 慢，是因为它带的 GCC 版本老，对std::filesystem这类重度模板代码的编译效率明显差一截。
产物体积和 DLL 依赖这两列更有参考价值。TDM-GCC 那行多出来的依赖，就是没静态链接 libstdc++ 和 winpthread 的后果。我给的建议始终是：发布版本一律静态链接 GCC 运行时。
4.3 静态链接的正确姿势
网上很多说法只提到-static-libgcc -static-libstdc++，但这两个选项管不到 winpthread。完整的做法是：
g++ main.cpp -o app.exe -O2 \ -static-libgcc -static-libstdc++ \ -Wl,-Bstatic -lstdc++ -lpthread -Wl,-Bdynamic或者更彻底，直接-static，让它把所有能找到的静态库都静态进去。代价是某些库（比如依赖系统 DLL 的部分）会被跳过，链接器可能给警告，但一般不影响。
链接完再查一遍依赖：
objdump -p app.exe | findstr "DLL Name"理想情况下只剩KERNEL32.dll、msvcrt.dll（或 UCRT 那一串）、USER32.dll这几个系统组件。如果还看到libgcc_s_seh-1.dll、libstdc++-6.dll、libwinpthread-1.dll，说明静态链接没生效，回头检查命令顺序——库的链接顺序在 GCC 里是有语义的，被依赖的库要放在后面。
提示：
-Wl,-Bstatic和-Wl,-Bdynamic是成对使用的开关，中间夹着的库走静态，后面恢复动态。如果你漏了后半段，后面所有库都会尝试静态链接，可能报一堆找不到.a的错误。
5. 高频问题与排查手册
下面这些是我在实际项目里反复遇到的，按“链接期 / 运行期 / 编码与路径 / 构建系统配合”分类整理。每一条都标了典型症状和排查动作，可以直接当速查表用。
5.1 链接期问题速查
| 症状 | 大概率原因 | 排查动作 |
|---|---|---|
undefined reference to 'WinMain' | 写了main但链接器按 GUI 子系统找入口 | 检查是否有-mwindows，去掉它 |
undefined reference to 'std::xxx' | 用gcc而不是g++链接 C++ 代码 | 改用g++，或手动加-lstdc++ |
大量undefined reference但库明明装了 | 库顺序不对，或被依赖库放在前面 | 把基础库放后面，-lz -lpng这类放最后 |
cannot find -lxxx | 库路径没加，或者架构不匹配 | 加-L路径，用objdump -f查.a的架构 |
链接时提示file format not recognized | 混入了 MSVC 的.lib | GCC 用不了 MSVC 的导入库，找 MinGW 版本 |
“库顺序”这条值得多说两句。GCC 的链接器是单遍扫描，遇到一个.o时它会去后面的库里找符号，找完就往前走不回头。所以-lA -lB里如果 A 依赖 B，顺序就是对的；反过来就报错。CMake 的target_link_libraries一般会帮你处理好依赖关系，手工写命令行时就得自己留意。
5.2 运行期问题速查
| 症状 | 大概率原因 | 排查动作 |
|---|---|---|
| 双击没反应，命令行跑正常 | 子系统是 console，或者程序立刻退出了 | 加-mwindows，或检查是否有异常 |
| 弹窗提示缺少某个 DLL | 没静态链接运行时 | 用objdump -p查导入表，补静态链接选项 |
| 启动就崩，调试器里栈是乱的 | 异常模型不匹配 | 用gcc -v查异常模型，统一整条依赖链 |
| 释放内存时崩溃 | 跨运行时混用堆 | 检查是否有 DLL 用了不同的 C 运行时 |
| 中文输出是乱码 | 代码页不匹配 | 见下一节的编码处理 |
“跨运行时混用堆”这个问题我踩过最狠的一次，是一个第三方 DLL 返回了它自己new出来的对象指针，主程序用delete释放，两边堆管理器不同，直接触发堆损坏。这种问题在 Debug 版下可能被堆检查抓住，Release 版就是随机崩溃。解决办法只有一条：跨 DLL 边界的内存分配和释放，必须由同一方负责，要么提供destroy接口，要么用shared_ptr带自定义删除器。
5.3 编码、换行与中文路径
GCC 默认把源文件按 UTF-8 解析。如果你的文件是 GBK 存的，里面又有中文注释或字符串，编译会直接报converting to execution character set之类的错误。
处理方式有两种。彻底的做法是把所有源文件统一转成 UTF-8，然后加-fexec-charset=UTF-8，运行时配合SetConsoleOutputCP(CP_UTF8)输出。这个方案在现代 Windows 上完全可行，也是我推荐的做法。
兼容老环境的做法是保留 GBK 源文件，编译时加：
-finput-charset=GBK -fexec-charset=GBK意思是“输入按 GBK 读，输出也按 GBK 生成”。这样运行时控制台默认代码页 936 就能正确显示，缺点是跨平台会出问题，移植到其他系统时又得改回来。
换行符的问题更隐蔽。Git 在 Windows 上默认core.autocrlf=true，检出的文件是 CRLF。大部分情况无害，但有些脚本（尤其是 shell 脚本）带 CRLF 会给出一堆莫名其妙的错误，比如$'\r': command not found。我的建议是仓库里放一个.gitattributes，明确规定*.sh text eol=lf、*.c text eol=lf，别让每个人的本地配置决定文件格式。
中文路径这块，新版 GCC 基本没问题，但历史上出过不少事。稳妥起见，构建目录和源码目录都不要带中文和空格。这一条听起来是老生常谈，但每年还是能看到有人在这上面栽跟头，尤其是构建缓存路径里带用户名的中文时。
5.4 与 CMake、IDE 的配合
CMake 在 Windows 上跑 GCC，最容易撞的坑是生成器选择。
用MinGW Makefiles生成器时，CMake 会检查 PATH 里有没有sh.exe，有的话直接报错拒绝对话。这个检查的逻辑是它担心 sh 和 make 用的路径语义不一致。解决办法要么是用Ninja生成器（我最推荐的，最省事也最快），要么确保 PATH 里没有多余的sh.exe。
用MSYS Makefiles生成器时，Make 程序用的是 MSYS 那一套，路径转换由它负责，但要求你在 MSYS 终端里执行。混着用容易出现路径来回转换出错的症状。
调试配置上，VS Code 的launch.json里miDebuggerPath要指到正确的 gdb，program指到带调试符号的 exe。如果混淆了两套环境的 gdb（比如用 MSYS 的 gdb 调 mingw64 编出来的程序），符号加载可能对不上，断点乱跳。这类问题没有报错，只有诡异现象，最容易卡住人。
6. 我的选型结论和工程落地建议
绕了一大圈，回到最开始那个问题：到底怎么选。我的答案不是“哪个更好”，而是分三个层次给结论。
6.1 分场景的选型对照
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 新项目、需要第三方库、长期维护 | MSYS2 UCRT64 | 包管理省心，运行时现代，工具链完整 |
| 需要兼容老系统（Win7 及更早） | MSYS2 MINGW64 | MSVCRT 兼容性更好，不需额外分发运行时 |
| 单人临时验证、教学演示 | TDM-GCC 或独立包 | 装完就用，不引入额外概念 |
| CI 容器、绿色分发 | 独立 MinGW-w64 包 | 体积可控，无包管理器依赖，易复现 |
| 需要多版本 GCC 并存 | MSYS2 多环境 | 天然隔离，切换成本低 |
再补一个维度：如果团队里有人用 Visual Studio，有人用 GCC，一定要在项目初期就把边界划清楚。两边共用同一份头文件是可以的，但一旦涉及 ABI 交互（比如互相调用对方的 DLL），就必须统一 C 接口、统一运行时、统一内存归属。这些事等出了线上崩溃再补，成本翻好几倍。
6.2 让构建可复现的几个具体做法
第一，锁版本。MSYS2 是滚动更新的，今天pacman -S装的版本和三个月后装的不一样。项目里放一份packages.txt记录关键包的版本号，用pacman -Q导出，新人搭环境时对着装。这不是形式主义，是真能减少“我这能编你那编不过”的扯皮。
第二，构建目录加杀毒白名单。这一条纯经验：Windows Defender 的实时扫描会让编译速度腰斩，我实测过把构建目录和工具链目录加进排除项，构建时间能减少三成到一半。尤其是大量小文件的 C++ 项目，效果非常明显。这条我在任何官方文档里都没见过，但它是所有 Windows 上做 C++ 的人的共同秘密。
第三，把编译选项收进 CMake，不要散落在命令行里。-static-libgcc这种东西一旦靠人记，就会漏。写成target_link_options或者用 toolchain 文件统一管理，比写十个 README 都有用。
第四，保留一份“最小可复现示例”。当你遇到链接错误、运行时崩溃这类问题，先把代码抽到一个最简单的能重现的文件里，再去找原因。我见过太多人直接在几万行的工程里改编译选项，改到最后都不知道是哪个改动生效了。抽小样本这十分钟，往往能省掉后面两小时。
最后分享一个我自己用了很久的习惯：在每套工具链的启动脚本里，顺手把gcc -v的输出重定向到一个日志文件。遇到任何“奇怪”的编译行为，先翻这个日志确认当前用的到底是哪个编译器、哪个配置，再往下查。这一步能过滤掉至少三成的误判——很多时候问题不是代码写错了，而是你以为在用 A，实际在用 B。
