Conan路径配置核心是确保--output-folder与CMake构建目录一致，并通过Profile和CMakeToolchain保证生成与消费路径匹配；必须用find_package而非硬编码路径，且Profile的settings须真实匹配目标平台。
Conan 本身不处理路径差异，它把路径交给生成器（Generator）和构建系统去解决；真正要动手的地方是选对生成器、配好 Profile、并在 CMake 中正确 include 工具链——路径问题本质是「谁生成路径、谁消费路径、谁保证一致」的问题。
conan install 时必须指定 --output-folder 且与 CMake 构建目录对齐
Conan 不会自动把生成的 CMakeToolchain.cmake 或 xxx-config.cmake 放进你期望的位置，它只按 --output-folder 写入。如果 CMake 找不到这些文件，就会报 find_package(fmt CONFIG REQUIRED) called with no module or config file。
-
--output-folder必须是 CMake 的构建目录（如build/），不能是源码目录或任意临时路径 - 执行顺序必须是：
conan install .. --output-folder=build --build=missing→cmake -B build -S .，否则 CMake 读不到 Conan 生成的文件 - 如果用 Ninja/Meson 等其他构建系统，
--output-folder同样要指向其构建根目录，且生成器需匹配（如NinjaDeps而非CMakeDeps）
CMakeToolchain 生成的路径是相对的，但依赖 Profile 的 settings 是否真实匹配目标平台
Conan 生成的 conan_toolchain.cmake 里写的 CMAKE_SYSROOT、CMAKE_FIND_ROOT_PATH 等路径，全靠 Profile 里的 [settings] 和 [conf] 驱动。一旦 Profile 里写的是 arch=x86_64，但实际在 ARM64 板子上运行，CMake 就会去找 x86_64 的 sysroot，路径自然错位。
- Profile 文件中
sysroot必须是绝对路径，且该路径下要有真实的usr/include和usr/lib - 交叉编译时，
compiler.cppstd、compiler.libcxx必须和目标 toolchain 一致，否则find_path可能跳过正确头文件目录 - Windows 上若用 MSVC，
compiler.runtime（如dynamic）会影响库名后缀，进而影响find_library查找逻辑
CMakeLists.txt 中不能硬编码头文件或库路径，必须用 find_package + target_link_libraries
手动写 include_directories(/home/user/.conan2/p/b/openssl-abc123/include) 是反模式：路径随 Conan 缓存位置、包 ID、版本变化而变，跨机器即失效。
- 必须用
find_package(openssl CONFIG REQUIRED)，靠 Conan 生成的openssl-config.cmake提供真实路径 -
target_link_libraries(myapp PRIVATE openssl::ssl openssl::crypto)，而不是target_link_libraries(myapp PRIVATE /path/to/libssl.a) - 若遇到
Could not find a package configuration file provided by "xxx"，先检查build/generators/下是否存在对应xxx-config.cmake，再确认CMAKE_PREFIX_PATH是否包含该路径
最常被忽略的一点：Conan 生成的路径变量（比如 ${openssl_PACKAGE_FOLDER}）只在 CMake 配置阶段可用，运行时不会注入到可执行文件中；证书路径、插件路径这类运行时路径，得靠 set_property(TARGET xxx PROPERTY INTERFACE_COMPILE_DEFINITIONS ...) 或 configure_file() 显式传入，不能指望 Conan 自动接管。
