Profile 应纳入项目版本控制而非依赖本地自动生成配置，统一放在项目根目录 profiles/ 下（如 profiles/arm64-release），通过 CI 自动同步公司级模板并配合 conan.lock 锁定依赖图以确保构建一致性。
Profile 文件该放项目里还是全局共享？
Profile 必须按项目/团队维度统一维护，不能依赖 ~/.conan2/profiles/default 这类本地自动生成的配置。因为 conan profile detect 只读当前机器环境，CI 机器、新成员、交叉编译场景下必然不一致——你看到的“能跑”，往往只是某台机器上恰好匹配。
正确做法是把 Profile 当作构建脚本的一部分，和 CMakeLists.txt 一样纳入 Git 版本控制。路径建议统一放在项目根目录下的 profiles/ 子目录中，例如：profiles/arm64-release、profiles/x86_64-debug。
- 每个 Profile 文件名需体现关键维度：目标架构 + libc 类型 + 构建类型（如
arm64-glibc-release） - 文件内容禁止硬编码绝对路径（如
sysroot=/opt/sysroot-arm64），改用环境变量或 Conan 的conf配置项注入 - 避免在 Profile 中写
compiler.path；交叉编译器前缀（compiler.cppstd、compiler.libcxx）才应固化
如何让多个项目共用同一套 Profile？
Conan 本身不支持 Profile 的“继承”或“引用”，但可通过符号链接或构建脚本实现复用。最稳妥的方式是：在公司级工具仓库中集中存放 Profile 模板，各项目通过 CI 脚本或 Makefile 自动同步。
例如，在 infra/conan-profiles 仓库中维护标准 Profile，项目 CI 启动时执行：
git clone --depth=1 https://git.example.com/infra/conan-profiles profiles/ -b v2.3
这样既保证一致性，又避免每个项目手动复制粘贴出错。注意：--depth=1 防止拉完整历史拖慢 CI；-b v2.3 锁定语义化版本，防止上游变更破坏构建。
- 不要用
conan profile update动态改本地 Profile——它不可审计、不可回滚 - 若项目需微调（如仅改
build_type），应新建子 Profile（如arm64-release-with-ubsan），而非修改基线 - Profile 中的
[conf]段（如tools.cmake.cmaketoolchain:generator）可被 CMakeToolchain 读取，但不会影响 package ID，适合做生成器侧定制
Profile 和 conanfile.py 怎么协同避免配置漂移？
Profile 控制「用什么工具链编」，conanfile.py 控制「依赖怎么编」，两者必须对齐。常见漂移点是 build_type 和 compiler.version：Profile 里写了 build_type=Release，但 conanfile.py 中漏了 settings = "os", "compiler", "build_type", "arch"，Conan 就会退回到默认值，导致 Debug 依赖混入 Release 构建。
验证是否对齐的最快方式是运行：
conan install . -pr:h=profiles/arm64-release --dry-run
观察输出中每个依赖的 package_id 是否含 Release 字样；如果出现 UNKNOWN 或缺失维度，说明 conanfile.py 的 settings 声明不全。
-
conanfile.py中的settings是白名单，没写的维度不会参与 package ID 计算，也不会从 Profile 继承 - 交叉编译时，
-pr:h（host profile）决定最终产物 ABI，-pr:b（build profile）只用于构建工具链本身（如 protobuf 编译器），别混淆 - Profile 中的
compiler.libcxx必须与项目实际链接的 STL 一致；libstdc++11和libstdc++是不同 ABI，混用直接链接失败
为什么 Profile 改了 CI 却没生效？
最常被忽略的是 Conan 的缓存机制：Profile 只在 conan install 阶段读取，且一旦某个依赖已有匹配二进制，Conan 就跳过重新解析——哪怕 Profile 已更新。这不是 bug，是设计使然。
CI 中必须强制刷新依赖上下文：
- 加
--build=missing确保缺失包从源构建（适合首次或 Profile 大改） - 加
--lockfile=conan.lock并配合conan lock create更新锁文件（推荐长期策略） - 删掉
~/.conan2/p下对应包缓存（暴力但有效，适合调试）
真正可靠的方案是：Profile 变更 → 触发 conan lock create → 提交新 conan.lock → CI 用 --lockfile 安装。这样所有环境都基于同一份确定性依赖图，Profile 变更才真正落地。
