“Cannot resolve dependency”是传递依赖冲突的直接表现，需在conanfile.py中显式声明根约束版本（如"zlib/1.2.13"）或用override=True强制覆盖；conan.lock仅保证依赖结构一致，不验证二进制兼容性，须检查settings/options统一性并提交lock文件以确保构建可重现。
conan install 时出现 “Cannot resolve dependency” 错误
这是传递依赖冲突最直接的表现：两个上游包（比如 openssl/3.0.10 和 curl/8.10.1）各自要求不同版本的 zlib，而 Conan 默认策略无法自动合并。它不会像 npm 那样“提升”一个版本去满足所有需求，而是严格按 DAG 检查一致性。
解决方式不是手动删掉某个包，而是让 Conan 显式知道你倾向哪个版本：
- 在
conanfile.py的requires中直接声明你认可的 zlib 版本，例如"zlib/1.2.13"—— 这会成为“根约束”，覆盖下游传递来的冲突版本 - 用
override=True强制覆盖（仅限 Conan 2.x）：requires = [ "openssl/3.0.10", "curl/8.10.1", ("zlib/1.2.13", "override") # 注意括号写法 ] - 避免在多个子依赖中重复指定同一包的不同版本，否则 override 会失效
为什么 conan lock create 不报错但构建失败？
因为锁文件（conan.lock）只保证依赖树结构一致，并不验证二进制兼容性。比如 boost/1.81.0 要求 zlib/1.2.12 编译为 static，而你显式声明的 zlib/1.2.13 在远程仓库只有 shared 二进制 —— 此时 conan install 会卡在构建阶段，报类似 ERROR: Missing binary: zlib/1.2.13。
关键检查点：
- 运行
conan graph info . --lockfile=conan.lock查看实际解析出的每个包的settings和options，确认 zlib 的shared=True/False是否统一 - 用
conan search zlib/1.2.13@ -r conancenter看该版本是否提供你当前-s下的二进制（如os=Linux,compiler=gcc） - 若缺失，加
--build=zlib或改用--build=missing让它现场编译
conan install --build=missing 后仍链接失败
常见于符号不匹配：比如 A 包用 libcxx=libstdc++11 编译，B 包用 libcxx=libc++，它们都依赖 fmt，但 Conan 拉下来的 fmt 二进制只对应其中一种 STL 实现，导致链接时报 undefined reference。
这不是版本冲突，而是配置维度不一致。必须确保所有包在相同 settings 下构建：
- 不要混用 profile：用
conan install . -pr:b default -pr:h linux-gcc-release明确区分 build/host 环境 - 检查
conan profile show linux-gcc-release输出中compiler.libcxx是否统一（C++ 项目通常锁定为libstdc++11或libc++，不能动态切换） - 如果必须混合 STL，只能把冲突包设为
header_only=True或改用源码集成（requires = ("fmt/10.2.1", "private")+no_copy_sources=True）
团队协作中 lock 文件未提交导致“在我机器上能跑”
conan.lock 是解决传递依赖冲突的唯一事实来源。不提交它，每个人 conan install 都会重新解析依赖树 —— 可能今天拉到 zlib/1.2.13，明天 CI 拉到 zlib/1.2.12，而后者恰好和某个子依赖的 ABI 不兼容。
必须做到：
- CI 流程第一行执行
conan lock create . --lockfile-out=conan.lock，而不是跳过 - 开发机上每次改
requires或profile后，立刻conan lock update . --lockfile=conan.lock - 禁止在 CI 中使用
--build=missing以外的--build参数，否则锁文件失去意义
真正难处理的从来不是“哪个版本更高”，而是“哪个配置组合能同时满足所有传递路径”。锁文件不是可选附件，它是传递依赖冲突的仲裁协议——漏掉它，等于没签合同。
