优先用target_include_directories而非include_directories，因其支持private/public/interface作用域控制，避免全局污染、头文件泄露和路径冲突；路径应使用${project_source_dir}等相对路径，第三方库应通过find_package+target_link_libraries自动注入头路径。
直接结论：优先用 target_include_directories，而不是 include_directories；路径写相对 ${PROJECT_SOURCE_DIR} 或 ${CMAKE_CURRENT_SOURCE_DIR}，别用绝对路径。
为什么 include_directories 容易出问题
它会让所有 target（包括后续 add_executable/add_library）都继承该头文件路径，缺乏作用域控制。一旦项目变大、有多个库相互依赖，就容易出现：头文件泄露（不该被下游看到的头被暴露）、路径冲突（不同子目录下同名头文件被错选）、Clion 索引不准（报红但实际能编译通过）。
- 它只在当前
CMakeLists.txt作用域内生效，跨子目录需重复写 - 不区分
PUBLIC/PRIVATE/INTERFACE，无法表达“哪些头该被使用者看到” - 和现代 CMake 的目标导向理念脱节，Clion 2023.2+ 对它的语义理解有限
target_include_directories 怎么写才安全
这是官方推荐方式，为具体 target 显式声明头文件可见性。关键在于三个作用域关键字：
-
PRIVATE：仅该 target 的源文件（.cpp）能用，头不传递给依赖者 -
PUBLIC：该 target 的源文件 + 所有链接它的 target 都能用（适合库的公开头） -
INTERFACE：该 target 自己不用，但链接它的 target 必须能用（适合纯头文件库、配置宏头）
示例：
add_library(mylib src/mylib.cpp)
target_include_directories(mylib
PUBLIC ${PROJECT_SOURCE_DIR}/include
PRIVATE ${PROJECT_SOURCE_DIR}/src/internal
)
这样，mylib 的用户只需 #include <mylib.h></mylib.h>，且不会意外 include 到 internal/ 下的私有头。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
第三方库头文件路径怎么处理
不要手动拼 ${OpenCV_INCLUDE_DIRS} 或硬写 include_directories。现代包（OpenCV ≥ 4.5、Boost ≥ 1.70、fmt、spdlog）都提供导入目标（imported targets）：
- 先
find_package(OpenCV REQUIRED) - 再
target_link_libraries(myapp PRIVATE OpenCV::opencv_core)
此时头文件路径、编译定义、链接库全部自动注入，target_include_directories 一行都不用加。如果 message(${OpenCV_INCLUDE_DIRS}) 输出为空，说明它走的是导入目标路线——这反而是好事。
Clion 报红但编译成功？重载 CMake 项目
Clion 的代码索引完全依赖 CMake 解析结果。常见表现：#include "utils.h" 下划红线，但 cmake --build . 没问题。根本原因不是路径错，而是 IDE 没读到最新配置：
- 改完
CMakeLists.txt后，点右上角 Reload project（或Ctrl+Shift+O） - 确认 Clion 底部状态栏显示 “CMake project loaded” 而非 “Loading…”
- 如果仍报红，删掉
cmake-build-*目录后重新 reload
这个步骤比调路径更常被忽略——很多所谓“路径配不对”的问题，其实只是没 reload。
