find_package用PATHS参数时需指定Config.cmake所在父目录而非安装根目录，且应加NO_DEFAULT_PATH；无Config时可用CMAKE_MODULE_PATH自定义FindXXX.cmake；优先级最高的是XXX_DIR环境变量；file(GLOB)易引发链接顺序与静态库冲突问题。
find_package 用 PATHS 参数指定目录时，路径必须精确到 Config.cmake 所在父目录
很多人以为 PATHS 后面填库的安装根目录（比如 /opt/gflags）就能找到，结果报错 Could not find a configuration file for package "GFlags"。这是因为 CMake 在 PATHS 下只搜索 */lib/cmake/GFlags/ 或 */share/gflags/cmake/ 这类子路径里的 GFlagsConfig.cmake 或 gflags-config.cmake，而不是直接在你给的路径下找。
正确写法是把路径指向 Config 文件实际所在的父级目录：
find_package(GFlags REQUIRED PATHS /workspace/xxx/gflags-2.2.2/out/lib/cmake/gflags NO_DEFAULT_PATH)find_package(Eigen3 3.4 REQUIRED PATHS /home/neo/3rdparty/eigen340/share/eigen3/cmake)- 如果 Config 文件在
/usr/local/lib64/cmake/xxhash/xxHashConfig.cmake，那PATHS应填/usr/local/lib64/cmake/xxhash，不是/usr/local
漏掉 NO_DEFAULT_PATH 会导致 CMake 仍去系统路径（如 /usr/lib/cmake）里找，可能误匹配旧版本。
找不到 FindXXX.cmake 时，靠 CMAKE_MODULE_PATH + 自定义模块文件最可控
当你要用的库没有官方 FindXXX.cmake（比如 xxHash、jsoncpp），又不想用 file(GLOB ...) 这种易出错的方式，就该自己写一个，并通过 CMAKE_MODULE_PATH 注入。
步骤很简单：
- 新建
cmake/FindxxHash.cmake，内容按标准模板：用find_path找头文件、find_library找库、find_package_handle_standard_args做校验 - 在
CMakeLists.txt开头加：set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake" ${CMAKE_MODULE_PATH}) - 之后就可以直接写
find_package(xxHash REQUIRED)，CMake 会优先从你的cmake/目录加载
注意：CMAKE_MODULE_PATH 必须在 find_package 之前设置；路径是相对于 CMAKE_SOURCE_DIR 的，别写绝对路径。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
用环境变量 XXX_DIR 比 PATHS 更优先，适合 CI 或多版本切换
如果你在 CI 脚本或开发机上要频繁切换 gflags/glog 版本，硬编码 PATHS 很麻烦。XXX_DIR 环境变量才是 CMake 内置的“第一优先级”查找入口 —— 它比 PATHS 和 CMAKE_MODULE_PATH 都早生效。
例如：
- 终端执行：
export GFLAGS_DIR=/workspace/gflags-2.2.2/out - 然后运行
cmake ..，CMake 会自动在$GFLAGS_DIR/lib/cmake/gflags/下找GFlagsConfig.cmake - 对应库名是
GFlags，变量名就是GFLAGS_DIR（全大写 + 下划线 + “DIR”后缀），大小写和拼写必须严格匹配
这个机制不依赖 CMakeLists 修改，适合构建脚本统一管控，但要注意它对大小写敏感，gflags_dir 或 GFlags_DIR 都无效。
file(GLOB ...) 是临时方案，链接顺序和静态库重复问题很难绕开
当你面对一个没提供 Config 或 Find 模块的老旧库（比如自己编译的 OpenSSL 1.1.1v），file(GLOB openssl_libs ${openssl_root}/lib*/*.so) 看似简单，但实际埋了几个坑：
-
GLOB不会自动按依赖顺序排序，如果库之间有依赖（如libssl.so依赖libcrypto.so），链接时顺序错就会报 undefined reference - 静态库（
.a）可能混入多个版本（libjsoncpp.a和libjsoncpp_static.a），GLOB全抓进来，target_link_libraries会随机选一个，导致符号冲突 -
GLOB结果是 list 类型，不能直接传给target_link_libraries，得用${openssl_libs}展开，且需确保路径中不含空格
真正稳定的做法还是老老实实写 FindXXX.cmake，哪怕只做最简版：明确指定 find_library(OPENSSL_SSL_LIBRARY NAMES ssl PATHS ${openssl_root}/lib)，把每个库单独定位。
