Conan通过CMakeToolchain和CMakeDeps自动生成权威路径配置，取代手动硬编码include_directories()和link_directories()；CMakeToolchain统一编译器与ABI设置，CMakeDeps生成包级Config.cmake文件供find_package()精准定位跨平台依赖，确保构建可复现、profile与CMake构建类型严格对齐。
Conan 用 CMakeToolchain + CMakeDeps 自动生成路径配置
Conan 不是靠改 CMakeLists.txt 里一堆 include_directories() 或 link_directories() 来“替代”手写路径，而是让 CMake 自己从 Conan 的生成器里读取权威路径。核心是两步：生成 CMakeToolchain（告诉 CMake “我用什么编译器、什么 sysroot、什么 ABI”），再生成 CMakeDeps（告诉 CMake “openssl 头在哪儿、lib 在哪儿、依赖关系怎么连”）。
这两者合起来，就替掉了你原来手动维护的：set(OPENSSL_INCLUDE_DIR ...)、find_library(SSL_LIB ssl PATHS ...)、target_include_directories(myapp PRIVATE ${OPENSSL_INCLUDE_DIR}) 这类易错、难复现的硬编码。
-
CMakeToolchain输出conan_toolchain.cmake，它覆盖CMAKE_SYSROOT、CMAKE_CXX_STANDARD、交叉前缀等——这些你原来得在 CMake 命令行或set()里反复对齐 -
CMakeDeps输出conan_deps.cmake和按包名分的openssl-config.cmake等，供find_package(OpenSSL REQUIRED)正常工作 - 必须在
cmake .. -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake中显式传入 toolchain，否则 CMake 不知道该信谁
为什么不能只用 find_package() 而不配 Conan 生成器
因为系统或本地安装的 find_package(OpenSSL) 找到的，大概率是 x86_64 Linux 主机上的 OpenSSL，不是你目标板子（比如 armv8 + musl）需要的那套 ABI 和链接行为。Conan 的 CMakeDeps 生成的 OpenSSLConfig.cmake 里写的全是交叉编译后的实际路径，比如：
set(OpenSSL_INCLUDE_DIRS "/home/user/.conan2/p/openss.../include") set(OpenSSL_LIBRARIES "/home/user/.conan2/p/openss.../lib/libssl.a")
而原生 find_package 查的是 /usr/include/openssl 和 /usr/lib/x86_64-linux-gnu/libssl.so——两者根本不在一个世界里。
- 如果你跳过
CMakeDeps，直接在 CMake 里写find_package(OpenSSL)，CMake 会去系统路径找，结果链接失败或运行时 segfault - 如果你只用
conan install . --generator cmake_find_package（Conan 1.x 风格），它生成的conanbuildinfo.cmake已被 Conan 2.x 废弃，且不支持 profile 切换和现代 CMake 的 target_link_libraries() 语义 - 正确姿势是：CMakeLists.txt 里只写
find_package(OpenSSL REQUIRED)，其余全交给CMakeDeps生成的 config 文件
imports 不是路径替代方案，而是临时兜底手段
imports 段（如 include, * -> ./deps/include）看起来像在“复制路径”，但它只是把 Conan 缓存里的文件硬拷到项目目录，属于反模式——它绕过了 CMake 的依赖解析，也破坏了 profile 隔离。一旦你换 profile（比如从 arm64-release 切到 arm64-debug），./deps 里的文件不会自动更新，下次 conan install 也不会提醒你。
- 仅适用于极简原型或 CI 中无法挂载 Conan 缓存的隔离环境（比如某些 Docker 构建阶段）
- 拷完仍需手动在 CMake 中加
include_directories(deps/include)和link_directories(deps/lib)，又回到了手写路径的老路 - 真实项目中，应禁用
imports，坚持用CMakeDeps+find_package()流程
容易忽略的关键点：profile 必须与 CMake 构建类型对齐
很多人跑通了 conan install，CMake 却报 “Could not find OpenSSL”，根本原因不是路径没生成，而是 build_type 不一致。例如你在 profile 里写了 build_type=Release，但执行 cmake .. -DCMAKE_BUILD_TYPE=Debug，CMake 就会去找 Debug 版 OpenSSL —— 而 Conan 只装了 Release 版，自然找不到。
- 单配置构建（Ninja / Makefiles）：profile 中
build_type必须和 CMake 的-DCMAKE_BUILD_TYPE=xxx完全一致 - 多配置构建（MSVC）：要用
--config Debug配合conan install --build=missing -pr:h profile-debug，否则 Debug/Release 二进制混用 - 最稳妥做法：profile 文件里固定
build_type，CMake 命令中不传-DCMAKE_BUILD_TYPE，完全由 Conan 控制
路径本身不是问题，上下文错位才是。Conan 替代的从来不是字符串，而是人脑里那张“这个头文件该从哪来、那个库该链哪个 ABI”的模糊地图。
