90%的target_link_libraries报错源于目标未定义、顺序错误、名称拼写错误或裸库名路径未配置；需确保add_executable/add_library在前、名称大小写一致、子目录用add_subdirectory引入、find_package后使用双冒号导入目标。
CMakeLists.txt 里写错位置，库就根本链不上——不是报错，而是静默失败。
target_link_libraries 必须放在 add_executable 之后
这是最常踩的坑：把 target_link_libraries 写在 add_executable 前面，CMake 不会报错，但链接器完全看不到你要链接的目标，最终编译通过、运行时崩溃（符号未定义）或直接找不到入口。
-
add_executable定义了目标名（比如MyApp），后续所有target_*指令都必须作用于这个已存在的目标 -
target_link_libraries(MyApp PRIVATE lib_acl_cpp.a)中的MyApp必须是前面add_executable(MyApp main.cpp)里声明过的 - 如果用
link_directories，它只影响后续出现的target_link_libraries，且不推荐——路径模糊、易冲突
静态库路径和名字怎么写才对
Linux/macOS 下静态库是 .a，Windows 下是 .lib；CMake 不接受带扩展名的完整文件名，也不接受相对路径里的 ./ 前缀。
- 错误写法：
target_link_libraries(MyApp ./lib/lib_acl_cpp.a)→ 找不到 - 正确写法：
target_link_libraries(MyApp PRIVATE acl_cpp)，前提是lib_acl_cpp.a在link_directories指定的目录里，且 CMake 能自动补上前缀lib和后缀 - 更稳妥写法（尤其跨平台）：
find_library(ACL_CPP_LIB NAMES acl_cpp PATHS ${CMAKE_CURRENT_SOURCE_DIR}/lib)，再target_link_libraries(MyApp PRIVATE ${ACL_CPP_LIB}) - 注意：
lib_acl_cpp.a对应的逻辑名是acl_cpp，不是lib_acl_cpp或acl_cpp.a
头文件路径别只用 include_directories
include_directories 是全局生效的，会导致所有 target 都能看到你的第三方头文件，破坏封装性，还可能引发命名冲突。
- 推荐用
target_include_directories(MyApp PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include) -
PUBLIC表示：本 target 编译需要它，且依赖本 target 的其他 target 也能用到这些头文件 -
PRIVATE表示：仅本 target 内部使用，不透出 - 如果第三方库头文件在
./third_party/acl-redis/include，就写${CMAKE_CURRENT_SOURCE_DIR}/third_party/acl-redis/include，不要用./include这种模糊路径
Windows 下 MinGW 和 MSVC 的库不能混用
你在 GitHub 下载的 lib_acl_cpp.a 很可能是用 GCC 编译的，而 CLion 默认 Windows 工具链如果是 MSVC，就会链接失败——函数名修饰（name mangling）、运行时（CRT）都不兼容。
- 检查当前工具链：Settings → Build → Toolchains → 右上角显示的是 MinGW、MSVC 还是 Clang-cl
- MinGW 项目必须用 GCC 编译的
.a库；MSVC 项目必须用.lib（导入库）或.dll - CLion 捆绑的是 MinGW-w64 13.1，默认支持 POSIX 线程和 SEH 异常，如果你用的第三方库要求
sjlj异常模型，就得手动换 MinGW 安装 - 不确定库来源时，用
file lib_acl_cpp.a（Linux/macOS）或dumpbin /headers lib_acl_cpp.lib（Windows）看编译器标识
真正麻烦的从来不是“怎么加”，而是“加完为什么没用”——绝大多数问题出在目标名不匹配、库名推导错误、或工具链与库二进制格式不一致。动手前先确认这三件事，比反复改 CMakeLists.txt 有效得多。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
