Martin Fowler在他关于反转控制的文章中讨论了库和框架之间的区别:

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client. A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.

总结一下:你的代码调用一个库，而框架调用你的代码。

框架:安装在你的机器上，允许你与它交互。没有这个框架，你就不能向你的机器发送编程命令

库:旨在解决某一问题(或同一类别的若干问题)

工具包:许多代码片段的集合，可以在多个问题上解决多个问题(就像工具箱一样)

库只是将方法/函数打包到一个包中的集合，可以导入到代码项目中并重用。

A framework is a robust library or collection of libraries that provides a "foundation" for your code. A framework follows the Inversion of Control pattern. For example, the .NET framework is a large collection of cohesive libraries in which you build your application on top of. You can argue there isn't a big difference between a framework and a library, but when people say "framework" it typically implies a larger, more robust suite of libraries which will play an integral part of an application.

我认为工具包和SDK是一样的。它附带文档、示例、库、包装器等。同样，您可以说这与框架是相同的，您可能这样做是正确的。

它们几乎都可以互换使用。

简介

有各种各样的术语与相关代码的集合有关，它们具有历史意义(为了回答这个问题，1994/5年以前)和当前含义，读者应该意识到这两点，特别是在阅读历史时期关于计算/编程的经典文本时。

图书馆

无论是过去还是现在，库都是与特定任务相关的代码集合，或者是在大致相同的抽象级别上操作的密切相关的任务集。它本身通常没有任何目的或意图，目的是供客户端代码使用(使用)并与客户端代码集成，以协助客户端代码执行其任务。

工具包

Historically, a toolkit is a more focused library, with a defined and specific purpose. Currently, this term has fallen out of favour, and is used almost exclusively (to this author's knowledge) for graphical widgets, and GUI components in the current era. A toolkit will most often operate at a higher layer of abstraction than a library, and will often consume and use libraries itself. Unlike libraries, toolkit code will often be used to execute the task of the client code, such as building a window, resizing a window, etc. The lower levels of abstraction within a toolkit are either fixed, or can themselves be operated on by client code in a proscribed manner. (Think Window style, which can either be fixed, or which could be altered in advance by client code.)

框架

Historically, a framework was a suite of inter-related libraries and modules which were separated into either 'General' or 'Specific' categories. General frameworks were intended to offer a comprehensive and integrated platform for building applications by offering general functionality, such as cross platform memory management, multi-threading abstractions, dynamic structures (and generic structures in general). Historical general frameworks (Without dependency injection, see below) have almost universally been superseded by polymorphic templated (parameterised) packaged language offerings in OO languages, such as the STL for C++, or in packaged libraries for non-OO languages (guaranteed Solaris C headers). General frameworks operated at differing layers of abstraction, but universally low level, and like libraries relied on the client code carrying out it's specific tasks with their assistance.

“特定”框架在历史上是为单一(但通常是庞大的)任务开发的，例如工业系统的“命令和控制”系统，以及早期的网络堆栈，并在高抽象级别上操作，就像工具包被用于执行客户端代码任务。

目前，框架的定义已经变得更加集中，并以“控制反转”原则作为指导原则，因此程序流程以及执行都由框架进行。然而，框架仍然是针对特定的输出;针对特定操作系统的应用程序(例如MFC用于MS Windows)，或者更通用的工作(例如Spring框架)。

SDK:“软件开发工具包”

SDK是帮助程序员创建和部署代码/内容的工具集合，这些代码/内容非常明确地针对在非常特定的平台上运行或以非常特定的方式运行。SDK可以由一组库组成，这些库必须仅由客户端代码以特定的方式使用，并且可以正常编译，直到一组二进制工具，这些工具创建或调整二进制资产以产生其(SDK的)输出。

引擎

引擎(在代码集合术语中)是一个二进制文件，它将以某种方式运行定制的内容或处理输入数据。游戏和图像引擎可能是这个术语最普遍的用户，并且几乎普遍地与SDK一起使用，以针对引擎本身，如UDK(虚幻开发工具包)，但也存在其他引擎，如搜索引擎和RDBMS引擎。

An engine will often, but not always, allow only a few of its internals to be accessible to its clients. Most often to either target a different architecture, change the presentation of the output of the engine, or for tuning purposes. Open Source Engines are by definition open to clients to change and alter as required, and some propriety engines are fixed completely. The most often used engines in the world however, are almost certainly JavaScript Engines. Embedded into every browser everywhere, there are a whole host of JavaScript engines which will take JavaScript as an input, process it, and then output to render.

API:“应用程序编程接口”

The final term I am answering is a personal bugbear of mine: API, was historically used to describe the external interface of an application or environment which, itself was capable of running independently, or at least of carrying out its tasks without any necessary client intervention after initial execution. Applications such as Databases, Word Processors and Windows systems would expose a fixed set of internal hooks or objects to the external interface which a client could then call/modify/use, etc to carry out capabilities which the original application could carry out. API's varied between how much functionality was available through the API, and also, how much of the core application was (re)used by the client code. (For example, a word processing API may require the full application to be background loaded when each instance of the client code runs, or perhaps just one of its linked libraries; whereas a running windowing system would create internal objects to be managed by itself and pass back handles to the client code to be utilised instead.

Currently, the term API has a much broader range, and is often used to describe almost every other term within this answer. Indeed, the most common definition applied to this term is that an API offers up a contracted external interface to another piece of software (Client code to the API). In practice this means that an API is language dependent, and has a concrete implementation which is provided by one of the above code collections, such as a library, toolkit, or framework. To look at a specific area, protocols, for example, an API is different to a protocol which is a more generic term representing a set of rules, however an individual implementation of a specific protocol/protocol suite that exposes an external interface to other software would most often be called an API.

备注

As noted above, historic and current definitions of the above terms have shifted, and this can be seen to be down to advances in scientific understanding of the underlying computing principles and paradigms, and also down to the emergence of particular patterns of software. In particular, the GUI and Windowing systems of the early nineties helped to define many of these terms, but since the effective hybridisation of OS Kernel and Windowing system for mass consumer operating systems (bar perhaps Linux), and the mass adoption of dependency injection/inversion of control as a mechanism to consume libraries and frameworks, these terms have had to change their respective meanings.

附注(一年后)

After thinking carefully about this subject for over a year I reject the IoC principle as the defining difference between a framework and a library. There ARE a large number of popular authors who say that it is, but there are an almost equal number of people who say that it isn't. There are simply too many 'Frameworks' out there which DO NOT use IoC to say that it is the defining principle. A search for embedded or micro controller frameworks reveals a whole plethora which do NOT use IoC and I now believe that the .NET language and CLR is an acceptable descendant of the "general" framework. To say that IoC is the defining characteristic is simply too rigid for me to accept I'm afraid, and rejects out of hand anything putting itself forward as a framework which matches the historical representation as mentioned above.

有关非ioc框架的详细信息，请参阅(如上所述)许多嵌入式和微框架，以及语言中不通过该语言提供回调的任何历史框架(OK。对于任何具有现代寄存器系统的设备，回调都可能被黑客攻击，但普通程序员不会)，显然。net框架也是如此。

图

如果你是一个视觉学习者，下面的图表会让你更清楚:

(学分:http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks)

非常非常相似，框架通常比库更完善和完整，而工具包可以简单地是类似库和框架的集合。

这是一个非常好的问题，在本质上可能有一点点主观，但我相信这是我能给出的最好的答案。