build_type是package ID的硬性组成部分，决定二进制唯一性；它作为host context全局设定贯穿整个依赖图，必须在conan install、profile、CMake全链路严格对齐，否则导致链接失败或find_package解析错误。
build_type 是 package ID 的决定性维度之一
它不是“可选开关”，而是 Conan 包身份的硬性组成部分。同一个库（比如 zlib/1.3），build_type=Debug 和 build_type=Release 生成的二进制包 ID 完全不同，Conan 会当作两个独立包处理。你本地或远程仓库里可能同时存在两套二进制，但它们互不替代。
build_type 不是“传给依赖”的参数，而是 host context 的全局设定
你在 conan install 命令里加 -s build_type=Debug，或者在 profile 里写 [settings] build_type=Debug，本质是在声明：整个依赖图（从你的项目到所有 transitive 依赖）都要在这个构建类型下求解、拉取、链接。
- 如果远端没有
build_type=Debug的openssl/3.2二进制，Conan 默认不会退而求其次用 Release 版 —— 它会报错或按--build=missing从源码编译 Debug 版 - 如果你的 profile 设的是
build_type=Release，但 CMake 里却写了-DCMAKE_BUILD_TYPE=Debug，链接时大概率失败：头文件里可能有#ifdef NDEBUG分支，而二进制里没这些符号 - Windows 上用 MSVC 多配置生成器（如 Visual Studio）时，
build_type仍需在 profile 中固定为Debug或Release，不能留空；CMake 生成阶段不靠它，但conan install --config Debug阶段必须对齐
常见错误：把 build_type 当成“调试开关”乱切
有人在同一个 build 目录反复执行 conan install -s build_type=Debug 和 -s build_type=Release，结果发现 CMakeLists.txt 里 find_package 找不到库，或链接时报 undefined symbol。这不是 Conan bug，而是因为：
- 两次 install 写入的是同一组
CMakeDeps文件名（如zlib-config.cmake），但内容指向不同二进制路径，后一次覆盖前一次 - CMake 缓存里
zlib_DIR指向旧路径，而该路径下的zlib-config.cmake已被覆盖成新内容，导致 find_package 解析失败 - 正确做法是：Debug 和 Release 使用**分离的构建目录**，例如
build-debug/和build-release/
profile 里写 build_type=RelWithDebInfo 怎么办
可以写，但要注意：Conan 官方 settings 枚举只明确支持 Debug 和 Release；RelWithDebInfo 属于合法自定义值，但远端仓库（如 ConanCenter）几乎不会提供对应二进制 —— 你基本只能靠 --build=missing 自己编译。更现实的做法是：
- 开发调试用
build_type=Debug（保证符号全、无优化） - 交付测试用
build_type=Release+[conf] tools.build:compiler_args="-g"手动加调试信息 - 避免在 profile 里混用非标准
build_type，除非你完全掌控所有依赖的构建流程
