在我们的项目中，我们使用了很多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的代码和变量应该只在最终合并的可执行文件中出现一次。有人能支持这个问题吗?

如果你在嵌入式项目或专门的平台上工作，静态库是唯一的方法，而且很多时候它们编译到你的应用程序中不是那么麻烦。同时，拥有包含一切的项目和makefile会让生活更快乐。

如果库是静态的，则在链接时将代码链接到可执行文件中。这使您的可执行文件更大(如果您走动态路线)。

如果库是动态的，那么在链接时，对所需方法的引用将内置于可执行文件中。这意味着您必须发布可执行文件和动态库。您还应该考虑对库中代码的共享访问是否安全、首选加载地址以及其他事项。

如果你能接受静态库，那就使用静态库。

Ulrich Drepper关于“如何编写共享库”的论文也是一个很好的资源，详细介绍了如何最好地利用共享库，或者他所说的“动态共享对象”(DSOs)。本文主要讨论ELF二进制格式的共享库，但有些讨论也适用于Windows dll。

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

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

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

除了其他人提到的所有要点，我在特定的用例中使用静态库:

不允许我的终端用户访问一些通用库 我在我的代码中开发的。

换句话说，假设我的产品中有两个库，A和B。A使用B服务并依赖于它。但是B是一个通用库，包括许多可以单独使用的有用服务。为了避免我的终端用户直接从B中受益(他们应该为B的许可证付费!)，我通常将B编译为一个静态库，并将其直接放在a中。因此，B服务对a来说是完全私有的，最终用户不能使用。