删 build 目录是最安全的清理方式，因 cmakecache.txt 和 cmakefiles/ 中残留旧状态（如编译器路径、系统库变更）易导致配置失效，官方推荐彻底删除 build 后重新 cmake -b 配置。
删 build 目录是最安全的清理方式
缓存问题八成以上都源于 CMakeCache.txt 和 CMakeFiles/ 里残留的旧状态，比如编译器路径变了、系统库升级了、甚至只是换了台机器——这些都会让缓存里的值（如 CMAKE_C_COMPILER:FILEPATH=/old/path/gcc）失效，但 CMake 默认不会主动校验。直接删掉整个 build 目录，等于把缓存、中间文件、生成的 Makefile/Ninja 文件全清空，下次 cmake -B build 就是干净重启。
这不是“暴力”，而是 CMake 官方推荐的惯用做法。CMake 本身没有 cmake clean 命令，原因正是：缓存和构建产物深度耦合，分开清理容易漏项或引发不一致。
- 执行
rm -rf build/（Linux/macOS）或rmdir /s build（Windows cmd） - 再运行
cmake -S . -B build重新配置 - 如果用 Ninja，确保
build下没残留build.ninja或.ninja_deps
CMakeCache.txt 单独删除的风险与适用场景
只删 CMakeCache.txt 看似省事，但容易踩坑：它不会重置 CMakeFiles/ 里的检测结果（比如 CheckIncludeFile.c 生成的测试可执行文件），也不会清理已生成的 Makefile 或 compile_commands.json。结果就是 CMake 以为“要重新检测”，但底层构建系统还在用旧规则，报错可能更隐蔽。
仅在以下情况考虑单独删 CMakeCache.txt：
- 你确认只是某个缓存变量写错了（比如手改过
CMAKE_BUILD_TYPE），且构建目录里没其他变动 - 项目很小、编译快，能接受重建所有中间文件
- CI 流程中为节省磁盘空间，明确控制只清缓存不删对象文件（但需配套清理
CMakeFiles/子目录）
用 -D 覆盖缓存比手动编辑更可靠
遇到 “修改了 CMakeLists.txt 里的 option() 却没生效”，别去改 CMakeCache.txt ——它的格式极其敏感（冒号后必须有空格、类型声明不能少），且改完不触发验证。正确做法是用命令行参数强制覆盖：
cmake -B build -DUSE_JPEG=OFF
这会直接写入缓存并跳过已有值的判断。如果想让某变量每次都按 CMakeLists.txt 里写的默认值走（无视缓存），就用 set(... FORCE)，而不是依赖用户界面或手改文件。
CLion 或 VS Code 插件里点 “Reload CMake Project” 不等于清理缓存
IDE 的重载按钮通常只触发 cmake --build 或增量配置，不会删 CMakeCache.txt。尤其当编译器升级（如从 gcc-11 换到 gcc-13）、CMake 版本跨大版本（3.22 → 3.28）时，缓存结构可能不兼容，IDE 重载反而会让错误更难定位。这时候必须退出 IDE，手动删 build 再重开。
真正需要警惕的是那些“看起来没变但其实变了”的环境因素：WSL 虚拟机重启后 PATH 变了、Docker 容器里挂载路径权限调整、甚至 macOS 上 Xcode 命令行工具更新后 xcode-select --install 指向了新位置——这些都不会被 IDE 自动感知，但会立刻让缓存失效。
