conan profile中compiler字段应填gcc、clang或msvc等标准编译器名称，而非路径或ide名；需配套填写compiler.version和compiler.libcxx以确保package id匹配与二进制兼容。
conan profile里compiler字段填什么
填你实际用的编译器名称，不是安装路径，也不是IDE名。Conan靠这个字符串匹配预编译包、决定构建参数、校验依赖兼容性——填错就拉不到二进制，或编译失败。
常见值直接写：gcc、clang、msvc，注意大小写和拼写。比如不能写 GCC 或 MinGW（后者是工具链名，不是compiler值）。
-
gcc：对应 MinGW-w64、Linux GCC、macOS Homebrew GCC；别写g++—— Conan 没这个 compiler 类型 -
clang：macOS 默认 Clang、Linux 上 llvm 链接的 clang++；别写apple-clang（那是旧版 v1 的写法，v2 已统一为clang） -
msvc：Windows 上 Visual Studio 的 cl.exe；别写visual studio或vs2019
compiler.version 和 compiler.libcxx 必须配套填
只填 compiler=gcc 不够，Conan 会按完整 settings 元组生成 package ID。漏掉或错配 compiler.version 和 compiler.libcxx，会导致“找不到包”或链接失败。
例如用 GCC 12 编译，但 profile 写成 compiler.version=11，Conan 就去远端找 GCC 11 编译的 zlib，而不是你本地能用的 GCC 12 版本。
- Linux GCC：
compiler.version=12+compiler.libcxx=libstdc++11（C++11 起默认） - macOS Clang：
compiler.version=15+compiler.libcxx=libc++（Clang 默认用 libc++） - MSVC：
compiler.version=193（对应 VS 2022 17.3），不用填 libcxx —— MSVC 没这选项
profile detect 自动生成的值不一定能直接用
conan profile detect 在多数情况下能识别出基础 compiler 名，但它不会猜你的真实意图。比如它可能把 MinGW-w64 识别为 gcc，但没填 compiler.version，或者把 macOS Clang 识别成 apple-clang（v2 不认这个）。
建议执行后立刻检查：
conan profile show default
如果看到 compiler=apple-clang，手动改成 compiler=clang；如果 compiler.version 是空或明显不对（如显示 14.0.0 却实际是 Clang 15），就得编辑 profile 文件修正。
编辑命令：conan profile update settings.compiler.version=15 default
交叉编译时 compiler 填的是目标平台编译器，不是宿主机的
比如你在 x86_64 Linux 上编译 ARM 程序，profile 里 os=Linux arch=armv8，那 compiler 仍填 gcc，不是 aarch64-linux-gnu-gcc —— 后者是 [buildenv]CC 该管的事。
Conan 的 compiler 字段只表达“语义类型”，不表达路径。路径由 [buildenv]CC/CXX 或 [conf]tools.cmake.cmaketoolchain:user_toolchain 控制。
填错的典型症状：conan install 成功，但 CMake 报 Unknown compiler 或链接时找不到 libstdc++.so —— 因为 toolchain 以为你在用 GCC，但实际调的却是 Clang 的 lib。
真正容易被忽略的是：compiler 设置一旦写进 profile，就会参与所有依赖的 package ID 计算。改一个字符，整个依赖图的二进制缓存就失效。调试时别只盯着 CMakeLists.txt，先确认 conan profile show 输出和你 conan install 用的 profile 完全一致。
