conan install 时用 --remote=remote_name 显式指定已注册的远程仓库，仅本次生效且不自动 fallback；conanfile 中不可硬编码 remote，需通过 CI 脚本统一配置并确保每次环境干净。
conan install 时如何指定 remote 参数
Conan 默认从第一个启用的 remote 拉取包，但你可以在 conan install 命令中显式用 --remote 指定来源。这是最直接、最可控的方式，尤其适合多仓库场景（比如私有仓库 + conancenter）。
- 命令格式：
conan install . --output-folder=build --remote=my-private-remote - 如果依赖在指定 remote 中不存在，会报错
ERROR: Package 'xxx' not found in remote 'my-private-remote'，不会自动 fallback 到其他 remote - 该参数只影响本次安装，不修改全局配置；适合 CI 脚本或临时验证
- 注意：
--remote必须配合conan remote list中已注册的 remote 名使用，不能传 URL
conanfile.txt 或 conanfile.py 中能否硬编码 remote？
不能。Conan 的依赖声明文件（conanfile.txt 和 conanfile.py）本身不支持写死 remote。remote 是客户端运行时策略，属于配置层，不是包元数据的一部分。强行“绑定”会导致协作困难和环境不可移植。
- 常见误解：试图在
[requires]下加注释如# from my-internal—— 这毫无作用 - 正确做法是靠 profile 或 CI 环境统一控制
--remote参数，或用conan remote enable/disable动态开关 - 若需差异化分发（如 dev 包走 internal，stable 包走 conancenter），应通过
user/channel或版本号（如mylib/1.2.0@dev/stable）区分，再配合 remote 权限策略
远程仓库优先级与 fallback 行为
Conan 不支持自动 fallback 到下一个 remote。它严格按 conan remote list 输出顺序查找，且仅对启用状态（enabled）的 remote 生效。所谓“默认 remote”只是列表里排第一的启用项。
- 查看当前顺序：
conan remote list，输出类似：conancenter: https://center.conan.io [Verify SSL: True, Enabled: True] my-internal: https://conan.internal.company.com [Verify SSL: True, Enabled: True]
- 调整顺序：
conan remote update conancenter --index 0（把 conancenter 移到首位） - 临时禁用某个 remote：
conan remote disable my-internal，避免误拉取 - 重要：即使
my-internal排第二，只要它 enabled，Conan 就会在 conancenter 找不到时继续查它——这不是 fallback，而是遍历所有 enabled remote
CI/CD 中安全指定 remote 的实践要点
在自动化流程里硬编码 remote 名看似简单，但容易因环境差异出错。关键点在于解耦配置与逻辑。
- 不要在
conanfile.py里调用self.run("conan remote add ...")—— 这污染了构建逻辑，且权限/网络可能不满足 - 推荐方式：在 CI 脚本开头统一执行
conan remote add和conan remote login，再用--remote显式调用 - 敏感信息（如 token）必须通过环境变量注入，禁止写进脚本或 profile 文件
- profile 文件（如
ci-gcc11-linux）里只存编译器、arch 等构建参数，remote 仍由命令行控制
实际项目里最容易被忽略的是：remote 启用状态是持久化在本地 ~/.conan/remotes.json 的，不同用户或容器之间不会共享。CI 镜像每次启动都应视为“干净环境”，必须重新 add 和 enable，否则 --remote xxx 会直接失败。
