必须删除整个build目录，因为仅删CMakeCache.txt会遗漏CMakeFiles/中的检测结果、自动生成头文件及生成器元数据，导致缓存与实际环境脱节，引发构建失败或静默错误。

CMake 没有内置的 cmake clean 命令，清理缓存必须手动操作或靠目录隔离 —— 直接删 build/ 是最可靠、最省心的做法。

为什么不能只删 CMakeCache.txt？

单独删 CMakeCache.txt 看似轻量，但容易漏掉关键残留：

• CMakeFiles/ 目录里存着检测结果（比如 CheckIncludeFile.c 编译产物）、自动生成的头文件、以及 CMake 内部状态，这些不会随 CMakeCache.txt 重建而刷新
• 某些 find_package() 的结果（如 OpenCV_FOUND）可能缓存在 CMakeFiles/ 下的临时构建目录里，不删它，CMake 会跳过重新探测
• 如果之前用过 -G 指定生成器（比如 Unix Makefiles 或 Ninja），CMakeFiles/ 里还包含生成器专用元数据，混用会导致 make 报错或静默失败

安全清理的两种实用方式

推荐按场景选，别凭感觉删单个文件：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

• 日常调试 / 配置变更频繁：直接 rm -rf build/ && cmake -S . -B build。虽然重编译耗时，但能彻底规避缓存污染，尤其在改了 toolchain、升级编译器、或切换 CMAKE_BUILD_TYPE 时必用
• 只想重检环境不重编译：删 build/CMakeCache.txt 后运行 cmake -S . -B build（不是 cmake build）。注意：这仅对纯配置变更有效，若 CMakeLists.txt 里用了 option() 或 set(... CACHE)，仍可能沿用旧值

cmake -S . -B build 为什么比 cmake . 更干净？

这是现代 CMake（3.13+）推荐的“源码-构建分离”模式，好处很实在：

• -S 明确指定源码根目录（.），-B 强制构建目录为 build/，避免当前目录被污染
• 执行后所有生成物（CMakeCache.txt、CMakeFiles/、Makefile）全集中在 build/ 里，删它就等于清空全部缓存 + 构建中间件
• 配合 CI/CD 脚本时，rm -rf build/ 可作为标准清理步骤，无需判断哪些文件该留、哪些该删

容易被忽略的陷阱

真正出问题的往往不是缓存本身，而是缓存和现实脱节：

• 你删了 build/，但 CMakeLists.txt 里写了 set(CMAKE_C_COMPILER "/old/path/gcc" CACHE FILEPATH "") —— 这个硬编码路径会立刻写回新缓存，导致检测失败
• 跨平台开发时，Windows 上生成的 build/ 目录被复制到 Linux 机器上再运行 cmake，CMakeCache.txt 里的 Windows 路径（如 C:/msys64/usr/bin/gcc.exe）会直接让 Linux 构建卡在编译器检测
• find_package(Boost REQUIRED) 成功后，Boost 的头文件路径、库路径全记在缓存里；卸载 Boost 再运行 cmake，它不会报错，而是继续用旧路径链接 —— 直到 make 阶段才爆 undefined reference