target_link_libraries中库名应写逻辑名或目标名而非绝对路径；正确做法是用find_package找到目标后传openssl::ssl等，或拆分使用逻辑名加link_directories。
target_link_libraries 里库名写绝对路径还是别名？
Windows 下 target_link_libraries 最容易错在库名写法——直接写 .lib 文件路径（比如 C:/deps/openssl/lib/libssl.lib）看似能编译过，但链接时大概率报 LNK1104: cannot open file 'libssl.lib'。这是因为 MSVC 链接器默认只在标准路径和 link_directories() 指定路径里找库，而你传进来的完整路径会被当成“库名”而非“路径”，链接器反而去拼接默认后缀或找同名导入库失败。
正确做法是拆开：用 target_link_libraries 只传逻辑名（如 ssl），再用 target_link_directories 或 link_directories 告诉链接器去哪找；或者更推荐——用 find_package 找到目标后，直接传目标名（如 OpenSSL::SSL）。
- ✅ 推荐：
find_package(OpenSSL REQUIRED)→target_link_libraries(myapp PRIVATE OpenSSL::SSL OpenSSL::Crypto) - ⚠️ 慎用：
target_link_libraries(myapp PRIVATE "C:/deps/openssl/lib/libssl.lib")（仅限极简测试，不可移植、不支持依赖传递） - ❌ 错误：
target_link_libraries(myapp PRIVATE libssl)（没加路径，链接器找不到）
PRIVATE / PUBLIC / INTERFACE 到底怎么选？
Windows 下 DLL 导出头文件和链接行为高度耦合，选错作用域会导致下游目标编译失败或运行时崩溃。比如你写了 target_link_libraries(myapp PRIVATE zlib)，但 myapp 的头文件里又用了 #include <zlib.h></zlib.h>，下游 target 链接 myapp 时就会报 zlib.h: No such file or directory。
判断依据很简单：下游是否需要看到这个库的头文件、宏定义或链接符号？
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 如果只是内部实现用（比如只在 .cpp 里调
inflate()），用PRIVATE - 如果头文件里有
#include <xxx.h></xxx.h>或用了该库的类型（如std::vector<:filesystem::path></:filesystem::path>），必须用PUBLIC或INTERFACE - Windows 上特别注意：DLL 导出的类若继承自第三方库（如 Qt 的
QObject），父类头文件必须通过PUBLIC透出，否则 MOC 生成代码会失败
静态库 vs 动态库，链接方式一样吗？
不一样。Windows 下静态库（.lib）和动态库（.dll + 对应的 .lib 导入库）虽然都用 .lib 后缀，但链接行为完全不同。CMake 默认按“导入库”处理，即假设你要链接 DLL —— 这没问题；但如果你真想静态链接（比如用 zlibstatic.lib），就必须显式告诉 CMake：
- 确认库是静态版：检查文件名（常见
zlibstatic.lib、libpng_static.lib）、或用dumpbin /headers xxx.lib看是否有LIBRARY字样（动态导入库才有） - 强制静态链接：
set(CMAKE_FIND_LIBRARY_SUFFIXES ".lib;.a" ${CMAKE_FIND_LIBRARY_SUFFIXES})，再配合find_package(ZLIB REQUIRED)和ZLIB_LIBRARY_DEBUG等变量手动指定静态库路径 - 更稳妥：用
vcpkg安装时加--triplet x64-windows-static，它会自动提供ZLIB::ZLIB目标并设好链接方式
找不到库？先看 CMakeCache.txt 里的 LINK_FLAGS
Windows 下很多链接失败不是因为写错 target_link_libraries，而是 CMake 自动加了冲突的链接器标志。比如你用了 find_package(Boost REQUIRED COMPONENTS system)，但 Boost 是用 /MT 编译的，而你的项目用 /MD，链接时就会报一堆 LNK2005 重定义错误。
这时候不要急着改 target_link_libraries，先打开 CMakeCache.txt 搜索 LINK_FLAGS，看有没有隐式加入的 /MD 或 /MT；再检查 Boost_SYSTEM_LIBRARY_DEBUG 这类缓存变量指向的是否真是你想要的版本。
- 关键检查点：
CMAKE_MSVC_RUNTIME_LIBRARY是否统一（推荐设为MultiThreadedDLL） - 临时验证：在
target_link_libraries后加$<cxx></cxx>条件表达式，避免 Fortran 目标误链 C++ 库 - 终极手段：用
message(STATUS "Linking ${TARGET}: ${LINK_LIBRARIES}")打印实际链接项，比猜强
Windows 的链接规则藏得深，target_link_libraries 写对只是第一步，真正卡住的往往是运行时库匹配、DLL 路径、或 CMake 没读到你以为它读到了的 find_package 结果。
