库，通常是一种代码或其对应产品构件的交付形式。这意味着库的表现形式是多样的，例如可以是源代码的一种组织形式，也可以是由源代码编译成的二进制结果；它既可能是一些单元或模块的、有或没有规则的包装或集合，也可能是将某些“类”有序集中在一起的一个泛指。一些常见的形式包括：□在编译语言中，库可能用来组织代码，或翻译阶段中的中间代码。例如汇编语言中的库(.lib),就用于管理一些目标文件(.obj)的集合。

□在目标系统中，库可能用来指应用发布的一个组成部分。例如Windows中的动态链接库(.DLL)。

□在面向对象系统中，(类)库通常用来指一些类的集合，但并不表现这些类是以源码形式或是二进制形式提供。例如开源项目中的类库可能是源代码包，而NET的类库则是一些可以注册到系统中的、二进制的程序集(Assembly)。

□在应用环境例如操作系统中，库通常是指可在不同应用产品之间复用的运行期代码。例如COM库，或前面提到的动态链接库(.DLL)①。

①动态链接库也有动态加载和静态加载两种形式，前者是用户代码可以使用loadLibrary)等函数将该库装载到应用环境中，后者是指在编译期由编译器决定的、在应用运行的初始化阶段由操作系统负责装载的库。在Windows环境中，一个库是用于静态加载或动态加载，通常是由应用决定的—这也意味着它的发布与依赖也由应用来决定。

综合上述以及更多的应用环境，“库”通常都不是指代码本身的组织，而是指它们的交付，包括最终交付之前的某种阶段。yipindushu.com

“库”究竟以何种形式交付，以及包含何种内容交付，都取决于最终应用产品对未来交付形式的需求。换而言之，既然库是某个产品(在特定运行环境中)的构件，那么它必然满足该环境的要求和该产品的限制。例如：□如果产品以平台依赖的二进制共享文件发布，那么库可能以编译阶段的中间文件，或者执行阶段的依赖模块的形式提供，例如Pascal的*.tpu和*.bpl,或者delphi的*.bpk,C/C++的*.lib,以及.NET的程序集、COM组件等。

□如果产品设计为支持插件的，那么库将以动态链接库(DLL)的形式交付，例如Windows操作系统中的屏保(*.scr)、控制面板应用(*.cpl)、管理模块(*.msc)等，或者Photoshop中的特效插件(*.8bf),这些其实都是修改了文件扩展名的动态链接库。

□如果产品设计为动态资源的，那么库将以资源包的形式交付，例如Android开发中的*-res.apk文件，通常就是作为某个主应用程序的资源包来提供的，这样便于提供同一个应用程序的不同国家/地区的版本。

□如果产品设计为支持动态脚本的，那么库将以源代码包或脚本库的形式交付，例如Mozilla Firefox的*xpi插件，本身就是一个.zip文件包，其内容则是一些javascript脚本及其依赖的资源。

“库”作为交付物以及最终产品的一个组成部件来提供，也意味着它是具有版本信息的①。这种版本信息与交付产品的版本相关，例如不能直接将用于MozillaFirefox 3的插件直接应用于Mozilla Firefox 6,而这一限制是作为版本信息(install.rdf文件)包含在插件中一起交付的。

然而作为一个完整的交付物，应用产品可能是一个不带有任何“库”的独立程序(例如Windows环境中的.exe文件),也可能带有更为丰富的产品信息，例如包括：□产品依赖的操作系统或主程序版本，例如Firefox插件中的install.rdf文件；□自身基于的运行库，例如VC的Runtime库vcredist_x86.msi;□与此前的发布版本的冲突或依赖，例如配置文件检查或修复；□当前产品版本发布时附带的完整库、文件或资源，例如文件清单；□当上述依赖缺失时，可能的获取渠道，例如ActiveX组件的codebase;□产品文档或相关信息，例如readme.txt、帮助文件或在线帮助的网址链接。

①版本也是导致“DLL地狱”(DLL Hell)问题的根源之一。所谓“DLL地狱”,是指在同一执行环境的不同软件产品中，由于使用了同名但版本不同的DLL而导致的冲突。这一问题并非WindowsDLL或Linux Library所特有。不同的库，在解决这一问题的策略上不尽相同，但大体上都是以“声明版本依赖关系”为基本思路。

通常应用程序开发的集成环境(或某些推荐性的套件、开发工具组合)会提供一系列的方式来生成上述的产品内容①,最后将这些文件打包并提供某种统一、便捷的安装方式。这些最终可以由“用户”在其机器环境下自主使用的交付物，在商业意义上称为“产品”,而在程序世界中，通常就称为“包”2。

综上所述，我们将库(library)与包(package)作为产品交付形式相关的两个组织方法