Conan --build=missing 仅在本地缓存中缺失与当前 settings（如os、arch、compiler.version）和options（如shared=True）完全匹配的二进制时，才从源码构建；其核心判断依据是package ID是否命中缓存。
conan create 时 --build=missing 的实际触发逻辑
Conan 不会“自动重构建”，它只在明确缺失对应二进制时才从源码构建。关键判断依据是 package ID：只要本地缓存中存在与当前 settings（如 os, arch, compiler.version, build_type）和 options（如 shared=True）完全匹配的二进制，conan create . --build=missing 就跳过编译，直接复用。
常见误判场景：
- 改了
conanfile.py里的version或revision，但没清缓存 → 新版本无二进制，必然重构建 - profile 里
compiler.cppstd=17改成20→package ID变，旧二进制不匹配，触发构建 - 本地修改了源码（比如 patch 了 CMakeLists.txt），但没改
revision→ Conan 不感知，仍用旧二进制，结果可能出错
远程仓库有包，但 conan install 还是走本地构建？
这通常不是“重新构建”，而是根本没命中远程二进制。原因集中在维度不一致：
-
conan remote list显示的默认远程仍是旧版https://conan.io/center，而 ConanCenter 自 2.9.2 起已切到https://center2.conan.io→ 远程查不到包，fallback 到--build=missing - 你的 profile 用了
compiler.libcxx=libstdc++11，但远程只提供了libstdc++→ ABI 不兼容，无法复用 - 执行
conan install时没传--profile，用了默认 profile，而该 profile 的os是Linux，但你实际在 WSL 里跑，os.subsystem可能被识别为windows→ 维度错位
如何强制跳过缓存、每次都重构建？
别用 --build=missing，改用：
-
conan create . --build=always：无视缓存，全部从源码构建（适合调试 build() 流程） -
conan create . --build=fast-lzma2：只对指定包名重构建，其余依赖仍走缓存（适合局部验证） - 先
conan remove "fast-lzma2/*"再conan create . --build=missing：手动清理后重建，最可控
注意：--build=never 会直接失败（如果缓存里没有匹配二进制），不是“不构建”，而是“拒绝构建”。
为什么改了 shared=False 却没触发重构建？
因为 shared 是 option，它参与 package ID 计算 —— 但前提是这个 option 在 conanfile.py 中被声明且未被硬编码。检查你的配方：
- 如果
options = {"shared": [True, False]}存在，且你运行的是conan create . -o shared=True，那shared=False确实会生成新package ID - 如果
default_options = {"shared": False}但没声明options字段 → Conan 忽略该 option，不会进入package ID，自然不触发重建 - 如果
conanfile.py里写了self.options.shared = False在config_options()中强制覆盖 → 同样绕过 option 机制，ID 不变
真正容易被忽略的是：Conan 不校验源码变更，只认维度+recipe 声明。哪怕你改了压缩算法实现，只要 package ID 没变，它就认为“这个二进制还有效”。
