我给出一个一般的经验法则，如果你有一个很大的代码库，所有的代码库都建立在较低层次的库(例如Utils或Gui框架)之上，你想把它们划分成更易于管理的库，然后让它们成为静态库。动态库实际上不会为您带来任何东西，而且惊喜也更少——单个实例只有一个实例。

如果你有一个完全独立于其他代码库的库(例如第三方库)，那么考虑将其作为一个dll。如果库是LGPL，由于许可条件，您可能无论如何都需要使用dll。

Static libraries are archives that contain the object code for the library, when linked into an application that code is compiled into the executable. Shared libraries are different in that they aren't compiled into the executable. Instead the dynamic linker searches some directories looking for the library(s) it needs, then loads that into memory. More then one executable can use the same shared library at the same time, thus reducing memory usage and executable size. However, there are then more files to distribute with the executable. You need to make sure that the library is installed onto the uses system somewhere where the linker can find it, static linking eliminates this problem but results in a larger executable file.

c++程序的构建分两个阶段

编译——生成目标代码(.obj) 链接——生成可执行代码(.exe或.dll)

静态库(.lib)只是一个.obj文件的包，因此不是一个完整的程序。它还没有经历构建程序的第二个(链接)阶段。另一方面，dll类似于exe，因此是完整的程序。

如果你构建了一个静态库，它还没有被链接，因此你的静态库的消费者将不得不使用与你使用的相同的编译器(如果你使用g++，他们将不得不使用g++)。

如果相反，您构建了一个dll(并且正确地构建了它)，那么您已经构建了一个所有消费者都可以使用的完整程序，无论他们使用哪种编译器。但是，如果需要跨编译器兼容性，则从dll导出有几个限制。

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

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

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

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

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

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

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

真正的权衡(在一个大型项目中)是在初始加载时间，库将在某个时间被链接，必须做出的决定是链接是否需要足够长的时间，以至于编译器需要咬紧牙关并提前完成，还是动态链接器可以在加载时完成。