必须启用远程二进制仓库并统一 profile，才能减少团队重复编译；需共用私有远程、校验提交标准 profile、ci 固定构建上传、锁文件纳入版本控制、严格区分交叉编译配置。

Conan 本身不编译代码，但它能大幅减少团队重复编译——关键在于让二进制包“一次构建、随处复用”，避免每个成员都从源码重走一遍 configure → build → package 流程。

为什么本地缓存默认不解决团队重复编译

每个开发者本地的 .conan/cache 是隔离的。即使 A 编译好了 openssl/3.2.1 在 x86_64 + GCC 12 + Release 下的二进制，B 的机器上依然是空的，除非显式共享。

• Conan 默认只缓存下载的二进制（来自远程），不自动上传本地构建产物
• conan create 生成的包只存在本地缓存，不会推送到远程，除非你加 --build=missing 并配合 conan upload
• Profile 配置不一致（比如 A 用 compiler.version=12，B 写成 12.3）会导致 Conan 认为这是两个不同二进制，拒绝复用

必须启用远程二进制仓库并统一 profile

团队共用一个私有远程（如 Artifactory、Nexus 或 Conan Server），是减少重复编译的前提。所有 conan upload 上去的包，其他人才能 conan install 直接下载二进制。

Conan 2.31.2

Conan 2.31.2 官方历史源码包，适合复现依赖解析、CMake 配置、二进制包兼容性和跨平台构建环境。

下载

• 用 conan remote add my-remote https://my.artifactory.com/conan 注册统一远程
• 所有成员运行 conan profile detect 后，手动校验并提交一份团队标准 profile（如 profiles/linux-gcc12-release），确保 os、arch、compiler.version、build_type 完全一致
• CI 流水线中固定用 conan create . --build=missing -pr=./profiles/linux-gcc12-release 构建并上传，保证远程二进制覆盖完整配置矩阵

锁文件（conan.lock）要纳入版本控制

没有 conan.lock，每次 conan install 都可能解析出不同依赖路径或二进制版本，导致“明明装了却还要重编”。

• 在项目根目录运行 conan lock --requires="fmt/10.2.1" --profile=./profiles/linux-gcc12-release 生成初始锁文件
• 所有 conan install 命令必须带 --lockfile=conan.lock，否则 Conan 会忽略锁并重新解析
• 当升级某个依赖时，只改 conanfile.txt 或 conanfile.py，再运行 conan lock --lockfile=conan.lock --update，让锁文件精准反映变更

交叉编译和嵌入式场景下更得小心二进制粒度

嵌入式项目常涉及多个 target triple（比如 armv7+gcc11+Release 和 aarch64+clang15+Debug），每个组合都对应独立二进制。若未严格区分，容易误复用或漏传。

• 用 conan profile new embedded-armv7 --detect 创建专用 profile，并手动覆盖 settings.os_build 和 settings.os_target
• 在 conanfile.py 中显式声明 self.settings_target = "os_target", "arch_target"（如果使用新式 toolchain）
• 上传时加 --remote=my-remote 和 --build=missing，避免本地缓存里混着不同 target 的产物却没推上去

最容易被忽略的是 profile 的 compiler.version 精确性——写成 12 和 12.3 在 Conan 2.x 中被视为不同设置，导致二进制无法命中。团队必须把 profile 当作构建脚本一样做 code review 和版本管理。