conan依赖版本被覆盖的本质是依赖树中某包的requires或override行为触发隐式重写，判断依据是conan.lock中resolved version与conanfile声明不一致；需查lock文件nodes下ref字段，并用conan graph build-order定位上游强依赖方。
Conan 依赖版本被覆盖，本质是依赖树中某个包的 requires 或 override 行为触发了隐式版本重写，而不是你声明的版本生效。最直接的判断依据是：运行 conan install 后，conan.lock 中该包的 resolved version 与你在 conanfile.py 或 conanfile.txt 里写的不一致。
看 conan.lock 文件里实际解析出的版本
这是唯一可信的真相来源。Conan 的依赖解析结果全部固化在 conan.lock 中，不是 conanfile 里写了什么就一定用什么。
- 打开
conan.lock，搜索目标包名（如fmt），找到它在graphs→nodes下的条目，检查ref字段值，例如fmt/10.2.1#r123abc... - 对比你
conanfile.txt中写的fmt/10.0.0或conanfile.py中self.requires("fmt/10.0.0")—— 如果不一致，说明已被覆盖 - 再查该节点的
requires字段，看是谁把它拉进来的（比如spdlog/1.13.0内部 requiresfmt/[>=10.1.0]），这就是覆盖源头
用 conan graph build-order 定位强依赖方
当某个包版本被“顶掉”，通常是它的上游依赖（transitive dependency）通过更严格的约束反向锁定了版本。用图命令能快速暴露谁在主导这个决策。
- 执行
conan graph build-order . --build=missing，它会输出按构建顺序排列的节点，并附带每个包的完整解析路径 - 重点关注目标包（如
zlib）所在行的requires列表，里面会显示类似openssl/3.0.10 → zlib/[>=1.2.12]这样的链路 - 如果某条路径中出现了
override=True标记，说明该路径上某个包显式强制了版本，优先级高于你的直接声明 - 注意
--build-order默认只显示缺失包；加--profile:build=default确保环境一致，避免 profile 差异干扰解析
检查是否误用了 override 或 conflict 机制
Conan 2.x 引入了显式 override 和 conflict 控制，但它们的行为容易被低估或误配。
-
self.requires("fmt/10.2.1", override=True)会强制整个图使用该版本，但若另一个包也用了override=True指向不同版本，Conan 会报错Conflict in fmt—— 如果没报错却版本不对，说明没人用override，而是被 semver 兼容规则“软覆盖”了 self.requires("fmt/[>=10.1.0 这类范围写法，在远程有多个匹配版本时，Conan 默认选最新可用二进制（非字典序最大），可能跳过你期望的 <code>10.0.0- 在
conanfile.py的requirements()方法里动态添加requires，比requires类属性更晚执行，也可能覆盖早期声明
为什么 conan install 不报错但版本变了
Conan 默认启用 semver 兼容匹配（如 fmt/10.0.0 可接受 fmt/10.2.1），且不校验“是否严格等于”。这在多数场景是便利，但在需要确定性时就是隐患。
- 加
--lockfile-preserve参数运行conan install，它会拒绝任何 lockfile 变更，一旦版本被覆盖就会失败，强制你干预 - 在
conanfile.py中用self.requires("fmt/10.0.0", force=True)（Conan 2.1+）可禁用 semver 升级，但要注意：force 会破坏依赖图一致性，仅限调试用 - 真正可靠的方案是：每次修改依赖后都
conan lock create .并提交conan.lock，让 CI 和团队共用同一份解析结果 —— 版本覆盖问题只在 lockfile 未受控时才频繁发生
版本覆盖本身不是 bug，而是 Conan 依赖解析机制的自然结果；真正的复杂点在于：它往往发生在间接依赖层，且不抛异常。所以排查必须从 conan.lock 出发，而不是盯着自己的 conanfile。
