cmake找不到包主因是未正确指定config.cmake搜索路径或规则；set(xxx_dir)需指向含*config.cmake的直接父目录且必须在find_package前声明，cmake_prefix_path更适配多库统一管理，config模式优先于module模式。
直接说结论： CMake 找不到包，90% 是因为 find_package 没扫到你装的库的 *Config.cmake 文件——不是路径写错了，而是没告诉它“去哪扫”或“怎么扫”。关键不在“找什么”，而在“在哪找、按什么规则找”。
为什么 set(XXX_DIR ...) 有时不生效？
很多人写了 set(OpenCV_DIR "/path/to/opencv/build") 还是报 Could NOT find OpenCV，原因很实际：
-
OpenCV_DIR必须指向包含OpenCVConfig.cmake（或opencv-config.cmake）的**直接父目录**，不是build/，而是build/lib/cmake/opencv4/或build/install/lib/cmake/opencv4/ - 如果该目录下只有
OpenCVConfig-version.cmake但没对应版本号参数，find_package(OpenCV 4.8 REQUIRED)会失败 -
set()必须放在find_package()之前，且不能被project()之后的 scope 隔离（比如写在子目录CMakeLists.txt里就无效） - 某些包（如
yaml-cpp）用的是小写命名：set(yaml-cpp_DIR ...)，但 CMake 变量名不支持连字符，实际应写成set(yaml_cpp_DIR ...)
NO_DEFAULT_PATH 到底该不该加？
加了 NO_DEFAULT_PATH，CMake 就只查你显式给的路径，跳过系统路径（/usr/lib/cmake、CMAKE_PREFIX_PATH 等）。它不是“保险开关”，而是“精准锁定”手段：
CMake 4.3.2
下载
CMake 4.3.2 Windows x86_64 历史版本安装包，适合旧项目兼容、构建环境回退、CMakeLists.txt 迁移验证、Visual Studio/Ninja/Makefile 生成器测试和 C/C++ 项目维护。
- 适用场景：你明确知道只用某一个构建版本（比如自己编译的 debug 版 libtorch），且要避免和系统里已装的 release 版冲突
- 典型写法：
find_package(Torch 1.13 REQUIRED NO_DEFAULT_PATH)，配合提前设置的set(Torch_DIR ".../libtorch/share/cmake/Torch") - 风险点：一旦
Torch_DIR路径下没有TorchConfig.cmake或文件权限不对，错误信息还是Could NOT find Torch，但不会提示“其实 /usr/lib/cmake/Torch/ 下有旧版”，排查更难 - 不加时，CMake 会按优先级顺序扫所有路径，容易“找到错的版本”——比如
find_package(OpenCV REQUIRED)拿到了系统 apt 装的 4.2，而你工程需要 4.8
用 CMAKE_PREFIX_PATH 替代一堆 *_DIR 更省事？
对，但得理解它怎么“省事”：
-
CMAKE_PREFIX_PATH是根路径列表，CMake 会在每个路径下自动拼接lib/cmake/<name>/</name>、share/cmake/<name>/</name>等子路径去找*Config.cmake - 例如：
cmake -DCMAKE_PREFIX_PATH="/home/user/mydeps;/opt/thirdparty" ..，CMake 就会查：/home/user/mydeps/lib/cmake/protobuf/、/opt/thirdparty/share/cmake/protobuf/等 - 它比逐个设
Protobuf_DIR、glog_DIR、gflags_DIR更干净，尤其适合整套自建依赖树（比如 conan 或 vcpkg 安装后输出的 install dir） - 注意：环境变量
$CMAKE_PREFIX_PATH和 CMake 参数-DCMAKE_PREFIX_PATH=...效果等价，但前者容易被 shell 会话污染；推荐统一用命令行参数传入 - 陷阱：如果某个包的 Config 文件放在
lib64/cmake/xxx/（常见于某些 CentOS 构建），而 CMake 默认不查lib64，这时就得配合PATH_SUFFIXES或改用HINTS
MODULE 模式和 CONFIG 模式到底怎么选？
别纠结“哪个高级”，看包本身提供什么：
- 现代 C++ 库（如
libtorch、OpenCV 4.x、yaml-cpp 0.8+）都自带*Config.cmake，默认走 CONFIG 模式，不用加CONFIG参数 - 老库（如
Boost、Threads、OpenGL）没 Config 文件，CMake 只能靠内置的FindBoost.cmake这类模块，必须走 MODULE 模式；加MODULE参数只是显式声明，不加也会 fallback - 混用风险：
find_package(Boost MODULE REQUIRED)和find_package(OpenCV CONFIG REQUIRED)可以共存，但如果你把FindOpenCV.cmake放进CMAKE_MODULE_PATH，又没删掉系统里的OpenCVConfig.cmake，CMake 可能优先用 Module 模式——结果变量名变成OpenCV_INCLUDE_DIR（单数）而非OpenCV_INCLUDE_DIRS（复数），链接就崩 - 验证方法：运行
cmake -LAH .. | grep -i "open.*config\|boost.*module"，看实际加载的是哪个文件
最常被忽略的其实是路径大小写和文件存在性：CMake 查 OpenCVConfig.cmake，但你放的是 opencvconfig.cmake（全小写）或 OpenCVConfig.cmake.in（带 .in 后缀），它就安静地跳过——不会报错，只会继续往下找，直到超时或放弃。
