conan.lock是依赖图精确快照，必须提交至git并配合固定profile使用，否则本地与ci无法保证二进制级一致；ci需用--lockfile --build=never复用，本地修改conanfile或profile后须更新lockfile并提交。
本地和 CI 必须用完全一致的 profile + conanfile + lockfile，否则不是“同一套依赖”，只是“看起来一样”
conan.lock 文件必须提交进 Git
Conan 的 conan.lock 是依赖图的快照，记录了每个包的 exact revision、settings、options 和二进制 ID。没有它，conan install 每次都可能拉取新版本或重新构建——哪怕 conanfile.txt 没变。
- CI 启动时先运行
conan install . --lockfile=conan.lock --build=never，强制复用 lock 中的二进制 - 本地开发中，只要改了
conanfile.txt或 profile，就必须重新运行conan install . --build=missing并提交更新后的conan.lock - 不要把
conan.lock加进.gitignore；也不要手动生成或编辑它
profile 不能靠 conan profile detect 自动推断
CI 环境（如 GitHub Actions 的 ubuntu-latest）和你本地机器的编译器路径、默认 stdlib、甚至 compiler.version 都可能不同。自动检测出来的 profile 在两边大概率不一致。
- 在项目里放一个明确命名的 profile 文件，例如
profiles/linux-gcc12-release，内容固定：
[settings] os=Linux arch=x86_64 compiler=gcc compiler.version=12 compiler.libcxx=libstdc++11 compiler.cppstd=17 build_type=Release
- 本地和 CI 都显式指定它：
conan install . --profile:host profiles/linux-gcc12-release --lockfile=conan.lock --build=never - 避免用
--profile:build和--profile:host混用，除非你在做交叉编译；普通场景只用--profile:host
CMake 构建时必须继承 Conan 的 toolchain
很多人本地能过、CI 报链接错，是因为 CMake 自己选了 Release，但 Conan 安装时用了 build_type=Debug，导致找错库。CMake 不该自己猜配置，而应完全信任 Conan 生成的 conan_toolchain.cmake。
- 确保
CMakeLists.txt第一行project()之后就include()工具链文件，且路径与conan install的输出目录严格对应（比如build/Release/generators/conan_toolchain.cmake） - 删除所有硬编码的
-DCMAKE_BUILD_TYPE=...；让 Conan 的 toolchain 控制CMAKE_CXX_FLAGS、CMAKE_POSITION_INDEPENDENT_CODE等 - CI 中 CMake configure 命令里不要加
-DCMAKE_BUILD_TYPE，否则会覆盖 toolchain 设置
最容易被忽略的一点：Conan 的 settings（尤其是 compiler.version 和 compiler.libcxx）一旦写死在 profile 里，就决定了整个依赖图的二进制兼容性。换一个 patch 版本的 GCC，或者从 libstdc++ 切到 libstdc++11，都会产生全新 package ID——这意味着你得重新构建所有依赖，而不是复用缓存。
