静态链接与动态链接MFC项目维护差异及适配旧系统相关问题咨询

问题1：采用静态链接解决运行时依赖是否合理 #

在你的场景下该方案完全合理，核心原因如下：

• 你的用户群体无联网条件，无法通过在线安装必备组件的方式获取VC++ redistributable，静态链接直接将VC++运行时依赖打包到可执行文件内部，用户拿到程序可以直接运行，不需要额外安装步骤
• 替代方案是将对应版本的VC++ redistributable离线包整合到安装程序中，不需要用户联网，但仍然需要执行额外的运行时安装流程，静态链接对于单可执行文件的项目来说是更简便的方案
• 注意静态链接时的配置要求：VS2019默认工具集不支持XP目标，必须切换到v142_xp工具集，同时运行库选项选择多线程(/MT)（Release版本）或多线程调试(/MTd)（Debug版本，仅用于测试，不可分发），同时要确保所有依赖的第三方库也使用相同版本工具集、相同静态链接选项编译，避免出现符号冲突。

静态链接的弊端仅为可执行文件体积会增加数MB、同版本VC++开发的多个程序无法共享运行时内存，对于面向XP/2000旧设备的场景，这些影响几乎可以忽略。

问题2：静态链接与动态链接项目的维护差异 #

二者的维护差异主要集中在以下几个方面：

• 运行时更新适配差异
  动态链接的程序，用户只需要更新系统中安装的VC++ redistributable，就能获得运行时的漏洞修复、性能优化，不需要开发者重新编译程序；静态链接的程序如果要适配新版运行时，必须将整个项目+所有依赖库使用新版运行时重新编译，将新版运行时静态打包后才能推送给用户。
• VS版本/工具集升级适配差异
  动态链接项目升级VS版本时，只要用户设备安装了对应版本的VC++ redistributable就能正常运行，不同版本的VC++ redistributable可在系统中共存，冲突概率极低；静态链接项目升级VS/工具集时，必须保证所有依赖的第三方静态库、项目内所有模块都使用完全相同版本的工具集、完全相同的运行时链接选项编译，一旦出现不同工具集生成的静态库混链，很容易出现符号冲突、跨模块内存分配释放异常等问题，升级成本远高于动态链接项目。
• 多模块项目维护差异
  如果你的项目由多个exe、dll模块组成，动态链接模式下所有模块共用同一个运行时实例，跨模块传递STL对象、分配/释放内存都是安全的；静态链接模式下每个模块都会打包独立的运行时副本，跨模块传递内存指针、STL对象极易出现崩溃，需要额外增加大量编译约束，维护成本大幅提升。
• 分发限制差异
  微软的许可证禁止分发VC++ Debug版本的运行时，静态链接的Debug版程序本身包含Debug运行时，完全不能对外分发；动态链接的Debug程序仅在测试场景下需要对应Debug运行时，分发限制更少。

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