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

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

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

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是一样的。它附带文档、示例、库、包装器等。同样，您可以说这与框架是相同的，您可能这样做是正确的。

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

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

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

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

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.

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

关于Mittag的正确答案:

一个简单的例子。假设您在一个类中实现了ISerializable接口(. net)。你利用了。net的框架特性，而不是库特性。你填上“白点”(就像mittag说的)，你就完成了骨架。你必须事先知道框架将如何“反应”你的代码。实际上。net是一个框架，这就是我不同意Mittag观点的地方。

你的问题的完整的答案在本书的第19章(整个章节都是关于这个主题的)中给出了，顺便说一下，这是一本非常好的书(完全不是“只是为了Smalltalk”)。

简介

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

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

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

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

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

图书馆

我认为库是已经编码的代码，您可以使用它，从而不必再次编码，这是一致的。代码的组织方式必须允许您查找所需的功能并从自己的代码中使用它。

大多数编程语言都带有标准库，特别是一些实现某种集合的代码。这是为了方便您不必自己编写这些代码。类似地，大多数编程语言都有构造，允许您从库中查找功能，例如动态链接、名称空间等。

因此，发现自己经常需要重用的代码是放入库中的好代码。

工具包

工具:用于特定目的的一套工具这是一致的。问题是，什么被认为是工具，什么不是。我想说没有固定的定义，它取决于自称为工具包的东西的上下文。工具的例子可以是库、小部件、脚本、程序、编辑器、文档、服务器、调试器等。

另一个需要注意的是“特殊目的”。这总是正确的，但是目的的范围很容易根据工具包的制作者而改变。所以它可以是程序员的工具箱，也可以是字符串解析工具箱。一个是如此广泛，它可以有工具触及所有编程相关的，而另一个是更精确。

sdk通常是工具包，因为它们尝试将一组工具(通常是多种类型的)捆绑到一个包中。

我认为常见的思路是，工具为您做了一些事情，要么是完全的，要么是帮助您做这些事情。工具箱只是一组工具，它们都执行或帮助您执行一组特定的活动。

框架

框架的定义并不一致。对于任何可以构建代码框架的东西，这似乎是一个通用术语。这意味着:任何构建或支持代码的结构。

这意味着您根据框架构建代码，而根据代码构建库。

But, it seems that sometimes the word framework is used in the same sense as toolkit or even library. The .Net Framework is mostly a toolkit, because it's composed of the FCL which is a library, and the CLR, which is a virtual machine. So you would consider it a toolkit to C# development on Windows. Mono being a toolkit for C# development on Linux. Yet they called it a framework. It makes sense to think of it this way too, since it kinds of frame your code, but a frame should more support and hold things together, then do any kind of work, so my opinion is this is not the way you should use the word.

我认为这个行业正试图将框架转变为一个已经编写好的程序，其中缺少你必须提供或定制的部分。我认为这是一件好事，因为工具箱和库是“框架”其他用法的非常精确的术语。

图

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

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

Barrass提供的答案可能是最完整的。然而，解释可以很容易地说得更清楚。大多数人忽略了一个事实，即这些都是嵌套的概念。所以让我告诉你吧。

编写代码时:

eventually you discover sections of code that you're repeating in your program, so you refactor those into Functions/Methods. eventually, after having written a few programs, you find yourself copying functions you already made into new programs. To save yourself time you bundle those functions into Libraries. eventually you find yourself creating the same kind of user interfaces every time you make use of certain libraries. So you refactor your work and create a Toolkit that allows you to create your UIs more easily from generic method calls. eventually, you've written so many apps that use the same toolkits and libraries that you create a Framework that has a generic version of this boilerplate code already provided so all you need to do is design the look of the UI and handle the events that result from user interaction.

一般来说，这完全解释了术语之间的差异。

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.