CI 中 Conan profile 必须用绝对路径且显式声明所有 settings：os、arch、compiler、build_type；禁用 -pr:b（除非交叉编译），避免 [conf] 滥用，确保可预测性。
CI 里 profile 必须用绝对路径，不能依赖 $HOME
CI 环境（比如 GitHub Actions、GitLab CI）的 HOME 往往是临时路径，且不同 job 甚至同一 job 的不同 step 可能指向不同目录。你写 ~/.conan2/profiles/linux-gcc-release，~ 展开后可能变成 /tmp/xyz 或 /home/runner，但 Conan 实际只在固定位置找 profile —— 它不会自动 fallback 到当前用户家目录下搜。结果就是 conan install -pr:h linux-gcc-release 报错：ERROR: Profile not found: 'linux-gcc-release'。
实操建议：
- 把 profile 文件直接放在项目根目录下，例如
conan/profiles/linux-gcc-release - CI 脚本中统一用绝对路径引用：
conan install . -pr:h $(pwd)/conan/profiles/linux-gcc-release - 避免用
conan profile detect自动探测——它依赖当前 shell 环境变量和编译器路径，在 CI 中不可靠，尤其当多个 GCC 版本共存时容易选错compiler.version
profile 里 settings 要显式写全，别省略默认值
Conan 2.x 对 settings 是严格匹配的：少写一个字段（比如漏掉 build_type），哪怕它有默认值，也会导致 package ID 计算不一致，进而找不到已构建好的二进制包。CI 流水线里常见现象是本地 conan install 成功，CI 却报 No remote binary packages found，根因往往就是 profile 缺了 build_type=Release 这一行。
实操建议：
- profile 必须包含全部 4 个基础
settings：os、arch、compiler、build_type - 不要依赖隐式默认值，例如
compiler.libcxx在 Linux 上必须明确写成libstdc++11或libc++，否则 CMake 工具链生成会出错 - 推荐用
conan profile show <profile_path>核对输出，确认所有字段都已展开且无<default>占位符
CI profile 别混用 host/build 双 context，除非真需要交叉编译
Conan 的 -pr:h（host）和 -pr:b（build）是为交叉编译设计的。但在绝大多数 CI 场景（x86_64 Linux 构建 x86_64 Linux 产物），你只需要 host profile。如果误加 -pr:b，而 build profile 里又没配好 compiler（比如写了 compiler=gcc 但没写 compiler.version），Conan 会静默 fallback 到不兼容的默认值，最终导致 CMakeToolchain 生成错误的 compiler_id，CMake configure 阶段直接失败。
实操建议：
- 普通 CI 构建只用
-pr:h，彻底不用-pr:b - 若真需交叉（如 ARM 嵌入式），确保 build profile 明确指定
os_build和arch_build，且与 CI runner 真实环境一致 - 检查
conan install --help输出，确认当前 Conan 版本是否默认启用双 profile 模式（2.25+ 默认关闭，但某些插件可能开启）
profile 的 conf 字段要克制，优先走 CMake 工具链参数
[conf] 段能覆盖 Conan 内部行为（比如指定 Ninja 生成器），但它属于“全局开关”，一旦写错会影响整个依赖图。CI 中最常踩的坑是写了 tools.cmake.cmaketoolchain:generator=Ninja，但项目 CMakeLists.txt 里又硬编码了 project(... VERSION ...) 且未适配 Ninja 的多配置特性，结果 conan build 报 CMAKE_BUILD_TYPE is not set。
实操建议：
- 除非必要，profile 里不要写
[conf]；CMake 相关配置优先通过-DCMAKE_BUILD_TYPE=Release或CMakeToolchain的variables控制 - 如果必须用
[conf]，只保留最小集，例如仅tools.cmake.cmaketoolchain:generator，删掉所有带tools.build前缀的项（它们已被废弃） - 验证方式：运行
conan install . -pr:h xxx --dry-run，看输出的CMakeToolchain文件里是否生成了预期字段
build_type 的显式声明和 profile 路径的绝对化，这两点一错，整个依赖解析链就断在第一步。 
