在 中，a 是一个，其中可以由用户代码表示，因此 - 。 一种构建 和 的方法。 A 是 a ，作为 a 的一部分，并且 。 may 、 、 code 、工具集和（API），它们带来了 or 的所有 to 。

在编程领域，软件框架是指为软件提供通用功能的抽象形式，这些功能可以由用户编写代码有选择地更改，以提供服务于特定应用的软件。 软件框架提供了构建和部署应用程序的标准方法。

软件框架是一种通用的、可重用的软件环境，它提供特定的功能作为更大的软件平台的一部分，以促进软件应用程序、产品和解决方案的开发。 软件框架可能包括支持程序、编译器、代码、库、工具集和 API，将所有这些组件组合在一起以支持项目或系统的开发。

有他们的钥匙：

框架和普通库在功能上有一些关键的区别：

of：在 a、in 或 in user 中，the 的流程不是 by the，而是 by the。

控制反转：与库或普通应用程序不同，在框架中，应用程序的宏观控制流程不是由调用者决定，而是由框架本身决定。

：用户可以通过 ; 或者可以将用户代码添加到 .

可扩展性：用户可以扩展框架——通常通过选择性重写（）或由程序员添加专门的用户代码来提供特定的功能。

non- code_： 中的代码不是 ，而用户- 。 换句话说，用户可以访问 ，但不能访问其代码。

不可修改的框架代码：通常，框架代码不打算由您修改，而是接受用户自己实现的某些扩展。 换句话说，用户可以扩展框架，但不应该修改其代码。

用一个比喻（但不够严谨）来说，框架就是一条生产线，有很多工人（代码）在这条生产线上工作。 生产线经理（程序员）负责管理这条生产线。 比如有些流程是空的，那么你可以安排自己的工人进去，让他们实现你的目标。 某些流程中的工人所做的工作与您预期的不同。 您也可以安排自己的工人来代替他们。

但无论怎样，你的工人除了执行你的意志之外，还必须遵守那个流程的强制性要求。 他想偷工减料或者偷工减料他都做不到，因为流水线的下一道工序可能会有加班检验或者质量检验。 如果出了问题，流水线会直接给你停下来。 即使是一些强制检查，你作为管理者也没有权利忽视。

可想而知，一条好的生产线的价值有多大。 生产线不仅仅是一套机器。 它是多年管理经验的结晶。 这些才是最有价值的。 不然的话，光这些机器能值多少钱呢？ 有了生产线，对工人（代码）的要求大大降低，甚至对管理人员（程序员）的要求也大大降低。 当然，如果你只是想生产“耐磨”的鞋子，那么这条生产线几乎没有什么附加值，甚至可能会增加你的成本。 但如果你想生产出“高品质”的鞋子，那么这条生产线就是根本保证，别人的鞋子能卖10块钱，你的鞋子能卖到1000块钱。

一般来说，建立生产线的目的是建立规则、保证质量，以较低的成本复制高质量。 框架也是如此。

从代码结构来看，框架在宏观层面采用了注册和回调机制。 这个机制有一个形象的名字，叫做好莱坞规则。 为什么叫好莱坞规则？ 因为好莱坞想要出名的演员太多了，他们都想找导演。 长此以往，导演的工作效率必然会受到严重影响。 于是导演制定了一个“规则”：别打电话给我们（Don't call us），等我们打电话给你（We'll call you!）。 由于这个call和程序调用的call是同一个字，所以编程界把这句话搬了过来，成为了()的形象代言人。

例如，在Java框架中，只需要给一个类添加@注解，它就会自动作为服务进行管理。 当认为有必要时，将创建该类并将其实例传递给请求者。 中国也是如此。 只要给一个类添加@注解（装饰器），它就会自动作为一个组件来管理。 当认为有必要时，将创建该类并将其实例传递给请求者。 （例如路由器）。

这些注释还可以携带一些附加信息，称为元数据。 所谓“元数据”是指关于数据的数据。 这不是一个自我发明的术语。 它已在其他编程领域使用了数十年。 当准备创建组件时，它会找到这些元数据，找出这个组件的模板（因为组件本身是一个纯类，不携带任何模板信息），然后相应地操作DOM。

你编写的组件类和模板实际上是“程序员添加特殊的用户代码来提供特定的功能”，因为框架并不关心你的组件的外观和逻辑。 它唯一关心的是你必须按照它的规范工作，否则它会给你一个错误（例如，“你连模板都没有，你怎么敢称自己为组件？”）。

库与框架相反。 从宏观上看，它正在等待你的调用。 它会给你任何你想要的功能。 然后你调用这个函数并传入所需的参数，而不是要求你遵循它的许多规则。 所以你是自由的，但你也对整个事情负责。 你必须创建组件、创建服务等，自己驱动整个流程，并自己做必要的检查。 当然，您不必这样做。 反正别人可能只希望穿一个月十块钱的鞋。

那么，问题是，框架会比库更先进吗？ 显然不是，即使是框架也不一定比库有更多的功能。 他们只是定位不同，设计理念不同。 对于你来说，它会更愿意你遵守一些规则，这样当系统需要长期维护甚至经历多次人事变动时，它才不会变得腐败。 它希望每个开发人员都能做好自己的工作，而不必了解整个应用程序（因为有当前流程的操作手册和检查点）。 当然，它不会去干涉那些它不需要关心的事情。 例如，它并不关心你在组件模板中放入 h1 还是 div。 这些目标也可以利用图书馆来实现，但对人员的建筑观和做事自律会有相应的要求。 毕竟无人管，不能放过。

但现实中，很多应用的整个生命周期可能不会超过一年，甚至有很多活动页面的生命周期长达几天。 因此，这些应用程序和页面的可维护性实际上并不重要，甚至是否可以让不同的人进行协作并不重要。 这么多的功能，会出现什么样的bug呢？ 一次性需求的可扩展性怎么样？ 这时，学习成本就会成为一个非常重要的参考因素。

学习中最困难的部分是遵循和理解规则。 然而，大多数人自然不愿意遵守规则，尤其是一些他们可能不明白为什么的规则（尽管这可能是前人根据血的教训总结出来的）。 然而，一旦你遵守并理解了这些规则，一扇新的大门就会向你敞开。 踏入这个层次之后你会发现，前端技术、后端技术或者移动技术都遵循很多相同的概念。 ，即使出现新的挑战，你也可以应用这些概念来解决它们。

规则就是自由。 孔子把“随心所欲，不逾矩”作为自己最好的境界。 事实上，很多事情都是如此。 一旦深入理解了设计和使用框架的思维模型，你就会迎来实质性的提升。

工作的前五年，我编程的时候非常“聪明”，用技巧解决了很多问题。 但在接下来的十五年里（恰好是我学习框架概念的那一年），我爱上了规则。 我不仅为自己制定了各种规则（基于血泪的教训），还借鉴了别人的很多规则，无论是宏观的还是微观的。 可以说，规则就是扎实的好习惯。 虽然它们有时会成为障碍，但如果你想在编程领域工作到退休，那么这些规则是你表面上最大的资产，而了解和理解这些规则的来龙去脉，则是你深度上最大的资产。

文/王志成

原来的：