conan私有仓库中包id不匹配的典型现象是执行conan install或conan build时卡在依赖解析并报“missing binary”，实则因本地与远程package id不一致所致；id由settings、options、requires共同决定，需用conan info和conan search --table比对id，常见差异包括build_type、shared选项写法、requires可见性及revisions未启用。
Conan私有仓库中包ID不匹配的典型现象
执行 conan install 或 conan build 时卡在依赖解析阶段，报错类似：ERROR: Missing binary: mylib/1.2.0@company/stable，但你确认该包已用 conan upload 推送到私有远程，并且 conan search mylib/1.2.0@company/stable -r=my-remote 能查到——问题大概率是 ID 不匹配，不是“没上传”，而是“对不上”。
验证本地计算出的package ID是否与远程一致
Conan 的 package ID 是由 settings + options + requires 共同决定的，哪怕只改一个 shared=True，ID 就完全不同。必须两端一致才能复用二进制。
- 在本地运行
conan info . --graph=deps.html（当前目录含conanfile.py），打开生成的 HTML，看mylib节点末尾显示的 ID 字符串（如5ab3c2f...） - 登录私有远程仓库 Web 界面（如 Artifactory、Nexus 的 Conan repo 页面），定位到
mylib/1.2.0@company/stable对应的二进制包，查看其 Package ID 字段 - 或命令行查：运行
conan search mylib/1.2.0@company/stable -r=my-remote --table，对比输出中的 ID 列
常见导致 ID 不一致的配置点
ID 不一致不是随机发生的，几乎都源于以下几处被忽略的隐式差异：
-
settings值不同：比如本地用build_type=Debug，但远程二进制是用build_type=Release构建的；检查conan profile show default和远程构建时用的 profile 是否一致 -
options写法不统一：例如mylib:shared=Truevsmylib/*:shared=True，后者会透传给所有子依赖，可能意外覆盖上游要求 -
requires的 visibility 模式：默认requires=["opencv/4.5.5"]是 public，会被下游继承并参与 ID 计算；若上游强制要求旧版 opencv（如opencv/2.4.13），而你的项目又引入了新版，ID 就会因 opencv 版本冲突而变 —— 此时需改用requires=[("opencv/2.4.13", "private")] - 远程仓库未启用 revision 模式：如果私有远程没开启
revisions_enabled = 1（Artifactory 需手动开），同一conanfile.py多次上传会被覆盖，旧 ID 二进制实际已丢失
强制复用某二进制而不重编译的临时方案
当确认远程已有可用二进制、只是 ID 因某项设置不一致而被跳过时，可绕过 ID 校验直接绑定：
- 用
--build=missing是默认行为，会触发重编译 —— 不要加 - 改用
--build=never强制跳过构建，但前提是 ID 必须完全匹配，否则报错 - 真正起效的是
conan install . -r=my-remote --build=never --update，其中--update会刷新远程元数据缓存，避免本地 cache 里残留旧 ID - 终极调试手段：临时删掉
~/.conan/data/mylib/下本地缓存，再conan install，确保走的是干净远程拉取路径
ID 匹配是 Conan 的硬性规则，没有模糊容错；所有“看起来一样却不用”的情况，背后都有至少一项 settings/options/requires 的字节级差异。别猜，先 conan info 出 ID，再逐字段比对。
