本文依旧希望大家建立起对中间件的一个良好观感。
希望大家能够通过这篇文章稍微知道什么是中间件。
文中提到的链接，希望大家点进去看看，毕竟人家写的比我更详细。
中间件描述的范围有点大，这里只说前端方面的中间件。
首先建立一个对中间件的初步观感
常看到中间件这个词，但是一搜都是一些比较抽象的概念。
后来去别的网站搜了搜，发现一些很有意思，又浅显易懂的回答，这里跟大家分享一下。
链接如下：
浅显易懂的解释就是，中间件类似中介，中间人。
炸鸡店不会自己去跟屠宰场交接，而是找了个中间人，从他那里拿货，不用担心自己去挑货的质量，这个中间人保证了货的质量。
就像评论里说的，类似中介。
中间件，就是所谓的中介，毕竟业务繁杂到一定程度后，干什么都需要中介
再结合场景看中间件
类似这篇文章：《什么是中间件？》中描述的场景：
近几年来，在企业开发中越来越推崇微服务架构，而它在不经意间却导致前端同学和后端同学之间关于 API 接口颗粒度的争吵，越来越多见：
- 「你自己请求 2 个接口再组装不就行了？」 - 后端同学追求服务下沉和解耦。
- 「少一次 HTTP 啊，加一个接口有那么难么？」 - 前端同学离用户最近，需要考虑用户体验灵活性。
再看这篇文章下的一个评论：
需求本身就复杂，还经常变更，后端实现和维护接口就越来越力不从心了，所以就有了微服务（Micro Services），
把原来的很多复杂接口拆分成多个细粒度的接口，让前端去分别调用再自己组合起来，
这又导致了前端的工作量大幅增加，
而且有时就算把各种接口组合起来仍然不能解决问题，
尤其是需要同时渲染UI的需求时，必须用一个接口一次性返回数据。
例如 获取朋友圈，后端给了以下几个接口：
moments/1, users/1, moments/priase, comments?momentId=1
分别调用并分段渲染会导致UI的评论区高度不断跳动，
因为预设的高度和拿到数据后渲染出来的高度不一致；
如果是依次调用再同时渲染，
不但多了几次HTTP连接导致时间变长，
还会导致moment里评论数commentCount=1，
但下面的评论comments却不止1条。
这种因为几次调用接口期间数据已更改导致的不一致问题。
前端为了解决这个问题就出现了中间件，将后端的接口聚合起来然后做数据整合，甚至结构变换。
Node.js用的是和前端一样的语言JavaScript，于是就顺手做了。
还有 版本迭代导致的兼容问题，后端还需要开发和维护大量重复功能的接口；
操作数据库时delete忘加where直接删光全部数据；
以及 繁琐恼人的开发流程：
后端写接口 > 后端写文档 > 前端/客户端查文档 > (前端/客户端关于文档向后端提问 > 后端解决问题并通知或等待再次被问) > 前端/客户端调用接口 > (前端/客户端关于实际使用向后端提问 > 后端解决问题并通知或等待再次被问) > 前端/客户端解析返回结果 > (前端/客户端关于返回内容或结构向后端提问 > 后端解决问题并通知或等待再次被问)
这些都导致了 前后端各种扯皮、前后端开发间歇性忙碌与闲置、接口bug不断漏洞频出、开发周期很长版本迭代慢
总结一下，我的理解就是，需求不断变化的情况下，后端提供的接口有时和前端需要的不能完全严丝合缝的吻合。
可是后端重写接口的代价有点大，于是出现了中间件在其中处理数据，然后重新提供给前端。
中间件就是上面提到的中介，前端不关心后端提供了什么，只关心中间件给自己提供了什么。
狭义的中间件和广义的中间件
中间件以后会消失吗这个回答，里面讲的概念很好！！！！
