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

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

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

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

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

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

您应该仔细考虑随时间的变化、版本控制、稳定性、兼容性等。

如果有两个应用程序使用共享代码，您是否希望强制这些应用程序一起更改，以防它们需要相互兼容?然后使用dll。所有的exe都将使用相同的代码。

或者你想把它们彼此隔离，这样你就可以改变一个，并确信你没有破坏另一个。然后使用静态库。

DLL地狱是当你可能应该使用一个静态库，但你使用了一个DLL代替，并不是所有的前任都与它兼容。

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

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

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

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

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