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

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

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.

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

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

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

关于Mittag的正确答案:

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

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

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.

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

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.

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