如果您的库将在几个可执行文件之间共享，那么将其动态化以减少可执行文件的大小通常是有意义的。否则，一定要让它是静态的。

使用dll有几个缺点。装载和卸载它有额外的开销。还有一个额外的依赖关系。如果您更改dll使其与执行表不兼容，则它们将停止工作。另一方面，如果您更改了静态库，则使用旧版本编译的可执行文件将不会受到影响。

静态库必须链接到最终的可执行文件中;它成为可执行文件的一部分，并跟随它到任何地方。每次执行可执行文件时都会加载动态库，并以DLL文件的形式与可执行文件分开。

当您希望能够更改库提供的功能而不必重新链接可执行文件(只需替换DLL文件，而不必替换可执行文件)时，您将使用DLL。

当您没有理由使用动态库时，您可以使用静态库。

除了静态库与动态库的技术影响(静态文件将所有内容捆绑在一个大的二进制文件中，而动态库允许在几个不同的可执行文件之间共享代码)之外，还有法律影响。

例如，如果您正在使用LGPL许可的代码，并且静态地链接到一个LGPL库(从而创建了一个大的二进制文件)，那么您的代码将自动成为开源(自由)LGPL代码。如果您链接到一个共享对象，那么您只需要LGPL对LGPL库本身所做的改进/错误修复。

例如，如果你决定如何编译你的移动应用程序，这就成为一个更重要的问题(在Android中你可以选择静态和动态，在iOS中你不能-它总是静态的)。

库是绑定在应用程序可执行文件中的代码单元。

dll是可执行代码的独立单元。只有在对该代码进行调用时，才会在流程中加载它。一个dll可以被多个应用程序使用并加载在多个进程中，而在硬盘驱动器上仍然只有一个代码副本。

Dll优点:可用于多个产品之间重用/共享代码;按需装入进程内存，不需要时可卸载;可以独立于程序的其余部分进行升级。

Dll缺点:Dll加载和代码重基的性能影响;版本控制问题(“dll地狱”)

Lib优点:没有性能影响，因为代码总是在进程中加载，而不是重基;没有版本问题。

Lib缺点:可执行文件/进程“膨胀”-所有的代码都在你的可执行文件中，并在进程启动时加载;没有重用/共享-每个产品都有自己的代码副本。

在我们的项目中，我们使用了很多DLL(> 100)。这些DLL相互依赖，因此我们选择了动态链接的设置。然而，它有以下缺点:

启动慢(> 10秒) DLL必须进行版本控制，因为windows根据名称的唯一性加载模块。否则，自己编写的组件将得到错误版本的DLL(即已经加载的DLL而不是自己的分布式集) 优化器只能在DLL边界内进行优化。例如，优化器试图将经常使用的数据和代码放在彼此旁边，但这将不能跨越DLL边界

也许更好的设置是将所有内容都设置为静态库(因此您只有一个可执行文件)。只有在没有发生代码复制的情况下，这才有效。一个测试似乎支持这个假设，但我找不到MSDN的官方引用。例如，创建1个exe:

Exe使用shared_lib1, shared_lib2 Shared_lib1使用shared_lib2 shared_lib2

shared_lib2的代码和变量应该只在最终合并的可执行文件中出现一次。有人能支持这个问题吗?

静态库增加了二进制文件中代码的大小。它们总是被加载，无论你用什么版本的代码编译，都是将运行的代码版本。

动态库的存储和版本是分开的。如果更新被认为与原始版本二进制兼容，则有可能加载的动态库版本不是随代码附带的原始版本。

此外，动态库不一定被加载——它们通常在第一次调用时被加载——并且可以在使用相同库的组件之间共享(多个数据加载，一个代码加载)。

动态库在大多数时候被认为是更好的方法，但最初它们有一个重大缺陷(谷歌DLL地狱)，这个缺陷几乎被最近的Windows操作系统(特别是Windows XP)所消除。