优先用target_compile_options(MyTarget PRIVATE -O2)，因其作用域明确、不污染其他target；全局设置易被覆盖或重置，且需手动Reload CMake Project才能生效。
CLion 里 CMake 配置不是“设完就完”，关键在变量作用域、缓存刷新时机和生成器选择是否匹配实际构建意图——多数卡顿、头文件找不到、参数不生效，都出在这三处。
为什么 CMAKE_CXX_FLAGS 加了 -O2 却没生效？
直接追加到全局 flag 变量（如 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O2")）看似正确，但容易被后续 CMakeLists.txt 中的 target_compile_options() 覆盖，或被工具链预设重置。
- 优先用目标级设置：
target_compile_options(MyTarget PRIVATE -O2)，作用范围明确，不污染其他 target - 若需全局生效，改用
add_compile_options(-O2)（注意：它影响当前目录及子目录所有 target） - 检查是否启用了 CMake 预设（
CMakePresets.json）——预设中的cacheVariables会覆盖CMakeLists.txt里的 set() 调用 - 修改后必须触发重新配置：右键 CMakeLists.txt → Reload CMake Project，不能只靠自动检测
头文件路径总提示 not found？重点看 target_include_directories() 的作用域
用 include_directories() 是旧式写法，CLion 解析时容易丢失 PUBLIC/PRIVATE 边界，导致补全失效或链接失败。
- 必须按依赖关系选作用域：
PUBLIC（本 target + 所有依赖它的 target 都能用）、PRIVATE（仅本 target 内部用）、INTERFACE（只给依赖者用，自己不用） - 路径别硬写
${CMAKE_CURRENT_SOURCE_DIR}/include，改用生成器表达式：$，避免 install 后路径错乱 - 第三方库路径如果来自
find_package()，直接用target_link_libraries(MyTarget PRIVATE SomeLib)，CLion 会自动拉入其INTERFACE_INCLUDE_DIRECTORIES
切换 Ninja 和 Visual Studio 生成器后编译失败？
CLion 默认用 Ninja（快、轻量），但某些 Windows 项目依赖 MSVC 特定行为（如 PCH、ATL），强行切 Ninja 会报 MSVC_RUNTIME_LIBRARY 相关错误。
- 生成器不是纯性能开关，它绑定编译器行为：Ninja + MinGW / Clang；Visual Studio Generator + MSVC
- 切换前先清缓存：File → Reload CMake Project，否则旧缓存变量（如
CMAKE_CXX_COMPILER）可能残留冲突值 - 远程开发时，生成器必须与远程主机工具链匹配——WSL 上选 Ninja，Windows 远程主机上选 Visual Studio Generator（需提前装好对应 VS 版本）
- 检查 CLION_IDE 环境变量是否被误读：某些自定义脚本会根据它跳过某些 configure 步骤，导致生成器未真正加载
最容易被忽略的是 CMake 缓存变量的“惰性更新”：你改了 CMAKE_BUILD_TYPE 或 CMAKE_INSTALL_PREFIX，但 CLion 没触发 full reconfigure，旧值仍留在缓存里。每次调大优化级别、换编译器、加新 target 前，手动点一次 Reload CMake Project，比猜半天为什么不生效更省时间。
