Conan无法自动解决MSVC运行时不一致，因其默认不启用compiler.runtime setting，故无法识别/MT与/MD差异；需显式声明该setting并配置profile，同时确保CMake正确读取且外部依赖（如vcpkg库）与之匹配。

Conan 为什么无法自动解决 MSVC Runtime 不一致

Conan 本身不修改编译器选项，它只传递 settings 和 options 并据此选择二进制包。而 MSVC 运行时库（/MT vs /MD）属于编译器级配置，不在 Conan 默认的 settings 维度里——build_type（Debug/Release）是 settings，但 runtime（MT/MD）不是。所以即使你本地工程设了 MD，Conan 拉下来的依赖若用 MT 编译，链接时照样报 RuntimeLibrary 不匹配。

让 Conan 识别并约束运行时：必须启用 compiler.runtime setting

MSVC 下需显式启用 compiler.runtime 这个 setting，否则 Conan 完全“看不见”运行时差异。操作分两步：

• 在 conanfile.py 或 conanfile.txt 中声明：settings = "os", "arch", "compiler", "build_type", "compiler.runtime"
• 在 profile 文件（如 win-msvc-md）中写明：

  [settings]
  os=Windows
  arch=x86_64
  compiler=msvc
  compiler.version=193
  compiler.runtime=dynamic
  compiler.runtime_type=Release

  注意：compiler.runtime 取值为 static 或 dynamic；compiler.runtime_type 控制 Debug/Release（对应 MTd/MDd 或 MT/MD）

CMake + Conan 联动时，MSVC_RUNTIME_LIBRARY 必须与 profile 对齐

Conan 传给 CMake 的只是变量，最终是否生效取决于 CMakeLists.txt 是否读取并应用。常见漏点：

Conan 2.31.2

Conan 2.31.2 官方历史源码包，适合复现依赖解析、CMake 配置、二进制包兼容性和跨平台构建环境。

下载

• 没在 CMakeLists.txt 中调用 conan_basic_setup() 或等价逻辑（如 find_package(conan)），导致 Conan 设置的 CMAKE_MSVC_RUNTIME_LIBRARY 未被加载
• 手动覆盖了 MSVC_RUNTIME_LIBRARY，比如写了 set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded")，硬编码成 MT，和 profile 里的 dynamic 冲突
• 使用 Ninja Multi-Config 生成器时，CMake 不会自动根据 --config Release 切换 runtime，必须靠 Conan 的 compiler.runtime setting 驱动

vcpkg 或预编译第三方库混入时最危险

Conan 管不到 vcpkg、NuGet 或手动下载的 .lib/.dll。它们若用不同 runtime 编译，就会成为“静默冲突源”。典型现象：

• Conan profile 设的是 dynamic，但你链接了 abseil 的 .lib（内部用 /MT 编译），链接时报 MT_StaticRelease 不匹配 MD_DynamicRelease
• 错误发生在某个 .obj 文件里（如 grpc.pb.obj），但你根本没在 Conan 里声明 grpc —— 它来自外部静态库
• 解决办法只有两个：重编译该库，用和主工程一致的 compiler.runtime；或彻底弃用它，改用 Conan 管理的版本（如 abseil/20250127）

真正麻烦的从来不是 Conan 配置本身，而是你无法控制的二进制依赖是否和你的 runtime setting 形成闭环。一旦漏掉一个，整个链就断在链接阶段。