target_link_libraries链接失败的根本原因是调用位置错误或目标名拼写不一致，必须在add_executable/add_library之后使用，且需注意大小写、下划线；链接方式分PRIVATE/INTERFACE/PUBLIC，影响头文件可见性与依赖传递；系统库须通过find_package获取，不可硬编码；链接顺序需按依赖关系反向指定，否则引发undefined reference。
target_link_libraries 为什么链接失败？
根本原因通常是 target_link_libraries 调用位置不对，或者目标名拼错。它必须在 add_executable 或 add_library 创建目标之后才能使用；否则 CMake 会报错 Cannot specify link libraries for target "xxx" which is not built by this project。
- 确保目标（比如
my_app）已通过add_executable(my_app main.cpp)定义完毕 - 检查目标名大小写和下划线是否完全一致——CMake 区分大小写，
MyApp和myapp是两个不同目标 - 如果链接的是自定义库（如
mylib），确认该库已在当前或上级CMakeLists.txt中通过add_library(mylib ...)声明
target_link_libraries 的三种链接方式怎么选？
参数顺序和关键字决定链接行为：链接接口、私有依赖、还是传递性依赖，直接影响下游能否访问头文件或链接该库。
-
target_link_libraries(my_app PRIVATE mylib)：仅my_app内部可用mylib的实现，不导出其头文件或依赖 -
target_link_libraries(my_app INTERFACE mylib)：my_app不链接mylib，但把mylib的头文件路径和链接信息“转发”给依赖my_app的其他目标 -
target_link_libraries(my_app PUBLIC mylib)：既链接mylib，又将它的头文件路径和链接信息传递给依赖my_app的目标——适合封装了第三方库的中间库
误用 PUBLIC 可能导致下游重复链接或头文件冲突；只用 PRIVATE 却让调用方 include 不到头文件，也是常见卡点。
链接系统库（如 pthread、m）要注意什么？
系统库不能直接写名字，必须用 find_package 或 find_library 获取完整路径，否则跨平台构建会失败。
- Linux 下写
target_link_libraries(my_app PRIVATE pthread)看似可行，但在 macOS 上会报library "pthread" not found - 正确做法是：
find_package(Threads REQUIRED)，然后target_link_libraries(my_app PRIVATE Threads::Threads) - 数学库同理：
find_package(OpenMP REQUIRED)→target_link_libraries(my_app PRIVATE OpenMP::OpenMP_CXX)，而不是硬写m
链接顺序影响链接结果吗？
影响，而且很隐蔽。CMake 本身不保证链接器命令行顺序，但底层链接器（尤其是 GNU ld）要求被依赖的库放在依赖它的库之后。
- 写成
target_link_libraries(my_app PRIVATE A B)，若A依赖B，实际链接时可能因顺序颠倒导致 undefined reference - 解决方法：拆成多行，按依赖链反向书写：
target_link_libraries(my_app PRIVATE B)，再target_link_libraries(my_app PRIVATE A) - 更稳妥的做法是用
INTERFACE或PUBLIC让 CMake 自动推导顺序，而非手动拼凑
真正麻烦的不是语法，而是链接时悄无声息的符号缺失——得翻 make VERBOSE=1 输出看最终链接命令才行。
