conan install --force-reinstall 仅强制重装当前声明的依赖版本，不改变版本号；真正回退需修改 conanfile.py 中 requires() 的版本字符串、删除 conan.lock 并执行 conan install . --build=missing。
conan install --force-reinstall 不是回退，只是重装
执行 conan install --force-reinstall 会强制重新下载/构建当前 conanfile.py 声明的依赖，但它不会改变版本号——如果 requires("zlib/1.2.13") 写死了，它就只重装 1.2.13；如果写的是 "zlib/[^1.2.11]"，它仍可能拉到 1.2.13 或更高兼容版。这不是“回退”，只是刷新本地缓存。
真正回退依赖版本，核心动作只有一个：改 requires() 行里的版本字符串，再重跑 conan install。
- 直接编辑
conanfile.py中的self.requires("pkg/old.version")，比如把"fmt/10.1.1"改成"fmt/8.1.1" - 确保该旧版本在你配置的远程仓库中存在（运行
conan search fmt/* -r conancenter验证） - 删掉
conan.lock（如有），避免锁文件干扰版本解析 - 运行
conan install . --build=missing，Conan 会按新声明重建整个依赖图
conanfile.py 里怎么安全指定旧版本？
硬编码版本如 "openssl/3.0.12" 最直接，但容易因子依赖冲突失败。更稳妥的方式是结合 conf 控制解析行为：
- 用
self.requires("openssl/3.0.12", override=True)强制覆盖其他地方对 openssl 的版本声明（常见于 transitive 依赖冲突） - 若需全局压制所有依赖的 openssl 版本，可在
conanfile.py顶部加python_requires = "openssl/3.0.12"（仅限 Conan 2.x） - 检查
conan show openssl/3.0.12输出的requires字段，确认它不依赖你环境中已不存在的组件（比如过高的 C++ 标准或已被弃用的 OpenSSL 选项）
为什么 conan install 后还是新版本？常见卡点
最常被忽略的是 conan.lock 文件——它一旦存在且包含新版本记录，conan install 默认优先服从 lock，而不是 conanfile.py。现象是：改了 requires，但 conan install 输出 “Already installed” 且 conan list 显示仍是新版。
- 先运行
conan list "pkg/*" --graph=conan.lock确认 lock 里实际记录的版本 - 若 lock 不是你想要的，删掉它：
rm conan.lock（Windows 用del conan.lock） - 别用
conan lock命令生成新 lock，它不校验conanfile.py是否匹配，容易埋坑 - 验证是否生效：运行
conan list "pkg/*" --graph=.，输出必须显示你指定的旧版本号
子依赖冲突时怎么定位封杀者？
执行 conan install 报错 “Cannot resolve dependencies” 时，错误信息通常只说 “conflict”，不说谁在拦路。关键命令是：
-
conan graph lock . --requires="pkg/old.version"—— 尝试生成锁图，失败时会指出第一个冲突点 -
conan graph build-order . --requires="pkg/old.version"—— 列出构建顺序，其中带ERROR的节点就是冲突源头 - 若用 Conan 2.x，启用详细日志：
conan install . -v --build=missing 2>&1 | grep -A5 -B5 "pkg"，看哪一层 require 了不兼容版本
复杂点在于：一个旧版包可能要求某个编译器 ABI（如 compiler.libcxx=libstdc++11），而你的 profile 用了 libstdc++14，这时它根本不会进入候选列表——连冲突都不会报，只会静默跳过。得手动核对 conan show pkg/old.version 的 settings 兼容性字段。
