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

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

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

简介

有各种各样的术语与相关代码的集合有关，它们具有历史意义(为了回答这个问题，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框架也是如此。

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

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

我认为这有点主观。工具箱是最简单的。它只是一堆可以使用的方法和类。 库和框架的区别在于如何使用它们。很久以前，我在某个地方读到一个完美的答案。框架调用您的代码，但另一方面，您的代码调用库。

库和框架之间最重要的区别，实际上是定义性的区别是控制反转。

这是什么意思?好吧，这意味着当你打电话给图书馆时，你是在控制。但是对于框架，控件是反向的:框架调用您。(这就是所谓的好莱坞原则:不要给我们打电话，我们会给你打电话。)这就是框架的定义。如果它没有控制反转，它就不是一个框架。(我在看你，.NET!)

基本上，所有的控制流都已经在框架中，只有一堆预定义的白点，您可以用您的代码填写。

另一方面，库是您可以调用的功能的集合。

I don't know if the term toolkit is really well defined. Just the word "kit" seems to suggest some kind of modularity, i.e. a set of independent libraries that you can pick and choose from. What, then, makes a toolkit different from just a bunch of independent libraries? Integration: if you just have a bunch of independent libraries, there is no guarantee that they will work well together, whereas the libraries in a toolkit have been designed to work well together – you just don't have to use all of them.

但这只是我对这个术语的解释。与定义良好的库和框架不同，我不认为工具包有一个被广泛接受的定义。

Others have noted that .net may be both a framework and a library and a toolkit depending on which part you use but perhaps an example helps. Entity Framework for dealing with databases is a part of .net that does use the inversion of control pattern. You let it know your models it figures out what to do with them. As a programmer it requires you to understand "the mind of the framework", or more realistically the mind of the designer and what they are going to do with your inputs. datareader and related calls, on the other hand, are simply a tool to go get or put data to and from table/view and make it available to you. It would never understand how to take a parent child relationship and translate it from object to relational, you'd use multiple tools to do that. But you would have much more control on how that data was stored, when, transactions, etc.