conan 默认按 remote 顺序查找包，但私有仓库优先依赖于包名匹配与虚拟仓库路由机制：只要私有仓库（如 artifactory 虚拟仓库 cpp-all）中存在完全匹配的 reference（含 user/channel），即命中返回，不再查询公共仓库；若未命中或 reference 不一致（如缺 @user/channel），则继续遍历后续 remote。
Conan 默认按 remote 添加顺序查找包，但“优先使用私有仓库”不是靠顺序决定的——而是靠远程仓库的配置策略和包名解析逻辑。简单说：只要私有仓库里有匹配的包（同名、同版本、同配置），Conan 就不会去查公共仓库；但如果私有仓库没命中，它会继续往下找。所以关键不是“怎么强制优先”，而是“怎么确保私有包能被正确识别并拦截请求”。
conan remote add 时的 --insert 参数不解决优先级问题
很多人误以为加 --insert 就能让私有仓库排第一、从而“优先”。其实它只影响 conan search 或 conan install --remote=all 这类显式多源操作的遍历顺序，对日常 conan install 没影响。Conan 的默认行为是：逐个 remote 查询，直到第一个返回成功结果为止。所以真正起作用的是“哪个 remote 先返回包”，而不是“谁在列表第几位”。
-
conan remote add my-private https://artifactory.example.com/artifactory/cpp-all—— 推荐用虚拟仓库（cpp-all）作为统一入口，里面已聚合了cpp-local和conan-center - 不要用
--insert去抢序，除非你明确需要--remote=all场景下的搜索顺序控制 - 如果私有仓库是本地
file:///path/to/local类型，它响应极快，天然容易“先命中”；但生产环境不推荐这种模式
包名冲突时，私有仓库必须提供完整且可区分的 reference
Conan 不会因为仓库“私有”就自动降权或升权。比如你上传了 fmt/10.2.0@myteam/stable 到私有仓库，但项目中写的是 fmt/10.2.0（无用户/通道），Conan 仍会去 conan-center 找——因为 reference 不匹配。要让私有包生效，必须保证 requires 中的 reference 完全一致：
- 在
conanfile.txt或conanfile.py中写明完整 reference：fmt/10.2.0@myteam/stable - 或者用
conan remote add --force覆盖默认 remote 名为conancenter，再把私有虚拟仓库命名为conancenter（不推荐，易混淆） - 更稳妥的做法：私有仓库只存内部包（如
mylib/1.2.0@），公共包一律走conan-center；通过命名空间隔离，避免 reference 冲突
Artifactory 虚拟仓库是实际生效的关键
你在 Artifactory 后台创建的 cpp-all 虚拟仓库，才是真正让“私有优先”落地的组件。它不是简单拼接，而是按预设顺序路由请求：先查 cpp-local → 命中则返回 → 未命中才查 conan-center（远程仓库）。这个顺序在 Artifactory UI 的 “Repositories > Virtual Repositories > cpp-all > Repositories” 里可拖拽调整。
- 确保
cpp-local在虚拟仓库的 repository list 中排第一位 - 检查
conan-center远程仓库的 “Offline Mode” 是否关闭，否则它不会参与代理查询 - 客户端只需配置一个 remote：
conan remote add artifactory https://artifactory.example.com/artifactory/cpp-all - 上传包时用
conan upload "mylib/*" -r=artifactory --check，确保进的是cpp-local
最容易被忽略的一点：Conan 客户端缓存（~/.conan/data）里如果已有从 conan-center 下载的同名包，conan install 可能直接复用本地缓存，根本不去连任何 remote。遇到“明明私有仓库有更新却没拉到”，先跑 conan remove "mylib/*" 清缓存，再加 -r=artifactory 显式指定 remote。
