profile必须显式指定，不能依赖环境变量：conan不读取cc/cxx等shell变量，所有编译器路径、架构、libc、浮点模式须白纸黑字写入profile；必须用-pr:h显式加载，配合conan.lock共同锁定构建结果。
Profile 必须显式指定，不能依赖环境变量
很多人以为设了 CC 或 CXX 环境变量，Conan 就会自动用上——它不会。Conan 的 profile 是独立于 shell 环境的配置单元，所有编译器路径、架构、libc、浮点模式都得白纸黑字写进 profile 里，否则就 fallback 到默认值（比如 x86_64 Linux + system GCC），和你本地实际环境对不上。
常见错误现象：conan install 成功但链接失败，报 undefined reference 或 ABI mismatch；或者在 CI 上构建成功，本地却失败。
- profile 中必须明确写出
compiler.executable和compiler.executable.cpp，例如arm-linux-gnueabihf-gcc，不能只写gcc - 若用 sysroot，
sysroot路径要绝对、可访问，且和交叉工具链实际路径一致 - 避免在 profile 里写
compiler.version=system——它不解析真实版本，只是占位符，会导致 package ID 不稳定
用 -pr:h 显式绑定 host profile
Conan 2.x 默认只用一个 profile（host context），但很多人仍沿用旧习惯，直接跑 conan install . -s os=Linux 这类命令。这种写法把 settings 拆开传，既难复现，又容易漏项（比如忘了 compiler.libcxx），而且无法复用 profile 文件里的 [conf] 配置（如 CMake generator）。
正确做法是：所有构建维度统一收口到一个 profile 文件，并用 -pr:h 显式加载。
- profile 文件名建议带平台标识，例如
linux-x86_64-gcc12-release，而不是myprofile - 执行时固定用
conan install . -pr:h linux-x86_64-gcc12-release -if build - CI 和本地开发用同一份 profile，删掉所有
if [ "$CI" = "true" ]类条件分支
profile 不该包含用户路径，而应封装成可移植结构
直接把 /home/yourname/toolchains/arm64 写进 profile，等于把机器 ID 刻进构建逻辑里。一旦换人、换机器、进容器，路径就失效。
解决思路不是“路径写对”，而是“路径不写死”：
- 用 Conan 的
conf.tools.cmake.cmaketoolchain:generator等 conf 项替代硬编码路径 - 把 toolchain 文件统一放在项目根目录下
toolchains/，profile 里用相对路径../toolchains/arm64.cmake（Conan 支持以 profile 所在目录为基准解析相对路径） - 对必须外部注入的路径（如 SDK 根目录），改用
conan config set设置全局变量，再在 profile 里引用${TOOLS_ROOT}（需启用conan config set general.conan_home=...并确保所有环境一致）
Profile 和 lockfile 要一起提交，不能只存 profile
profile 定义了“想用什么”，但不保证“能拿到什么”。如果远程仓库里没有对应二进制，Conan 可能回退到源码构建，而源码构建行为又受 conanfile.py 中 configure() 和 requirements() 影响——这些细节 profile 管不了。
真正锁定构建结果的是 lockfile（conan.lock）。它记录了每个依赖最终解析出的 package ID、revision、remote 来源。
- 每次
conan install后，加--lockfile-out conan.lock生成锁文件 -
conan.lock必须和 profile 一起纳入版本控制（.gitignore 里删掉它） - 后续构建统一用
conan install . -pr:h xxx -if build --lockfile conan.lock，跳过依赖解析阶段
没锁文件的 profile，就像没地图的导航——方向是对的，但不知道下一秒会拐进哪条岔路。
