target_link_libraries必须写在对应目标（如add_executable/add_library）定义之后，否则报错“target does not exist”；它不支持前向引用，但允许跨目录使用（需通过add_subdirectory加载），且PUBLIC/PRIVATE/INTERFACE是决定依赖是否传递给下游的关键语义开关，非可选风格修饰。
target_link_libraries 必须写在目标定义之后
否则 CMake 直接报错：CMake Error: target "xxx" does not exist。它不支持前向引用，也不做回溯查找。
-
add_executable(myapp main.cpp)和add_library(mylib src.cpp)必须先执行 -
target_link_libraries(myapp PRIVATE mylib)必须紧随其后（或至少在同一作用域内） - 如果目标在子目录中定义，而
target_link_libraries写在父目录，CMake 仍能识别——但前提是该目标已通过add_subdirectory()加载
库名写错是链接失败最常见原因
现代 CMake 中，第三方库几乎都以 imported target 形式提供（比如 OpenCV::opencv_core），而不是裸库名 opencv_core。
- 用
find_package(OpenCV REQUIRED)后，必须写target_link_libraries(myapp PRIVATE OpenCV::opencv_core)，不能漏掉OpenCV::前缀 - 系统库如 pthread、m 可直接写
-pthread或m，但注意：写pthread（无横线）在某些平台会失败 - 自建静态库
libfoo.a，若用add_library(foo STATIC foo.cpp)定义，则链接时写foo；若用全路径/path/to/libfoo.a，则直接传入即可，但会失去依赖自动重建能力
PUBLIC/PRIVATE/INTERFACE 不是可选修饰，而是语义开关
它们决定链接项是否“传染”给下游目标，不是风格偏好，而是构建正确性的关键。
-
PRIVATE：只影响当前目标编译和链接，下游完全感知不到 —— 可执行文件一律用这个 -
PUBLIC：当前目标需要 + 下游目标也需要（比如头文件里用了 Boost 的模板）—— 库作者用这个暴露接口依赖 -
INTERFACE：当前目标自己不链接，但强制下游带上（比如要求 C++17 或定义宏）—— 多用于INTERFACE类型库 - 混用时顺序无关，但重复指定同一 item 的不同作用域会覆盖：例如
target_link_libraries(mylib PUBLIC Boost::system PRIVATE spdlog::spdlog)
链接静态库和动态库的行为差异藏在导入方式里
target_link_libraries 本身不区分 .a 还是 .so，真正起作用的是库如何被声明或导入。
- 用
add_library(mylib STATIC ...)定义的库，链接时自然静态链接 - 用
find_package(XXX)找到的 imported target，行为由其配置决定：默认倾向 shared；想强制 static，得配合find_package(XXX CONFIG COMPONENTS ...)和CMAKE_FIND_LIBRARY_SUFFIXES - 手动写
/usr/lib/libz.a路径，CMake 会按字面链接静态库，但失去跨平台性和版本管理能力
最容易被忽略的是：INTERFACE 库不生成任何二进制，但它传递的链接要求（如 cxx_std_17）会静默影响所有下游编译器参数，出问题时很难定位。
