CLion报“broken compiler”主因是启动时未加载新PATH或gcc Target不匹配；应从已设好PATH的终端启动CLion，或在Toolchains中手动指定gcc绝对路径，并确保Target为x86_64-w64-mingw32。
gcc 命令在终端能用，CLion 却报 “broken compiler” 或根本找不到编译器？这不是环境变量没配好，而是 CLion 启动时压根没读到你改的 PATH，或者它找到了 gcc 却连最简单的 int main(){return 0;} 都编译失败——这说明工具链 ABI 不匹配，不是“有没有”，而是“能不能用”。
CLion 启动后 PATH 不生效怎么办
Windows 下从开始菜单或桌面快捷方式启动 CLion，它继承的是系统启动时的环境变量快照，不会动态加载你刚在终端里 set PATH=... 或修改注册表后的值。哪怕你在 CMD 里 echo %PATH% 能看到 gcc 路径，CLion 也看不到。
- 最可靠做法：完全退出 CLion，在一个已正确设置
PATH的终端（如 PowerShell 或 CMD）中，用绝对路径启动：start "" "C:\Program Files\JetBrains\CLion 202X.X\bin\clion64.exe" - 次选方案：进
Settings → Build → Toolchains，手动把C Compiler设为完整路径，例如D:\mingw64\bin\gcc.exe，彻底绕过PATH查找逻辑 - 别信“重启电脑就行”——只要 CLion 不是从新环境的终端启动，问题依旧
gcc -v 显示 Target 不匹配导致链接失败
CLion 报 skipping incompatible libkernel32.a 或 Detecting C compiler ABI info - failed，核心是 gcc 输出的 Target 字段和项目期望的不一致。比如项目设为 x86_64-pc-windows-gnu，但你装的是 TDM-GCC（默认链接 msvcrt），它的 Target 是 x86_64-pc-windows-msvc。
- 运行
gcc -v，看最后一行Target:输出，必须是x86_64-w64-mingw32这类 GNU 目标，不能是msvc - CLion 自带的
mingw目录（如clion/bin/mingw/bin/gcc.exe）和你手动装的 MinGW 冲突，直接删掉 CLion 自带的mingw文件夹 - Linux/macOS 用户注意：
CC环境变量对 CLion 内置 CMake 无效，必须在CMakeLists.txt里写set(CMAKE_C_COMPILER "/opt/gcc-12.2.0/bin/gcc")才管用
调试器 gdb 灰掉或报 Unable to start debugging process
CLion 的 Toolchain 要求编译器和调试器来自同一发行版。混用 MSYS2 的 gdb、Cygwin 的 gdb 和 MinGW-w64 的 gcc，99% 会失败。
- 检查
gdb --version输出里的Target:，必须和gcc -v完全一致 -
Debugger字段必须填gdb.exe的绝对路径，不能只写gdb；路径里不能含空格或中文（哪怕PATH里能用，CLion 这里会崩） - 常见陷阱：下载了独立
gdb包但没配libexpat.dll、zlib1.dll等依赖，放进gdb.exe同目录即可
CMake 构建缓存错位引发路径冲突
项目移动过位置、重命名过文件夹，或者切换过构建类型（Debug/Release），就可能触发 CMakeCache.txt 记录的旧路径与当前实际路径不一致，导致配置失败甚至静默跳过某些 target。
- 不要手动删
CMakeCache.txt—— 它只是症状，不是病因；直接删整个cmake-build-*目录更安全 - CLion 中点击
File → Reload project不起作用，必须点右上角Build → Clean，再点Build → Rebuild - 如果反复出问题，关掉 CLion，进终端执行
rm -rf cmake-build-*，再重新打开项目
CLion 编译环境异常的根子，往往不在“会不会配”，而在“它用的是哪一套路径、哪个时刻的环境、哪一版工具链”。手动指定绝对路径、验证 Target 一致性、清掉整套构建目录——这些动作看起来笨，但比反复调环境变量更接近真相。
