Conan 多仓库是设计初衷而非额外支持，各 remote 平权独立，需显式指定 -r 查找或上传，default_remote 可通过 profile 配置避免误用 ConanCenter。
适合，而且是设计初衷之一。Conan 的去中心化架构不是为了“支持多仓库”，而是默认就按多仓库协同工作——它不强制你把所有依赖塞进一个中心源，也不要求所有团队共用同一套远程配置。
conan remote list 显示的每个 remote 都是独立可信源
Conan 不像 Maven 或 pip 那样有“中央仓库优先”的隐含逻辑。每个 remote 是平权的，conan install 会按顺序查所有已配置的 remote（除非显式指定 -r=xxx），但不会自动合并或降级匹配结果。
- 常见错误：误以为添加多个 remote 后，
conan search zlib/*会聚合所有结果 —— 实际上必须加-r=xxx指定远程，否则只查本地缓存 - 正确做法：用
conan list "zlib/*" -r=conancenter和conan list "zlib/*" -r=myinternal分别查，再人工比对版本、revision、二进制可用性 - 注意：不同 remote 上同名包（如
openssl/3.2.1）可能对应完全不同的conanfile.py内容和构建逻辑，不能假设语义一致
profile + conanfile.txt 中的 remote 绑定容易被忽略
Conan 2.x 默认不绑定 profile 到特定 remote，但你在 CI 或多环境协作中，常需要确保某组构建参数（比如 linux_gcc12_release）只从私有仓库拉取二进制，避免意外命中 ConanCenter 的旧版或不兼容 build。
- 推荐做法：在 profile 文件末尾加
[conf]段落，写tools.conan:default_remote = myinternal - 不推荐做法：靠
conan remote add --force覆盖默认顺序 —— 这会让本地开发和 CI 行为不一致，尤其当conan install没带-r时行为难预测 - 隐患点：如果 profile 里没设
default_remote，而conanfile.txt又没声明requires的 remote，Conan 会 fallback 到第一个可用 remote（通常是conancenter），这在企业项目里极易导致漏测私有 patch
上传包时 -r 参数必须显式指定，且不支持通配符
conan upload 命令不接受 -r=* 或 -r=all，每个上传动作必须明确指向一个 remote。这对多仓库发布流程是个硬性约束，也是防止误发的关键设计。
- 典型场景：你维护一个内部基础库
mybase/2.3.0，需同时推送到dev-internal（供测试）和prod-internal（供发布），必须执行两条命令：conan upload mybase/2.3.0 -r=dev-internal和conan upload mybase/2.3.0 -r=prod-internal - 常见疏漏：脚本里漏写
-r，结果包只上传到默认 remote（通常是第一个添加的），其他仓库空缺，下游conan install失败却报错模糊（提示 “package not found”，而非 “not found on specified remote”） - 技巧：用
conan upload "*@*" --all -r=myremote批量上传当前缓存中所有包到指定 remote，但注意它不会跨 remote 同步 —— 每个 remote 都得单独跑一遍
真正复杂的点不在“能不能用多仓库”，而在于 remote 之间的信任边界和缓存隔离是否清晰。比如 conancenter 上的 fmt/10.2.1 和你内部 myfmt/10.2.1-patch1 看似版本接近，但 revision 不同、settings 可能不兼容，Conan 不会自动做等价替换 —— 它只认完整引用（name/version@user/channel#rrev）。这点一旦忽略，多仓库就从优势变成隐患。
