express评论：繁琐简单！虽有精妙中间件设计，其余设计过于简单层层回调和递归
koa2评论：精简彪悍！新js规范(async..await)很好实现中间件

1、express用法和koa用法简略展现

如果你应用express.js启动一个简略的服务器，那么根本写法应该是这样：

const express = require('express')const app = express()const router = express.Router()app.use(async (req, res, next) => {  console.log('I am the first middleware')  next()  console.log('first middleware end calling')})app.use((req, res, next) => {  console.log('I am the second middleware')  next()  console.log('second middleware end calling')})router.get('/api/test1', async(req, res, next) => {  console.log('I am the router middleware => /api/test1')  res.status(200).send('hello')})router.get('/api/testerror', (req, res, next) => {  console.log('I am the router middleware => /api/testerror')  throw new Error('I am error.')})app.use('/', router)app.use(async(err, req, res, next) => {  if (err) {    console.log('last middleware catch error', err)    res.status(500).send('server Error')    return  }  console.log('I am the last middleware')  next()  console.log('last middleware end calling')})app.listen(3000)console.log('server listening at port 3000')

换算成等价的koa2，那么用法是这样的：

const koa = require('koa')const Router = require('koa-router')const app = new koa()const router = Router()app.use(async(ctx, next) => {  console.log('I am the first middleware')  await next()  console.log('first middleware end calling')})app.use(async (ctx, next) => {  console.log('I am the second middleware')  await next()  console.log('second middleware end calling')})router.get('/api/test1', async(ctx, next) => {  console.log('I am the router middleware => /api/test1')  ctx.body = 'hello'})router.get('/api/testerror', async(ctx, next) => {  throw new Error('I am error.')})app.use(router.routes())app.listen(3000)console.log('server listening at port 3000')

于是二者的应用区别通过表格展现如下：

koa(Router = require('koa-router'))express(假如不应用app.get之类的办法)
初始化const app = new koa()const app = express()
实例化路由const router = Router()const router = express.Router()
app级别的中间件app.useapp.use
路由级别的中间件router.getrouter.get
路由中间件挂载app.use(router.routes())app.use('/', router)
监听端口app.listen(3000)app.listen(3000)

区别：koa用的新规范，因二者外部实现机制不同，挂载路由中间件也有差别

重点：便是放在二者的中间件的实现上

2、express.js中间件实现原理

demo展现express.js的中间件在解决某些问题上的弱势

const express = require('express')const app = express()const sleep = (mseconds) => new Promise((resolve) => setTimeout(() => {  console.log('sleep timeout...')  resolve()}, mseconds))app.use(async (req, res, next) => {  console.log('I am the first middleware')  const startTime = Date.now()  console.log(`================ start ${req.method} ${req.url}`, { query: req.query, body: req.body });  next()  const cost = Date.now() - startTime  console.log(`================ end ${req.method} ${req.url} ${res.statusCode} - ${cost} ms`)})app.use((req, res, next) => {  console.log('I am the second middleware')  next()  console.log('second middleware end calling')})app.get('/api/test1', async(req, res, next) => {  console.log('I am the router middleware => /api/test1')  await sleep(2000)  res.status(200).send('hello')})app.use(async(err, req, res, next) => {  if (err) {    console.log('last middleware catch error', err)    res.status(500).send('server Error')    return  }  console.log('I am the last middleware')  await sleep(2000)  next()  console.log('last middleware end calling')})app.listen(3000)console.log('server listening at port 3000')

该demo中当申请/api/test1的时候打印后果是什么呢？

I am the first middleware================ start GET /api/test1I am the second middlewareI am the router middleware => /api/test1second middleware end calling================ end GET /api/test1 200 - 3 mssleep timeout...

如果你分明这个打印后果的起因，想必对express.js的中间件实现有肯定的理解。

咱们先看看第一节demo的打印后果是：

I am the first middlewareI am the second middlewareI am the router middleware => /api/test1second middleware end callingfirst middleware end calling

这个打印合乎大家的冀望，然而为什么方才的demo打印的后果就不合乎冀望了呢？二者惟一的区别就是第二个demo加了异步解决。有了异步解决，整个过程就乱掉了。因为咱们冀望的执行流程是这样的：

I am the first middleware================ start GET /api/test1I am the second middlewareI am the router middleware => /api/test1sleep timeout...second middleware end calling================ end GET /api/test1 200 - 3 ms

那么是什么导致这样的后果呢？咱们在接下去的剖析中能够失去答案。

2.1、express挂载中间件的形式

要了解其实现：咱们得先晓得express.js到底有多少种形式能够挂载中间件进去？
挂载办法：(HTTP Method指代那些http申请办法，诸如Get/Post/Put等等)

  • app.use
  • app.[HTTP Method]
  • app.all
  • app.param
  • router.all
  • router.use
  • router.param
  • router.[HTTP Method]

2.2、express中间件初始化

express代码中依赖于几个变量(实例)：app、router、layer、route，这几个实例之间的关系决定了中间件初始化后造成一个数据模型，画了上面一张图片来展现：

看下面两张图，咱们抛出上面几个问题，搞懂问题便是搞懂了初始化。

  • 初始化模型图Layer实例为什么分两种？
  • 初始化模型图Layer实例中route字段什么时候会存在？
  • 初始化实例图中挂载的中间件为什么有7个？
  • 初始化实例图中圈2和圈3的route字段不一样，而且name也不一样，为什么？
  • 初始化实例图中的圈4里也有Layer实例，这个时候的Layer实例和下面的Layer实例不一样吗？

首先咱们先输入这样的一个概念：Layer实例是path和handle相互映射的实体，每一个Layer便是一个中间件。

