conan.lock文件必须提交到git，否则无法保证依赖版本统一；conan 2.x虽具确定性解析能力，但缺失lock文件会导致不同环境解析出不同二进制，引发abi不兼容、跨平台构建不一致等问题。
conan.lock 文件必须 commit 到 Git
不提交 conan.lock，就不存在真正统一的依赖版本。Conan 2.x 的依赖解析是确定性的，但前提是 lock 文件存在且被复用。一旦缺失，conan install 会重新解析整个依赖树，哪怕 conanfile.txt 没变，也可能因远程仓库新增了 patch 版本（如 openssl/3.0.10 → openssl/3.0.11）而拉取不同二进制。
常见错误现象：
- 本地构建成功，CI 失败：CI 环境没 lock 文件，自动升了某个间接依赖的 patch 版本，触发 ABI 不兼容
- Windows 开发者和 Linux 构建机结果不一致：两者各自生成的 lock 文件里，
zlib对应的二进制 ID 不同（因 settings 差异），但若没共享 lock，就根本不是同一组二进制
实操建议：
- 每次修改
conanfile.txt或conanfile.py后，必须运行conan lock create .并提交新conan.lock - CI 流程中禁止使用
--build=missing以外的构建策略，且必须指定--lockfile=conan.lock - 团队内禁用
conan install --requires=xxx这类 ad-hoc 命令，避免绕过 lock
profile 必须显式指定，不能靠 detect
conan profile detect 生成的 profile 只适合单机开发，跨平台协作时它会把本地编译器路径、libc 版本甚至 CMake 路径硬编码进去，导致别人机器上直接报错 Compiler 'gcc' not found。
使用场景：
- 嵌入式交叉编译：ARM64 Linux 和 x86_64 macOS 开发者共用同一套
conanfile.py，但必须各自用--profile=profiles/arm64-release和--profile=profiles/macos-debug - 企业 CI：所有 job 统一加载
--profile=ci/gcc-12-armv8-release，该 profile 存在 Git 仓库中，内容不含绝对路径
实操建议：
- profile 文件用纯文本写，只保留
[settings]和必要[conf]，例如：arch=armv8、compiler=gcc、compiler.version=12，绝不要写compiler.path=/opt/gcc-12/bin/gcc - 用
conan profile new myprofile --detect仅作初稿，立刻人工删掉路径类字段 - 在
conan install命令中始终显式传参，不依赖CONAN_PROFILE_DEFAULT环境变量
requires 中避免裸版本号，优先用 semver 范围 + lock 固化
写 fmt/10.2.1 看似精确，但 Conan 默认启用 semver 兼容匹配（~10.2.1），实际可能解析成 fmt/10.2.3 —— 这本身没问题，但必须由 conan.lock 记录最终选中的版本，而非靠人眼判断。
性能与兼容性影响：
- 裸版本号（如
fmt/10.2.1）在 lock 文件中记录的是 exact version，无法享受 patch 升级带来的安全修复 - 用
fmt/[>=10.2.0 更灵活，但必须配合 lock，否则每次 install 都可能选新 patch
实操建议：
- 开发阶段用宽松范围（如
openssl/[>=3.0.0 ），快速获取安全更新 - 发布前运行
conan lock update conan.lock确保所有传递依赖都收敛到已验证组合 - 禁止在
requires中写latest或stable这类动态别名，它们无法被 lock 固化
CMakeToolchain + CMakeDeps 生成器必须配套使用
只用 CMakeDeps 而不用 CMakeToolchain，会导致 CMake 编译参数（如 -std=c++17、-march=armv8-a）和 Conan 包编译时实际使用的参数不一致，轻则链接失败，重则运行时 SIGILL。
容易踩的坑：
- 旧项目沿用
cmake_find_package生成器，它不控制 toolchain，CMake 自行推导标准库路径，常和 Conan 编译的boost二进制 mismatch - 在
CMakeLists.txt中手动 set(CMAKE_CXX_STANDARD)，却没同步到 Conan 的 toolchain，造成头文件和库 ABI 不匹配
实操建议：
- conanfile.txt 中必须同时声明：
[generators] CMakeDeps CMakeToolchain - CMakeLists.txt 开头第一行 include 就是
include(${CMAKE_BINARY_DIR}/conan_toolchain.cmake)，不要用find_package(XXX)前手动设置任何编译选项 - 检查生成的
conan_toolchain.cmake是否包含你期望的set(CMAKE_CXX_STANDARD "17")和set(CMAKE_SYSTEM_PROCESSOR "aarch64")
