conan lock 本质是对依赖图进行快照式求解，生成确定的版本+配置组合并写入 conan.lock 文件；后续操作需显式指定该文件才能跳过解析、确保版本固定。
conan lock 生成 lockfile 的本质是什么
Conan 的 conan lock 不是“手动指定版本”，而是对当前依赖图做一次**快照式求解**：它会根据 conanfile.py 或 conanfile.txt 中的约束（如 zlib/1.2.*）、远程仓库中实际可用的版本、以及已缓存的二进制兼容性信息，算出一组确定的版本+配置组合，并写入 conan.lock 文件。这个文件就是“锁定”的载体。
后续所有构建、安装、上传都默认读取该 lockfile，跳过版本解析阶段——这才是真正意义上的“固定”。
如何生成并复用 conan.lock
最简流程就是两步：先生成，再带上它执行操作。注意路径和上下文必须一致：
- 在项目根目录运行
conan lock --requires="fmt/10.2.1" --base（--base表示只锁基础依赖，不展开 profile 差异） - 或更常用：
conan lock --profile=linux-gcc12 --lockfile-out=conan.lock，确保 profile 和构建环境匹配 - 之后所有命令都显式加
--lockfile=conan.lock，比如：conan install . --lockfile=conan.lock --build=missing - 如果没指定
--lockfile-out，Conan 默认输出到当前目录的conan.lock；但若项目有多个配置（debug/release），建议按需命名，如conan-release.lock
为什么 conan install 有时还是变了版本
常见原因不是 lockfile 失效，而是你根本没用上它：
- 忘记加
--lockfile=xxx参数，Conan 就会重新走 resolver 流程，尤其当远程新增了更高 patch 版本（如从openssl/3.2.1到3.2.2）时，3.2.*约束就会拉新版本 -
conanfile.py里用了self.requires("boost/[>=1.80 这类动态范围，lockfile 虽然记住了当时选的 <code>1.83.0，但若你删掉 lockfile 后重跑，就可能变成1.84.0 - profile 变了（比如换了 compiler.version），Conan 认为这是不同二进制上下文，会忽略旧 lockfile 并重新计算——此时需用
conan lock --lockfile=old.lock --profile=new.profile --lockfile-out=new.lock迁移
CI/CD 中怎么保证 lockfile 真正生效
关键点在于：lockfile 必须被检入 Git，且 CI 脚本不能跳过它。
- 推荐在 PR 流程中加入检查：用
conan lock --lockfile=conan.lock --verify验证当前 conanfile 和 profile 是否与 lockfile 兼容；失败说明有人改了依赖却没更新 lockfile - CI 安装命令必须带
--lockfile=conan.lock，不能只写conan install . - 如果项目使用
conanfile.txt，注意它本身不支持[requires]块里的版本覆盖逻辑，所有版本控制必须靠 lockfile —— 这时更不能漏掉--lockfile
lockfile 是声明式快照，不是魔法开关；它只在被明确引用时起作用，而且一旦生成，里面记录的每个 reference（如 zlib/1.2.13#r1a2b3c）都包含 recipe revision，连配方变更都被锁死——这点常被忽略。
