add_subdirectory必须放在target_link_libraries之前，因其会立即执行子目录CMakeLists.txt并注册目标；若顺序颠倒，父目录将找不到子目录定义的目标而报错。
为什么 add_subdirectory 不能随便写在任意位置
因为 CMake 的执行是线性的，add_subdirectory 会立即进入子目录、读取其 CMakeLists.txt 并执行其中所有指令——包括 project()、set()、add_library() 等。如果它出现在 target_link_libraries() 之后，而子目录里定义了 AlgoLib，主目录却已经试图链接它，就会报错：Target "AlgoLib" not found。
常见错误现象：
- 构建时报
Cannot find target "XXX" in target_link_libraries - 子目录的
add_library像没生效一样 - IDE（如 CLion）中目标不识别、跳转失效
正确做法：
-
add_subdirectory必须放在依赖它的target_link_libraries之前 - 推荐统一放在
project()之后、所有add_executable之前 - 子目录的
CMakeLists.txt不要重复调用cmake_minimum_required或project（除非它是独立子项目）
target_link_libraries 的 PRIVATE/PUBLIC/INTERFACE 到底影响什么
这仨关键字控制头文件路径、编译定义、链接依赖的“传播范围”，不是可有可无的修饰词，直接决定下游能否编译通过。
使用场景：
- 你写了一个静态库
UtilsLib，内部用了fmt，但对外只暴露自己头文件 → 用PRIVATE fmt - 你封装了一个 wrapper 库
NetworkWrapper，把libcurl的头和 API 透出给调用者 → 用PUBLIC libcurl - 你只想让别人包含你的头文件，但不希望他们链接任何东西 → 用
INTERFACE（比如纯头文件库）
容易踩的坑：
- 全写
PRIVATE：下游链接时找不到符号，或#include报错（头文件路径没传下去） - 全写
PUBLIC：下游被强制引入你不希望暴露的依赖（比如你用了OpenCV内部头，不该让调用者感知） - 混淆
INTERFACE和PUBLIC：前者不参与链接，后者既传头又传链接项
为什么 find_package(OpenCV) 找不到，但 pkg_check_modules 可以
find_package 默认只查系统路径（/usr/lib/cmake/opencv4、CMAKE_PREFIX_PATH），而 pkg_check_modules 走的是 pkg-config 路径（/usr/lib/pkgconfig），两者机制完全不同。
性能与兼容性影响：
-
find_package更现代、支持导入 targets（如OpenCV::opencv_core），但要求 OpenCV 安装时生成了 CMake config 文件 -
pkg_check_modules兼容性更好（尤其老版本 OpenCV），但只返回变量（OpenCV_INCLUDE_DIRS），没法用 target 风格链接 - 若 OpenCV 是源码编译安装且没加
-DOPENCV_GENERATE_PKGCONFIG=ON，pkg_check_modules也会失败
实操建议：
- 优先用
find_package(OpenCV REQUIRED)，失败后检查OpenCV_DIR是否指向build/install/lib/cmake/opencv4 - 若用
pkg_check_modules，记得手动include_directories(${OpenCV_INCLUDE_DIRS})和target_link_libraries(... ${OpenCV_LIBRARIES}) - 跨平台项目慎用
pkg_check_modules，Windows 下pkg-config不是默认组件
FetchContent_Declare 和 ExternalProject_Add 选哪个
核心区别在于：前者在 configure 阶段就拉取并构建依赖（同步），后者在 build 阶段才触发（异步）。这不是“哪个更好”，而是“谁更适合当前构建节奏”。
关键判断点：
- 你要集成的是 header-only 库（如
spdlog、range-v3）→ 用FetchContent，轻量、可缓存、支持set_target_properties - 你要集成的是带复杂构建流程的项目（如
protobuf、ffmpeg），且不想阻塞 configure → 用ExternalProject_Add，但它生成的目标不能直接用target_link_libraries，得靠add_dependencies+ 自定义IMPORTEDtarget - CI 构建时间敏感 →
FetchContent可利用CMAKE_BINARY_DIR缓存，ExternalProject每次都重拉重编
容易被忽略的地方：
-
FetchContent的BINARY_DIR默认在${CMAKE_BINARY_DIR}/_deps，别把它加进 git；但若想调试，可以设UPDATE_COMMAND ""冻结版本 -
ExternalProject_Add的INSTALL_COMMAND ""很重要，否则它可能试图 install 到系统路径，引发权限问题 - 二者都不能替代 proper package manager（如 vcpkg），仅适合轻量级、可控的第三方依赖
