不同MSVC运行时依赖库的动态链接安全时机及方案咨询

针对你的场景，动态链接的安全性核心取决于跨模块接口的隔离程度以及CRT运行时的交互方式，以下分情况说明：

通用安全前提 #

无论BLib选择/MD还是/MT，只要满足以下条件，动态链接就是安全的：

• 接口严格采用纯C-API：禁止在接口中传递任何STL对象（如std::string、std::vector）、CRT特定类型（如FILE*、_FILE*）或依赖CRT实现的结构体。
• 内存管理规则明确：跨模块传递的内存，要么由分配该内存的模块负责释放（比如BLib分配的内存只能通过BLib提供的函数释放），要么双方约定使用统一的内存分配函数（比如BLib暴露blib_malloc/blib_free供双方调用）。
• 避免跨模块抛出/捕获C++异常：不同CRT实例的异常处理机制可能不兼容，接口中应改用错误码返回。

不同BLib链接方式的安全情况 #

1. BLib使用/MT（静态链接CRT） #

这种情况下，BLib拥有独立的CRT实例，与AApp的动态CRT完全隔离，只要满足上述通用前提，动态链接完全安全。

• 注意：绝对不能出现跨模块操作CRT资源的行为，比如AApp用free释放BLib中malloc分配的内存，或传递std::string这类STL对象，否则会因堆不兼容导致崩溃。

2. BLib使用/MD（动态链接CRT） #

VS2019 16.7与16.8属于同一系列的小版本升级，其动态CRT库（如vcruntime140.dll、msvcp140.dll）是二进制兼容的，因此BLib用/MD链接时，会与AApp共享同一套动态CRT，这种场景下动态链接也是安全的。

• 部署注意：确保程序运行环境中带有兼容的CRT版本（建议使用BLib编译时的16.8版本CRT，它向下兼容16.7的调用）。

混合运行时的影响 #

• 当BLib用/MT、AApp用/MD时，属于典型的混合运行时场景，但只要接口严格隔离（不交叉操作CRT资源），就不会有问题——两个CRT实例各自独立运行，互不干扰。
• 当BLib用/MD时，与AApp的/MD属于同一种链接方式，共享CRT实例，不存在混合运行时的冲突风险，这种场景下内存管理的约束可以适当放宽（但仍建议遵循分配方释放的原则，避免潜在问题）。

内容的提问来源于stack exchange，提问作者ruhig brauner