Conan默认不重复编译已有二进制包，但“conan install总走build=missing”的主因是settings（os/arch/compiler等）不匹配导致缓存未命中；需显式指定profile、对齐host/build、启用远程预编译包与ccache协同，并确保其持久化挂载。
Conan 默认不会重复编译已存在的二进制包，但你每次看到“正在构建 xxx”或 CI 耗时十几分钟，大概率不是 Conan 本身在重编译，而是它没找到匹配的缓存——要么根本没生成过，要么生成了但当前配置不匹配，导致 fallback 到源码构建。
为什么 conan install 总是 build=missing？
最常见原因是：你没显式指定 --profile，或 profile 中的 settings（如 os、arch、compiler、compiler.version、compiler.libcxx）和本地环境/目标平台不一致。Conan 把这些 settings 当作二进制唯一标识的一部分，只要其中一项不同，就认为是全新包，必须重新构建。
比如你在 macOS 上用 Clang 15 编译，但 profile 写的是 compiler=gcc，Conan 就找不到已有缓存，只能从头来。
- 运行
conan profile show default看当前 profile 是否真实反映你的构建环境 - 交叉编译时务必用
--profile:host和--profile:build显式区分，不能只靠 default - 检查
conan search <ref>（如conan search fmt/10.2.1）是否列出已有的二进制，注意看settings列是否和你当前一致
如何让 Conan 复用已构建的二进制？
核心是确保“构建请求”和“已有缓存”的 settings + options 完全对齐。Conan 不会自动降级或适配——它严格按签名匹配。
- 统一使用命名 profile 文件（如
profiles/linux-gcc11-release），而不是靠conan install -s os=Linux -s compiler=gcc...手动拼参数，容易漏项或大小写错误 - 在
conanfile.py中固定default_options，避免依赖方传入不同 options 导致二进制不复用（例如shared=True和shared=False是完全不同的二进制） - CI 中不要用
--build=missing无脑兜底；先用--build=never测试能否命中缓存，失败再切到--build=missing并记录原因 - 启用远程缓存（如 Artifactory 或 ConanCenter 的 prebuilt binaries），很多流行库（fmt、spdlog、zlib）官方已提供大量预编译二进制，直接下载比本地编译快得多
ccache 和 Conan cache 怎么协同？
Conan 自身的缓存（~/.conan2）只管包元数据和二进制分发，不加速源码编译过程；而 ccache 加速的是单个包内部的 C/C++ 编译阶段。两者必须配合才能真正减少“构建时间”。
- 在 profile 中通过
conf设置启用 ccache：tools.cmake.cachepath=/path/to/ccache（Conan 2.x）或旧版用tools.env:CCACHE_PATH - 确保所有 Conan 包的构建逻辑都尊重
CC/CXX环境变量，否则 ccache 不会被调用 - ccache 本身需要独立挂载或持久化（尤其在容器 CI 中），否则每次 job 启动都是空 cache —— 这正是“冷启动慢”的主因之一
- 交叉编译时，ccache 必须和工具链路径对齐；比如用 aarch64-linux-gnu-gcc，ccache 需指向该路径，而非系统默认 gcc
真正卡住构建速度的，往往不是 Conan 本身，而是 settings 对不齐、profile 没管住、ccache 没挂上、远程二进制没开——这些点任何一个松动，都会让“复用”变成“重来”。尤其在交叉编译场景下，host/build profile 分离不彻底，是最隐蔽也最常被忽略的坑。
