我不记得这个答案的来源了(我想我是在互联网上的一个。ppt中找到的)，但答案很简单。

一个库和一个框架是一组类，模块和/或代码(取决于编程语言)，可以在你的应用程序中使用，并帮助你解决特定的“问题”。

这个问题可以是在应用程序中记录或调试信息、绘制图表、创建特定的文件格式(html、pdf、xls)、连接到数据库、创建应用程序的一部分或完整的应用程序或应用于设计模式的代码。

你可以有一个框架或一个库来解决所有这些问题，甚至更多，通常框架帮助你解决更复杂或更大的问题，但这只是它们主要区别的连续，而不是两者的主要定义。

库和框架之间的主要区别是它们自己的代码之间的依赖关系，换句话说，你要使用框架 需要使用FW中几乎所有的类、模块或代码 类中的一个或几个类、模块或代码 Lib在您自己的应用程序中

这意味着，如果一个框架有50个类，为了在你需要使用的应用程序中使用框架，比如说，在你的代码中有10-15个或更多的类，因为这就是设计框架的方式，一些类(类的对象)是框架中其他类的方法的输入/参数。请参阅. net框架、Spring或任何MVC框架。

但是以一个日志库为例，你可以在你的代码中使用一个log类，并帮助你解决“日志问题”，这并不意味着日志库在他的代码中没有更多的类，比如处理文件的类，处理屏幕输出，甚至数据库，但你永远不会在你的代码中接触/使用这些类，这就是为什么它是一个库而不是一个框架的原因。

还有比框架和库更多的类别，但这是跑题了。

我会像你五岁一样解释。(没有使用编程术语。)

让我们想象一下，你不久前在你的城市开了一家汉堡店。但是作为初学者，你会觉得做汉堡太难了。你在想一种为顾客做汉堡的简单方法。 有人告诉你，如果你使用框架，你可以很容易地做bugger。你要知道有麦当劳汉堡框架和汉堡王汉堡框架。

如果你使用麦当劳汉堡框架，做巨无霸汉堡就很容易了。(但你不能做皇堡。)

如果你使用汉堡王汉堡框架，就可以很容易地做出皇堡。(但是你不能做巨无霸)

不管怎样，最后，它们都是汉堡。这里很重要的一点是，你必须遵循他们的框架规则来做汉堡。否则，你会觉得更难完成或者根本无法完成。

你也听说过有一种叫做简单汉堡-帕蒂图书馆的东西。

如果你使用这个库，你可以很容易地做出任何汉堡肉饼(X2速度)。 使用麦当劳汉堡框架还是汉堡王汉堡框架并不重要。 无论哪种方式，您仍然可以使用这个简单汉堡-帕蒂库。(即使你没有框架也可以使用这个库。)

你现在看到框架和库的区别了吗?

一旦你开始使用麦当劳汉堡框架。要切换到汉堡王的汉堡框架并不容易。既然你要把整个厨房都换了。

如果您开始使用Java Spring框架构建Web应用程序，那么稍后将很难(也许不可能)更改为Ruby on Rails框架。

但是Library，换别人会容易得多。或者你可以不用它。

你的解释听起来不错。库可以是任何经过编译和自包含的东西，以便在其他代码中重用，实际上对其内容没有任何限制。

另一方面，框架应该具有一系列用于应用程序开发的特定领域的功能，就像您的示例MVC一样。

什么是图书馆?

库是代码块的集合(可以是变量、函数、类、接口等形式)，由开发人员构建，以简化其他发现其相关性的开发人员的软件开发过程。

什么是框架?

参考库的定义，我们可以将框架定义为一种工具，通过在受控的开发环境中为开发人员提供必要的库，帮助开发人员解决大量特定于领域的问题。

这是我的想法(其他人也对此进行了合理化解释):

库是包含在代码中的东西。框架是应用程序的容器。

实际上，这取决于你给术语下什么定义。可能有很多不同的定义。

我认为下面的解释是基于我认为这个术语指的是什么:

确定的图书馆

确定性库保存的函数是基于A)函数输入或b)在函数调用之间以某种方式维护的状态确定的。

如果将逻辑依赖注入确定性库，则该逻辑必须符合具体的规范，以便库的输出不受影响。

示例:一个碰撞检测库，由于某种原因依赖于排序函数来帮助这些计算。这个排序函数可以配置为优化目的(例如通过依赖注入，编译时链接等)，但必须始终符合相同的输入/输出映射，以便库本身保持确定性。

非命定论的图书馆

一个非确定性库可以通过与它以某种方式访问的其他外部非确定性库通信来保存非确定性函数。

我通常将不确定性库称为服务。

示例:依赖于随机数字生成器服务来洗牌的扑克库。这可能是一个不好的例子，因为出于架构的目的，我们应该将这个库的不确定性方面推到外部。相反，通过采用预先洗牌的牌组，扑克库可以变得具有确定性和单元可测试性，现在这个库的用户有责任随机洗牌，如果他们愿意的话。

框架

框架介于确定性库和非确定性库之间。

任何依赖注入框架的逻辑在该函数实例的生命周期内都必须是确定的，但是不同逻辑的不同函数实例可以被注入到框架函数的单独执行中。

Example: Functions that operate on lists such as map, filter, sort, reduce, that expect to take in functions that are deterministic but can have varying logic for different executions. Note that this requirement only exists if these list operations advertise themselves as deterministic. In most languages, list operations wouldn't have this constraint. The core logic of such frameworks are deterministic, but are allowed to accept indeterministic logic at the risk of the user. This is generally a messy scenario to deal with, because output can vary widely due to implementation details of the framework.