c_cpp_properties.json 的 includePath 手动配置易与 CMake 实际路径不一致，应启用 CMAKE_EXPORT_COMPILE_COMMANDS 并用 CMake Tools 生成 compile_commands.json，再配置 C_Cpp > Configuration Provider 为 cmake-tools。
为什么 c_cpp_properties.json 里 includePath 配了却还报找不到头文件？
VSCode 的 C/C++ 插件（CPT）不读 CMake 的实际构建配置，它只认自己那套 c_cpp_properties.json。你手动写的 includePath 很可能和 CMake 实际生成的路径不一致，尤其在使用 find_package() 或第三方库（如 fmt、OpenCV）时，头文件位置由 CMake 在 configure 阶段动态确定。
正确做法是让 CMake 帮你生成标准的 compile_commands.json，再让 CPT 自动读取：
- 确保
CMakeLists.txt中启用了set(CMAKE_EXPORT_COMPILE_COMMANDS ON)（推荐放在project()后面） - 运行一次
cmake --build build或用 VSCode 的 CMake Tools 插件点击 “Build” —— 这会生成build/compile_commands.json - 在 VSCode 设置中打开
C_Cpp > Configuration Provider，选ms-vscode.cmake-tools（不是默认的Default） - 重启窗口或点击命令面板执行
C/C++: Reset IntelliSense Database
用 CMake Tools 插件时，buildDirectory 和 sourceDirectory 怎么设才不踩坑？
这两个配置直接决定 CMake 命令执行位置和缓存读写路径。设错会导致重复 configure、找不到 CMakeLists.txt、甚至污染源码目录。
典型错误：把 buildDirectory 设成 ${workspaceFolder}/build，但没配 sourceDirectory，结果插件在 build/ 下找 CMakeLists.txt，当然失败。
立即学习“C++免费学习笔记（深入）”；
-
sourceDirectory必须指向含CMakeLists.txt的目录，比如${workspaceFolder}或${workspaceFolder}/src -
buildDirectory推荐用绝对路径变量，例如${workspaceFolder}/build/${buildType}-${platform}，避免多配置冲突 - Windows 上注意路径分隔符：VSCode 内部统一用
/，别写\，否则 CMake Tools 可能解析失败 - 如果项目有多个
CMakeLists.txt（如子模块），必须在设置里指定cmake.configureSettings中的CMAKE_SOURCE_DIR，否则插件会乱猜
跨平台编译时，toolchain file 和 kit 到底谁管什么？
kit 是 CMake Tools 里的“工具链抽象”，它描述“用哪套编译器+环境”，而 toolchain file 是 CMake 原生命令行参数 -DCMAKE_TOOLCHAIN_FILE=...，用于交叉编译（如编译 ARM Linux 或 Android）。两者不等价，也不能互相替代。
常见混淆：以为选了个 ARM GCC 10.2.1 的 kit 就能自动交叉编译 —— 实际上 kit 只负责调用本地 arm-linux-gnueabihf-gcc，但 CMake 仍按 host 系统生成构建逻辑，缺少 toolchain file 会导致 find_package 找 host 库、target_compile_options 不生效等问题。
- 交叉编译必配
toolchain file：在settings.json中加"cmake.configureArgs": ["-DCMAKE_TOOLCHAIN_FILE=/path/to/arm-toolchain.cmake"] - kit 仅需匹配 toolchain file 里指定的编译器路径（比如
CC指向/opt/gcc-arm/bin/arm-linux-gnueabihf-gcc） - macOS 编译 iOS？toolchain file 必须含
set(CMAKE_SYSTEM_NAME iOS)和set(CMAKE_OSX_ARCHITECTURES "arm64")，kit 选 Xcode 或 clang 即可
cmake.buildArgs 和 cmake.configureArgs 改哪个才生效？
configure 阶段决定构建系统怎么生成（Makefile/Ninja/Visual Studio），build 阶段只是执行已生成的构建命令。绝大多数跨平台适配逻辑（如架构、标准库、链接选项）必须在 configure 阶段传入，build 阶段改参数基本无效。
典型误操作：在 cmake.buildArgs 里加 -j8 没问题，但加 -DENABLE_CUDA=ON 就完全不生效 —— 因为 CMake 已经 configure 完了，ENABLE_CUDA 变量根本没被读取。
-
cmake.configureArgs：放所有-Dxxx=yyy、-G（生成器）、-DCMAKE_TOOLCHAIN_FILE、-DCMAKE_BUILD_TYPE -
cmake.buildArgs：只放构建器特有参数，如Ninja的-j8、Make的-l4、Visual Studio的/p:Configuration=Release - 修改
configureArgs后，必须触发重新 configure（右键命令面板 → “CMake: Configure”），不能只点 “Build”
最常被忽略的是 configure 缓存残留：改了 toolchain file 或 configureArgs 后没删 build/CMakeCache.txt，CMake 会复用旧值，导致行为和预期完全不符。
