CMake报“No CMAKE_CXX_COMPILER could be found”是因为未找到C++编译器，需先安装g++或clang++，再清除build目录缓存并重新配置，或显式指定-DCMAKE_CXX_COMPILER路径。
CMake 不是构建工具，而是生成构建文件的元构建系统——你直接运行 make 或 ninja 才真正编译代码；CMake 本身从不编译、链接、运行任何东西。
为什么 CMakeLists.txt 放在项目根目录却报 “No CMAKE_CXX_COMPILER could be found”
这是新手最常卡住的第一步：CMake 没找到可用的编译器。它不会自动继承 shell 中的 CC/CXX 环境变量（除非显式启用），也不读取系统 PATH 下所有 g++ 或 clang++。
- 先确认编译器已安装：
g++ --version或clang++ --version - 首次配置时，显式指定编译器：
cmake -S . -B build -DCMAKE_CXX_COMPILER=g++-12（Linux/macOS）或cmake -S . -B build -T "host=x64" -A x64（Windows + VS 工具链） - 如果用 VS Code 的 CMake Tools 插件，它会尝试自动探测，但首次仍建议手动选 Kit——选错 Kit（比如选了“Clang for Windows”却没装 LLVM）就会静默失败
- 注意：一旦
build/目录生成过缓存（CMakeCache.txt），再换编译器必须删掉整个build/重来，否则 CMake 会复用旧配置并报奇怪错误
add_executable() 报 “target name already exists” 怎么办
这个错误不是因为文件重名，而是你在同一个 CMakeLists.txt 或 include() 进来的子文件里，重复调用了 add_executable(myapp ...) ——CMake 的 target 名全局唯一，且不区分大小写（MyApp 和 myapp 冲突）。
- 检查是否误把
add_executable()写在foreach()循环里，导致多次定义同名 target - 检查是否在子目录的
CMakeLists.txt中用add_subdirectory()引入了同一目录两次（比如add_subdirectory(src)和add_subdirectory(./src)） - 想为同一源码生成多个可执行文件？用不同名字：
add_executable(myapp_debug ...)和add_executable(myapp_release ...)，别共用一个 target 名 - 临时调试可加
message(STATUS "Defining target: myapp")在add_executable()前，看它被触发几次
如何让 find_package(OpenCV) 成功而不是 “Could not find OpenCV”
find_package() 不是联网下载，它只在固定路径搜 OpenCVConfig.cmake 或 opencv-config.cmake。找不到=路径不对，不是 OpenCV 没装。
- 先确认 OpenCV 是否已编译安装（不是只解压源码）：
pkg-config --modversion opencv4（Linux/macOS）或检查C:\opencv\build\install\（Windows） - 告诉 CMake 去哪找：
cmake -S . -B build -DOpenCV_DIR=/usr/local/share/opencv4（Linux/macOS）或-DOpenCV_DIR="C:/opencv/build/install/x64/vc17/lib"（Windows + VS2022） - 若用 vcpkg：确保已运行
vcpkg integrate install，并在 CMake 配置时加-DCMAKE_TOOLCHAIN_FILE=[vcpkg-root]/scripts/buildsystems/vcpkg.cmake - 别在
find_package()后直接用${OpenCV_LIBS}——正确写法是target_link_libraries(myapp PRIVATE ${OpenCV_LIBS})，且要确保find_package()成功返回（加REQUIRED或检查OpenCV_FOUND）
target_include_directories() 的 PUBLIC/PRIVATE/INTERFACE 到底影响什么
这三者决定头文件路径如何向依赖者“传染”。写错会导致编译时找不到头文件，或头文件污染（不该暴露的路径被下游误用）。
-
PRIVATE：只本 target 编译时用，不传给链接它的其他 target（适合实现细节头文件） -
PUBLIC：本 target 编译要用，且所有链接它的 target 也自动获得该路径（适合库的 public 头文件） -
INTERFACE：本 target 自己不用，但所有链接它的 target 必须用（适合纯头文件库，如fmt） - 常见错误：对第三方库用
PUBLIC导致下游项目意外包含其内部头文件（比如opencv2/flann/...），应优先用PRIVATE或INTERFACE，仅对真正需要导出的头文件用PUBLIC - 验证方法：生成 Ninja 构建文件后，查
build/CMakeFiles/myapp.dir/flags.make，看CXX_INCLUDES是否含预期路径
最容易被忽略的是：CMake 缓存机制会让错误配置“看起来生效”，实际却没更新——每次改完 CMakeLists.txt，只要涉及 find_package、编译器、toolchain 或 target 属性，就该清空 build/ 重来。信缓存，不如信 rm -rf build/ && cmake -S . -B build。
