conan.lock文件是conan依赖锁定的核心，通过dag算法解析完整依赖树并记录精确版本、配置与选项，确保构建可重复；冲突不自动解决，需显式用override或editable干预。
Conan 本身不回避依赖冲突，而是把冲突显式暴露出来，并提供可追溯、可锁定的解决路径。它不会自动“选一个版本就装”，而是强制你面对版本差异带来的构建确定性问题。
conan lock create 生成的 conan.lock 文件是冲突处理的核心
当你运行 conan lock create .，Conan 会解析整个依赖树，用 DAG 算法计算出所有直接和传递依赖的精确版本、配置（settings）和选项（options），然后写入 conan.lock。这个文件就是构建事实的唯一来源。
- 没有
conan.lock时，每次conan install都可能因远程仓库更新、缓存状态不同而拉取不同二进制，导致“昨天能编译，今天链接失败” - 有
conan.lock后，conan install --lockfile=conan.lock会严格复现相同环境，哪怕某个依赖在远程已发布新版 - 若两个子依赖分别要求
openssl/3.0.8和openssl/3.0.10，Conan 默认拒绝合并，报错类似ERROR: Conflict in openssl: requirement openssl/3.0.8 conflicts with openssl/3.0.10
手动干预冲突：editables + override 是最常用组合
当锁文件报冲突，又不能简单升级/降级某一方时，override 是最小侵入解法——它不修改依赖源码，只在当前项目层指定“以谁为准”。
- 在
conanfile.py的requirements()方法里用self.requires("openssl/3.0.10", override=True) -
override=True表示：不管其他依赖怎么声明 openssl 版本，最终整个图只认这一个 - 搭配
editable可调试本地修改：比如self.requires("mylib/1.0@user/dev", editable=True)，Conan 会软链接源码目录而非拷贝二进制，改完头文件立刻生效 - 注意：override 不解决 ABI 兼容问题。如果
openssl/3.0.8和3.0.10的 C++ 符号 ABI 不兼容，仅靠 override 仍可能运行时报undefined symbol
为什么 conan install --build=missing 有时反而加剧冲突？
很多人以为加了 --build=missing 就能“万事大吉”，其实它会让 Conan 在遇到无法匹配预编译二进制时，转而从源码构建——而这恰恰放大了配置不一致的风险。
- 例如：A 依赖要求
zlib:shared=False，B 依赖要求zlib:shared=True，Conan 无法同时满足，就会触发构建逻辑分支冲突 - 此时
--build=missing可能让 Conan 尝试用不同shared值各构建一次 zlib，但最终链接阶段仍失败 - 正确做法是先统一选项：
conan install . -o zlib:shared=True显式指定，再配合--lockfile固化 - 更稳妥的是在
conanfile.py的default_options中提前声明关键依赖的一致性约束
真正难的不是发现冲突，而是判断该不该妥协——比如某个旧版库硬编码了 OpenSSL 3.0.8 的符号名，而新依赖必须用 3.0.10，这时就得查 ABI 报告或干脆 fork 改源码。Conan 把选择权交给你，而不是替你决定。
