conan 通过 build_type setting 驱动整个依赖图自动匹配 debug/release 二进制，而非手动切换；build_type 参与 package id 计算，导致 debug 与 release 包完全隔离、不可混用，错配时链接失败而非静默降级。
Conan 切换 Debug/Release 依赖不是“手动换包”，而是靠 build_type setting 驱动整个依赖图自动匹配——错配时链接失败，不是静默降级。
为什么 conan install 加了 --settings build_type=Debug 还链接到 Release 库？
常见错误是 CMake 构建类型和 Conan 的 build_type 不一致。比如你在命令行用 --settings build_type=Debug 安装了依赖，但 CMake 没启用调试符号或优化开关，或者用了 -DCMAKE_BUILD_TYPE=Release，结果链接器会优先找 Release 版本的库（尤其在 Windows MSVC 多配置下），导致 LNK2038 或 LNK2005 错误。
- Linux/macOS（单配置生成器如 Ninja）：必须保证
-DCMAKE_BUILD_TYPE=Debug和--settings build_type=Debug完全对齐 - Windows MSVC（多配置生成器如 Visual Studio）：CMake configure 阶段不指定构建类型，而是在 build 阶段用
--config Debug，同时conan install必须用--settings build_type=Debug - 检查是否误用了
CMakeDeps但没在CMakeLists.txt中调用find_package(... CONFIG)——否则 CMake 可能 fallback 到系统路径下的 Release 库
build_type 怎么影响 package ID 和二进制选择？
build_type 是 Conan 的核心 setting，天然参与 package ID 计算。这意味着：zlib/1.2.13 的 build_type=Debug 和 build_type=Release 是两个完全不同的二进制包，ID 不同、缓存路径不同、不能混用。
- 执行
conan install . -s build_type=Debug后，Conan 会查找或构建 ID 包含build_type-Debug的 zlib 包 - 远端仓库若没有对应二进制，
--build=missing才会触发源码编译；否则直接报错“package not found”，不会自动退到 Release - 本地已有 Release 包，但你运行 Debug 安装命令，Conan 会新建一个 Debug 子目录（如
~/.conan2/p/zlib/...下不同 hash 路径），互不干扰
如何验证当前安装的依赖确实是 Debug 版本？
不能只看命令参数，得查实际产物。最直接的方式是检查生成的 CMakeDeps 文件内容或依赖库的符号信息。
- 打开
build/conan_deps.cmake（或类似命名），搜索set(fmt_BUILD_TYPE "Debug")或set(zlib_BUILD_TYPE "Debug") - 在 Windows 上用
dumpbin /headers path\to\zlibd.lib，看是否有debug字样；Linux/macOS 用file libz.so或nm -C libz.a | grep "_Z.*assert"看是否含调试相关符号 - 运行
conan list "*" -r=all --graph=graph.json，再用jq '.graph.nodes[] | select(.name=="zlib") | .context, .settings.build_type'查看节点实际解析出的build_type
真正容易被忽略的是：Conan 的 build_type 不仅控制你自己的构建，也强制约束所有传递依赖——哪怕某个中间库（比如 openssl）内部没显式处理 _DEBUG 宏，只要它声明了 build_type setting，它的二进制就按该类型打包，且无法被上层“覆盖”。一旦某层依赖缺失 Debug 二进制，整个链就断在那一步。
