应安装mingw-w64而非已停更的老版mingw，下载sourceforge上x86_64-posix-seh离线包，解压后将bin路径（无空格、中文）添加至系统path环境变量，再用gcc -v验证。
gcc -v 报“不是内部或外部命令”？先确认你装的是哪个 MinGW
Windows 自带没有 gcc，必须手动安装第三方 GCC 移植版。但网上搜“MinGW”容易踩坑：老版 mingw.org 已停更，不支持 64 位、无维护、编译新标准代码（如 __attribute__((fallthrough))）会失败。真正该用的是 MinGW-w64 —— 它是当前唯一活跃维护、完整支持 C17/C++20、原生提供 32/64 位双架构的 GCC Windows 移植版本。
别下 mingw-get-setup.exe（那是老 MinGW），也别点进 mingw.org 下载页。直接去 MinGW-w64 官网下载页 或 SourceForge 的 mingw-w64-builds，选带 “x86_64” 和 “posix” 的离线包（例如 x86_64-13.2.0-release-posix-seh-rt_v11-rev0.7z），解压即用。
解压后 bin 目录加不进 Path？检查路径里有没有空格和中文
把解压后的 mingw64\bin（或类似路径）加进系统环境变量 Path 是关键一步。常见失败原因不是操作错，而是路径本身有问题：
- 路径含空格（如
C:\Program Files\mingw64\bin）→ Windows 命令行会截断，改成C:\mingw64\bin - 路径含中文（如
D:\开发工具\mingw64\bin）→gcc启动时加载运行库失败，报错libgcc_s_seh-1.dll not found - 复制路径时多了一个反斜杠（如
C:\mingw64\bin\）→ 某些 Windows 版本会识别异常，删掉末尾\
验证方式：打开新 cmd 窗口，直接输 gcc -v。如果仍报错，用 where gcc 看是否命中了其他残留的旧版本（比如某 IDE 自带的旧 gcc），删掉冲突路径。
hello.c 能编译但 a.exe 运行崩溃？缺运行时 DLL 是主因
用 gcc hello.c 成功生成 a.exe，双击却闪退或报“缺少 libwinpthread-1.dll”，说明运行时依赖没打包进去。这不是编译问题，是链接阶段默认动态链接导致的：
- 临时解决：把
mingw64\bin下的libwinpthread-1.dll、libgcc_s_seh-1.dll、libstdc++-6.dll复制到a.exe同目录 - 一劳永逸：编译时加
-static-libgcc -static-libstdc++参数，例如：gcc -static-libgcc -static-libstdc++ hello.c -o hello.exe，生成纯静态可执行文件 - 注意：加
-static会把整个 libc 静态链接，体积暴涨且可能引发符号冲突，不推荐
想用 make 或调试？gdb 和 make 不是默认自带的
gcc 包本身只含编译器，gdb（调试器）、make（构建工具）、ld（链接器）等需单独确认是否包含。主流 MinGW-w64 离线包（如 SourceForge 上的 mingw-w64-builds）通常都带，但精简版（如某些 TDM-GCC）可能阉割。
验证方法：
-
gdb --version→ 无输出？说明没装或不在Path -
make --version→ 报错？Windows 原生make不是 GNU Make，得装mingw32-make（名字就叫这个） - 若缺失，最稳方案是换用
MSYS2：它用pacman管理工具链，一条命令就能装齐：pacman -S mingw-w64-x86_64-gcc mingw-w64-x86_64-gdb mingw-w64-x86_64-make
最后提醒一句：MinGW-w64 的 gcc 默认生成的是 Windows 原生 PE 格式程序，不依赖 Cygwin 或 MSYS2 的 POSIX 层。只要 bin 路径正确、DLL 依赖处理得当，它就是最接近 Linux 下 GCC 体验的 Windows 编译器——别被名字里的 “MinGW” 欺骗，重点在后面的 “-w64”。