这样的话，咱们的中间件中就有可能嵌套中间件，那么看待这种情景，express就在Layer中做手脚。咱们分两种状况挂载中间件：

  1. 应用app.use、router.use来挂载的

    • app.use通过一系列解决之后最终也是调用router.use的

  2. 应用app.all、app.[Http Method]、app.route、router.all、router.[Http Method]、router.route来挂载的

    • app.all、app.[Http Method]、app.route、router.all、router.[Http Method]通过一系列解决之后最终也是调用router.route的

聚焦router.use和router.route这两办法。

2.2.1、router.use

该办法的最外围一段代码是：

for (var i = 0; i < callbacks.length; i++) {  var fn = callbacks[i];  if (typeof fn !== 'function') {    throw new TypeError('Router.use() requires a middleware function but got a ' + gettype(fn))  }  // add the middleware  debug('use %o %s', path, fn.name || '<anonymous>')  var layer = new Layer(path, {    sensitive: this.caseSensitive,    strict: false,    end: false  }, fn);  // 留神这个route字段设置为undefined  layer.route = undefined;  this.stack.push(layer);}

Layer实例：初始化实例图圈1的所有Layer实例，自定义的中间件(共5个)，还有两个零碎自带，看初始化实例图的Layer的名字别离是：query和expressInit
二者的初始化是在application.js中的lazyrouter办法：

// application.jsapp.lazyrouter = function lazyrouter() {  if (!this._router) {    this._router = new Router({      caseSensitive: this.enabled('case sensitive routing'),      strict: this.enabled('strict routing')    });    this._router.use(query(this.get('query parser fn'))); // 最终调用的就是router.use办法    this._router.use(middleware.init(this)); // 最终调用的就是router.use办法  }};

第三个问题：7个中间件，2个零碎自带、3个APP级别的两头、2个路由级别的中间件

2.2.2、router.route

app.all、app.[Http Method]、app.route、router.all、router.[Http Method]
通过一系列解决之后最终也是调用router.route
所以咱们在demo中的express.js，应用了两次app.get，其最初调用了router.route
外围实现：

proto.route = function route(path) {  var route = new Route(path);  var layer = new Layer(path, {    sensitive: this.caseSensitive,    strict: this.strict,    end: true  }, route.dispatch.bind(route));  layer.route = route;  this.stack.push(layer);  return route;};

区别上一个办法就是多了new Route这个
通过二者比照，咱们能够答复下面的好几个问题：

  • 初始化模型图Layer实例为什么分两种?
    因为调用形式的不同决定了Layer实例的不同
    第二种Layer实例是挂载在route实例之下的
  • 初始化模型图Layer实例中route字段什么时候会存在？
    应用router.route的时候就会存在
    最初一个问题，既然实例化route之后，route有了本人的Layer

那么它的初始化又是在哪里的？初始化外围代码：

// router/route.js/Route.prototype[method]for (var i = 0; i < handles.length; i++) {    var handle = handles[i];    if (typeof handle !== 'function') {      var type = toString.call(handle);      var msg = 'Route.' + method + '() requires a callback function but got a ' + type      throw new Error(msg);    }    debug('%s %o', method, this.path)    var layer = Layer('/', {}, handle);    layer.method = method;    this.methods[method] = true;    this.stack.push(layer);  }

能够看到新建的route实例，保护的是一个path，对应多个method的handle的映射
每一个method对应的handle都是一个layer，path对立为/

至此，再回去看初始化模型图，置信大家能够有所明确了吧~

2.3、express中间件的执行逻辑

整个中间件的执行逻辑无论是外层Layer，还是route实例的Layer，都是采纳递归调用模式，一个十分重要的函数next()流程图太简单，不看了：

咱们再把express.js的代码应用另外一种模式实现，这样你就能够齐全搞懂整个流程了。

为了简化，咱们把零碎挂载的两个默认中间件去掉，把路由中间件去掉一个，最终的成果是：

((req, res) => {  console.log('I am the first middleware');  ((req, res) => {    console.log('I am the second middleware');    (async(req, res) => {      console.log('I am the router middleware => /api/test1');      await sleep(2000)      res.status(200).send('hello')    })(req, res)    console.log('second middleware end calling');  })(req, res)  console.log('first middleware end calling')})(req, res)

因为没有对await或者promise的任何解决，所以当中间件存在异步函数的时候，因为整个next的设计起因，并不会期待这个异步函数resolve,于是咱们就看到了sleep函数的打印被放在了最初面，并且第一个中间件想要记录的申请工夫也变得不再精确了~

3、koa2中间件

koa2中间件的主解决逻辑放在了koa-compose，也就是仅仅一个函数的事件：

function compose (middleware) {  if (!Array.isArray(middleware)) throw new TypeError('Middleware stack must be an array!')  for (const fn of middleware) {    if (typeof fn !== 'function') throw new TypeError('Middleware must be composed of functions!')  }  /**   * @param {Object} context   * @return {Promise}   * @api public   */  return function (context, next) {    // last called middleware #    let index = -1    return dispatch(0)    function dispatch (i) {      if (i <= index) return Promise.reject(new Error('next() called multiple times'))      index = i      let fn = middleware[i]      if (i === middleware.length) fn = next      if (!fn) return Promise.resolve()      try {        return Promise.resolve(fn(context, dispatch.bind(null, i + 1)));      } catch (err) {        return Promise.reject(err)      }    }  }}

每个中间件调用的next()其实就是这个：

dispatch.bind(null, i + 1)

还是利用闭包和递归的性质，一个个执行，并且每次执行都是返回promise，所以最初失去的打印后果也是如咱们所愿。那么路由的中间件是否调用就不是koa2管的，这个工作就交给了koa-router，这样koa2才能够放弃精简彪悍的格调。

再贴出koa中间件的执行流程吧：