关键在于统一版本决策与锁死路径：通过conan.lock文件固化依赖图，配合统一remote源、禁用fallback、隔离缓存及定期校验profile/remote一致性，确保团队复现完全相同的二进制依赖树。
Conan 怎么让团队使用同一套依赖 —— 关键不在“怎么配”，而在“谁来决定版本”和“如何锁死路径”。默认情况下，conan install 会从远程仓库拉取满足 version_ranges（如 fmt/10.x）的最新兼容版，这正是团队依赖不一致的根源。
用 conan.lock 文件固化整个依赖图
Conan 2.x 默认启用 lockfile 机制。只要团队成员都基于同一个 conan.lock 执行安装，就能复现完全一致的二进制依赖树。
- 首次生成：在项目根目录运行
conan install . --lockfile-out=conan.lock，它会记录所有解析出的包 ID、远程源、构建上下文等 - 后续协作：把
conan.lock提交到 Git，队友只需conan install . --lockfile=conan.lock，Conan 就不会重新解析版本，而是严格按锁文件还原 - 注意：如果修改了
conanfile.py中的requires或配置（如settings.os），必须重新生成 lockfile 并提交，否则队友执行时会报错Lockfile not compatible
统一 remote 源并禁用自动 fallback
即使有 lockfile，如果 team 成员各自配置了不同 remote（比如有人加了 conancenter，有人加了私有仓库），Conan 可能从不同源拉取相同引用的包，导致二进制不一致。
- 强制使用指定 remote：在
conan install命令中显式指定--remote=my-company，避免 Conan 自动遍历所有 remote 查找 - 禁用 fallback 行为：在
conan.conf中设置general.revisions_enabled = True（推荐），并确保所有 remote 都开启 revisions；同时避免使用conan remote add --force覆盖已有 remote - 检查一致性：团队可定期运行
conan remote list和conan profile show default对比输出，确认 settings、remotes、profiles 完全一致
避免本地缓存污染导致“明明用了 lock 却不一样”
Conan 缓存是本地的，如果某人手动运行过 conan create 或 conan export-pkg，可能把未经过 CI 验证的本地包写入缓存，干扰 lockfile 的效果。
- CI/CD 中应使用 clean 缓存：例如 GitHub Actions 里加
conan cache clean "*"或直接用conan config set storage.path=/tmp/conan_cache隔离 - 开发机上慎用
conan upload --force：它会覆盖远程已存在的包，但 lockfile 仍指向旧 revision，造成语义冲突 - 验证是否真一致：对比两台机器上同一依赖项的完整引用，例如
fmt/10.2.1#8a7b3c4d...（含 revision hash），而不仅是fmt/10.2.1
最常被忽略的一点：lockfile 不是“一次生成永久有效”的快照，它隐式绑定当前 profile 和 remote 状态。换平台（Windows → Linux）、换编译器（Clang 15 → GCC 12）或换 remote 地址，都会使原有 lockfile 失效——这时必须重新生成并同步，而不是强行复用。
