Conan按项目隔离管理二进制包，核心流程为conan install生成CMake配置、conan create打包库、conan upload推送至远程；推荐使用CMakeDeps/CMakeToolchain生成器，需在CMakeLists.txt中include并find_package链接。
Conan 的基本工作流：从声明依赖到链接库
Conan 不是全局安装所有依赖，而是按项目隔离管理二进制包。核心动作是三步：conan install 生成构建配置（如 conanbuildinfo.cmake），conan create 打包自己的库，conan upload 推送到私有或公共远程仓库。
典型 conanfile.txt 声明如下：
[requires] fmt/10.2.1 openssl/3.2.1 [generators] CMakeDeps CMakeToolchain
注意：CMakeDeps 和 CMakeToolchain 是 Conan 2.x 推荐的生成器，替代旧版 cmake_find_package；它们与 CMake 3.23+ 原生兼容，避免 find_package() 查找失败。
- 运行
conan install . --build=missing --settings compiler.cppstd=17会自动下载、构建缺失的二进制（若远程无匹配） - 生成的
build/generators/下文件需在CMakeLists.txt中include()，再用find_package(fmt CONFIG)链接 - Conan 默认按
profile（如default）解析平台、编译器、标准等设置，不同项目可共用同一 profile，也可用--profile:build/--profile:host分离构建机与目标机环境
vcpkg 与 Conan 的关键差异点：二进制复用粒度和 ABI 控制
vcpkg 默认按 triplet（如 x64-windows-static-md）构建，所有依赖强制统一静态/动态、CRT 类型、链接方式；Conan 则允许每个依赖独立指定 shared=True/False、fPIC=True 等选项，并通过 settings（如 compiler.version）和 options 构成唯一二进制 ID。
立即学习“C++免费学习笔记（深入）”；
这意味着：
- vcpkg 的二进制复用更“粗”，一个 triplet 下所有包必须一致；Conan 可混合
zlib/1.2.13动态链接 +boost/1.83.0静态链接，只要 ABI 兼容 - vcpkg 没有原生 profile 概念，跨平台需手动维护多个 triplet 文件；Conan 的
profiles支持继承、条件覆盖（如[settings] os=Linux arch=x86_64 compiler=gcc compiler.version=12） - vcpkg 的
vcpkg.json不支持版本范围（如^1.2.0），Conan 的conanfile.py可用self.requires("fmt/[>=10.0.0 精确约束
Conan 2.x 中容易踩的坑：缓存污染、远程优先级、CMake 集成断裂
Conan 缓存（~/.conan2）不是“干净即安全”。常见问题包括：
- 本地修改过某个依赖的
conanfile.py并conan create后，未清理缓存就切分支，导致旧二进制被复用 —— 应用conan remove "zlib/*" -c清除特定引用 - 多个远程（如
conancenter、私有 Artifactory）存在同名同版本包时，Conan 按conan remote list顺序查找，第一个命中即停；误配顺序会导致拉取错误源码 —— 用conan remote update <name> --force</name>调整优先级 - CMakeLists.txt 中若仍用
find_package(OpenSSL)而非find_package(OpenSSL CONFIG)，且未include(${CMAKE_BINARY_DIR}/conan_toolchain.cmake)，则头文件路径、宏定义、链接库全丢失
何时该选 Conan 而非 vcpkg？看这三点硬指标
如果你的项目需要：
- 跨平台构建中，Windows 使用 MSVC 动态 CRT、Linux 使用 GCC 12 + libstdc++11、macOS 使用 Clang + libc++，且各平台依赖的共享/静态链接策略不一致 → Conan 的 settings/options 组合能力不可替代
- 团队已有内部 Artifactory/Nexus，要求所有二进制审计可追溯、带签名、按 Git Tag 自动触发 CI 构建 → Conan 的
conan upload --recipe --sources和conan lock锁定完整依赖图，vcpkg 无等效机制 - 嵌入式目标（如 aarch64-unknown-elf）需自定义 toolchain + 编译器路径，且依赖必须全部静态链接 → Conan 支持
profile中写死tools.build:compiler_executable=/opt/arm-gcc/bin/gcc，vcpkg triplet 不支持任意路径注入
Conan 的复杂性主要来自其灵活性 —— 它不预设“标准环境”，所有行为都靠显式声明驱动。一旦 profile、lockfile、generator 三者对齐，CI 构建的可重复性远高于 vcpkg。但这也意味着，少写一行 compiler.cppstd=17，就可能在 CI 上触发全套源码编译。
