CMake不是编译器，而是构建配置生成器；报“No CMAKE_C_COMPILER could be found”是因为它找不到可用的C编译器，常见于Linux未装build-essential、Windows未装VS或MinGW且PATH未配置、macOS未运行xcode-select --install。
直接说结论：CMake 不是编译器，也不是构建工具，它是个“构建配置生成器”——你写 CMakeLists.txt，它帮你生成 Makefile、.sln 或 build.ninja，再由这些文件调用真实编译器（如 g++、cl）干活。搞不清这点，后面所有报错都容易误判。
cmake .. 为什么报 “No CMAKE_C_COMPILER could be found”
这不是 CMake 本身的问题，而是它找不到可用的 C 编译器。常见于：
- Linux 上没装
build-essential（Ubuntu/Debian）或gcc+make（CentOS/RHEL）； - Windows 上装了 CMake 却没装 Visual Studio 或 MinGW，或没把编译器路径加进系统
PATH； - macOS 上没运行
xcode-select --install安装命令行工具。
验证方式：终端里直接执行 gcc --version 或 cl（Windows），能输出版本号才算就位。CMake 启动时会扫描环境变量和注册表（Windows）或 /usr/bin（Linux/macOS），找不到就停在这一步，不往后走。
add_executable() 和 add_library() 的 target 名不能重复
每个 add_executable() 或 add_library() 声明的 target 名（第一个参数）必须全局唯一。重复会导致 CMake 配置失败，报错类似：
add_executable() cannot create target "demo" because another target with the same name already exists.
注意：
- target 名和生成的文件名（如
demo可执行文件）默认一致，但可不同——用set_target_properties(<code>demoPROPERTIES OUTPUT_NAME "myapp") 修改输出名； - 头文件（
.hpp）不用列在add_executable()参数里，只列源文件（.cpp）； - 静态库和动态库 target 名可以一样，但必须显式指定类型：
add_library(utils STATIC ...)vsadd_library(utils SHARED ...)。
为什么 build 目录必须是空的或全新创建的
CMake 的缓存机制（CMakeCache.txt）是基于目录存在的。如果复用旧 build 目录，且 CMakeLists.txt 有修改（比如加了 set(CMAKE_CXX_STANDARD 17)），CMake 很可能沿用旧缓存值，导致标准没生效、链接失败、甚至静默跳过某些逻辑。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
安全做法永远是：
-
rm -rf build（Linux/macOS）或rmdir /s build（Windows）； -
mkdir build && cd build； -
cmake ..—— 这步必须重新运行，不能跳过。
尤其当你改了 project() 名、升级了 CMake 版本、或切换构建生成器（比如从 Unix Makefiles 换成 Ninja），旧缓存几乎必然出问题。
target_link_libraries() 的 PRIVATE/PUBLIC/INTERFACE 区别常被忽略
这三者控制头文件搜索路径和链接传递行为，不是可选项，而是影响下游依赖的关键开关：
-
PRIVATE：仅当前 target 用，不透传给依赖它的其他 target； -
PUBLIC：当前 target 用 + 所有依赖它的 target 也能用（头文件路径 + 链接库）； -
INTERFACE：当前 target 不用，只提供给依赖它的 target（典型用于纯头文件库或 compile options）。
例如：add_library(json INTERFACE) 后，必须用 target_include_directories(json INTERFACE include/) + target_link_libraries(app PUBLIC json)，否则下游 app 无法找到 #include "json.hpp"。
漏写或写错作用域，编译时大概率报 fatal error: xxx.h: No such file or directory，但错误位置总显示在下游文件里，排查起来特别绕。
