conan.lock文件是确保构建可重复性的关键，必须在生产发布和CI/CD中强制启用；它锁定settings与options快照，不同平台需各自维护独立锁文件，并通过--lockfile参数显式触发校验。
conan.lock 文件只在需要构建结果完全一致时才必须启用，不是所有项目都该默认开启。
生产发布和 CI/CD 流水线必须用 conan.lock
发布版本前打 tag、CI 触发构建、归档二进制包——这些环节一旦依赖版本浮动，就可能让线上行为与测试不一致。Conan 不会自动校验 conan.lock 是否过期，你得主动用 conan install . --lockfile 强制走锁定路径。CI 脚本里漏掉这个参数，等于白写锁文件。
- CI 中应校验
conan.lock是否被修改：比如git diff --quiet conan.lock || (echo "lockfile changed!" && exit 1) - 发布分支建议禁用
--build=missing，改用--build=never防止意外编译源码 - 私有远程仓库若未同步某包的特定 revision，
conan install会失败而非降级，这点比 vcpkg 更严格
跨团队协作时，conan.lock 是防“在我机器上能运行”的底线
当 A 同学在 macOS 上跑通，B 同学在 Windows + MSVC 下报链接错误，大概率是 conan.lock 没提交或没更新。Conan 的 lock 文件包含 settings（如 compiler.version）和 options（如 shared=True）的完整快照，不同平台生成的 lock 文件天然不兼容——不能共用一个文件，但每个平台都该有自己的 lock 文件并纳入 Git。
- 团队应约定 lock 文件命名规则，例如
conan.lock.windows、conan.lock.linux - 不要把
conan.lock加进.gitignore；但要避免把它放在conanfile.py同级又不区分平台 -
conan lock create默认不覆盖已有文件，需显式加--lockfile-out才能更新
开发阶段慎用全量锁定，优先用语义化范围 + 定期审计
每天 conan lock create 一次？没必要。开发中更常见的是“小步迭代”：用 fmt/[~10.2.0] 允许补丁升级，既防 breakage 又自动获取安全修复。等临近发布再生成最终 lock 文件。长期锁死所有依赖，反而会让 conan info . 查出一堆已知 CVE 却无法升级。
- 用
conan list "*/*@*/*" --graph=graph.json导出依赖图，配合工具扫描漏洞 -
conan lock create不会自动更新子依赖的版本范围，只基于当前conanfile.py解析；若子依赖本身用了波浪号，它仍可能引入新 revision - 锁文件里没有注释字段，别指望靠它记录“为什么选这个版本”——得靠 commit message 或
notes.md
最易被忽略的一点：conan.lock 不锁定 profile，也不锁定远程地址。同一份 lock 文件，换一个 profile 或切到另一个 remote，conan install 仍可能拉下不同二进制——它只锁定“解析结果”，不锁定“获取来源”。
