Conan 2.0 的 conan.lock 文件是实现 C++ 构建可复现性的核心机制,固化 package_id、revision、settings、options 及依赖拓扑;必须在 CI/CD、团队协作、稳定分支等场景生成并提交,且须与 conanfile 成对更新。
Conan 2.0 的 conan.lock 文件是实现 C++ 构建可复现性的核心机制——它不只记录依赖版本,还固化了每个依赖的 package_id、revision、配置(如 settings 和 options)以及整个依赖图的拓扑结构。只要 lockfile 不变,conan install 就会复现完全一致的二进制依赖。
conan.lock?不是所有场景都需要 lockfile,但以下情况必须生成并纳入版本控制:
release/2.5),要求任意时间 checkout 后都能重建相同产物关键点:lockfile 必须和 conanfile.py / conanfile.txt 成对提交;修改 conanfile 后,需显式重新 lock,不能沿用旧 lockfile。
conan lock 命令的必要参数与常见误用最简锁操作不是 conan install,而是独立的 conan lock 命令。它不触发下载,只计算并写入 lockfile,因此更安全、更可控。
conan lock --requires="fmt/10.2.1" --settings=os=Linux --settings=arch=x86_64 --settings=compiler=gcc --settings=compiler.version=12 --settings=compiler.libcxx=libstdc++11 -o build_type=Release
容易踩的坑:
--settings:即使 conanfile 中有默认值,lockfile 仍以命令行传入为准;未指定则用当前 profile 默认值,CI 环境 profile 可能不同--profile 和 --settings:二者不可共存;若用 profile,请确保 profile 文件内容稳定(建议用绝对路径或 git submodule 引用)--build 策略:lockfile 本身不决定是否构建源码,但 --build=missing 这类策略会影响最终 package_id,应统一在 CI 脚本中固定运行 conan lock --check 是最直接的方式:它会重算当前 conanfile + settings 下的 lockfile,对比是否与磁盘上已存在的 conan.lock 完全一致。不一致即说明 lockfile 已过期或被手动篡改。
还可人工检查 lockfile 内容:
"revisions_enabled": true 必须为 true(Conan 2.0 默认开启),否则无法锁定 recipe 和 package 的 revision"package_id" 字段,且该 ID 应与你期望的配置(如 shared=True)严格对应"graph_lock" 下的 "nodes" 数量应与预期依赖层级匹配;若突然多出一个 node(如 zlib/1.3.1),说明某个间接依赖升级了,需查清来源注意:conan.lock 是 JSON 格式,但它是 Conan 内部格式,**不要手动编辑**——任何手改都会破坏校验和,后续 conan install --lockfile 会直接报错 Lockfile corrupted。
典型 CI 脚本里,lockfile 不是“可选优化”,而是强制环节。推荐流程如下:
conan profile detect --force # 确保 profile 与当前环境一致 conan lock --profile:build=default --profile:host=default --lockfile-out=conan.lock conan install . --lockfile=conan.lock --build=missing
关键约束:
--lockfile-out 显式指定输出路径,避免意外覆盖其他 lockfileconan install 必须带 --lockfile 参数,否则忽略 lockfile,退化为普通解析conan-debug.lock),并用 --lockfile 显式指定最常被忽略的一点:Conan 2.0 默认启用 revisions,但某些私有 Artifactory 仓库若未开启 “Enable Conan Revisions” 选项,会导致 lockfile 中的 revision 字段为空或不一致——务必确认远程仓库配置与本地 con 匹配。