Conan 不支持统一 Debug/Release 包，因 build_type 是 settings，天然参与 package ID 计算，不同 build_type 生成独立二进制包；必须为每个 build_type 单独构建、上传与消费，确保依赖图中各节点严格对齐，否则将引发链接失败或运行时崩溃。
Conan 本身不支持“统一” Debug 和 Release 包 —— 它的设计原则是 不同 build_type 必须生成不同 package ID，对应不同二进制包。强行“统一”只会导致链接失败、符号缺失或运行时崩溃。你真正需要的不是“统一”，而是让 Debug/Release 构建在依赖图中各自走通、互不干扰、且可复现。
build_type 是 settings，天然参与 package ID 计算
Conan 2.x 中，build_type（如 Debug 或 Release）属于 settings，和 os、compiler、arch 并列。这意味着：
- 同一个 recipe，
conan create . -s build_type=Debug和conan create . -s build_type=Release会生成两个完全独立的包，ID 不同； - 这两个包在远程仓库里是并存的，不能覆盖或合并；
- 消费者指定
--settings build_type=Debug时，Conan 只会拉取build_type=Debug的那个包，不会“退而求其次”去用 Release 版。
常见错误现象：
- 编译通过但链接时报
LNK2019（Windows）或undefined reference（Linux），尤其是调试符号相关函数（如_CrtDbgReport）； - 程序在 Debug 下正常，Release 下崩溃，或反之 —— 往往是因为混用了不同
build_type的依赖（例如主工程 Debug，但某个依赖只提供了 Release 包）； -
conan install报错Cannot find a valid package，提示找不到匹配build_type=Debug的二进制。
正确做法：
- 所有依赖（包括你自己写的库）都必须为每个需要的
build_type单独构建并上传； - 使用 profile 显式固化
build_type，避免命令行漏传； - 示例 profile（
profiles/debug）：[settings] os=Windows arch=x86_64 compiler=msvc compiler.version=193 compiler.runtime=dynamic build_type=Debug
CMake 多配置（MSVC）下，--config 和 build_type 必须对齐
Visual Studio 和 Ninja Multi-Config 生成器一次生成多个配置，但 Conan 的 build_type 是单值的 —— 它描述的是 host context 的构建上下文，不是目标配置名。
关键点：
- 生成阶段（
conan install）不指定-DCMAKE_BUILD_TYPE，也不应指定； - 安装时必须用
--settings build_type=Debug（或对应 profile），确保 Conan 解析出的依赖是 Debug 版； - 构建时用
cmake --build . --config Debug，CMake 会自动从 Conan 生成的xxx-config.cmake中加载对应配置； - 如果你在
conan install时用了build_type=Release，但cmake --build --config Debug，就会链接 Release 库到 Debug 工程 —— 这是典型崩溃源头。
容易踩的坑：
- 在 VS 中右键项目 → “属性” → C/C++ → “常规” → “调试信息格式”设为
Program Database (/Zi)，但 Conan 依赖却是 Release 编译的（无调试信息），导致断点失效； -
CMakeDeps生成的xxx-debug.cmake文件被忽略，因为 CMake 没有按 config 加载逻辑读取它； - 使用
find_package(xxx CONFIG)但没传CONFIGS参数，CMake 默认找xxx-config.cmake（Release 路径），而不是xxx-debug.cmake。
本地开发时，如何避免反复 conan create Debug/Release 两遍
你不需要每次改代码都重打两套包。推荐分层策略：
- 对自己维护的库：用
conan build+conan export-pkg快速迭代；- 先
conan build . --build-folder=build-debug --settings build_type=Debug - 再
conan export-pkg . pkgname/1.0@user/channel --settings build_type=Debug --profile:build debug --profile:host debug
- 先
- 对第三方依赖（如
fmt、zlib）：直接从 ConanCenter 拉预编译包，它们已提供完整build_type矩阵； - 对CI 流水线：用脚本批量构建：
conan create . -s build_type=Debug --user=myteam --channel=stable conan create . -s build_type=Release --user=myteam --channel=stable
注意：conan upload 也必须带 --settings build_type=Debug，否则远端无法区分。
build_type 不是开关，而是构建契约的一部分。最容易被忽略的地方是：profile 里写了 build_type=Debug，但 CI 脚本里执行 conan install 时又额外加了 --settings build_type=Release —— 后者会覆盖前者，且毫无警告。这种覆盖不会报错，但会导致整个依赖图错配，问题往往延迟到链接或运行时才暴露。
