本文纲要

  • express与koa的比照
  • Koa1 内核源码
  • 简要介绍 Koa2 内核与 koa1 的区别
  • 理解 Koa 中 http 协商缓存的实现机制
  • koa-router 源码
  • koa-view 源码

express

本文咱们不解说express的源码。然而express的实现机制对于咱们理解 TJ 在设计框架时的思路有肯定的参考意义。express 实现了一个相似于流的申请处理过程，其源码比 Koa 还要略微简单一点（次要是其内置了Router概念来实现路由）。如果对 express 的源码感兴趣的能够参考这两篇文章:

从express源码中探析其路由机制

NodeJS框架之Express4.x源码剖析

exporess和koa都是用来对http申请进行 接管、解决、响应。在这个过程中，express和koa都有提供中间件的能力来对申请和响应进行串联。同时要提供一个封装好的 执行上下文 来串联中间件。

因而，koa和express就是把这些http解决能力打包在一起的一个残缺的后端利用框架。波及到了一个申请解决的残缺流程，其中蕴含了这些常识概念：Application、Request、Response、COntext、Session、Cookie。

express跟koa的区别是，express应用的ES5时代的语言能力（没有应用generator和async），因而express实现的中间件机制是传统的串行的流式运行（从第一个运行到最初一个后输入响应）；而koa应用了generator或async从而实现了一种洋葱模型的中间件机制，所谓洋葱模型实际上就是中间件函数在运行过程中能够停下来，把执行权交给前面的中间件，等到适合的机会再回到函数内持续往下执行

Koa1 内核

本文咱们还是次要剖析 Koa1 的代码（因为 Generator 比 async 要绕一些难一些），我看的代码是基于 Koa 1.6.0。

对于 Koa1 来说，其实现是基于 ES6 的 Generator 函数。Generator 给了咱们用同步代码编写异步的可能，他能够让程序执行流 流向 下方，在异步完结之后再返回之前的中央执行。Generator 就像一个迭代器，能够通过它的 next 办法一直去迭代来实现函数的步进式执行。对于 Generator 函数解决异步问题的学习能够参考 阮一峰的 ES6 教程 Generator函数与异步

Koa 内核只有 1千 行左右的代码。共蕴含 4 个文件:

application.jsrequest.jsresponse.jscontext.js

咱们从 package.json 中能够看到 Koa 的主入口是 lib/application.js. 这个入口做的事件便是导出了一个 Application 的class类。（能够看到 Koa 的实现相比express曾经比拟面向对象了）

而 Application 的 prototype 上被挂载了咱们罕用的 application 的办法，例如 use, listen, callback, onerror 。

咦？是不是少了点 API？ app.env，app.proxy这些呢？

原来，这些是 Application 的实例属性，在 Application 实例化的时候会同步初始化。来看一下 Application 构造函数的代码:

function Application() {  if (!(this instanceof Application)) return new Application; // 反对工厂函数模式创立  this.env = process.env.NODE_ENV || 'development'; // 设置以后环境  this.subdomainOffset = 2; // 利用的子域偏移（这个次要是管制request.subdomain如何返回以后域名的哪个局部；具体可参考文档的request.subdomains）  this.middleware = []; // 寄存利用中间件的数组  this.proxy = false; // 是否信赖代理。为true时会让request.ips/hosts等字段读取X-Forward-*头  this.context = Object.create(context); // 在app挂载一个继承 context 对象的对象。  this.request = Object.create(request); // 在app挂载一个继承 request 对象的对象  this.response = Object.create(response); // 在app挂载一个继承 response 对象的对象}

Application 类型的实现就是如此简略，除此之外，还继承了 EventEmitter 从而提供事件能力:

Object.setPrototypeOf(Application.prototype, Emitter.prototype);

至此，Application 上的办法和属性咱们都找到源头了，暂且先不剖析其办法的具体实现。咱们再来看看 request 和 response 对象。

而从 request.js 中能够看到，该文件就仅仅导出了一个Object对象，对象中所有函数和属性即是 Koa 中间件中 request api 的所有办法。简要摘录下该文件源码构造:

// request.jsmodule.exports = {  get header() {    return this.req.headers;  }}

留神到这外面的 api 基本上就是对 Node.js 原生的 http.IncomingMessage 类型 API 的封装; response.js 也是相似的; context.js 也是相似的，并代理挂载了 request 和 response 的一些办法。那这里问题就来了: 下面代码中 this.req 为什么能够拿到 IncomingMessage 对象呢？这就要从 Koa 中间件是如何运行说起了。

中间件是如何运行起来的?

咱们先看下中间件是如何注入到利用中的。咱们在开发 Koa 利用时，通常是应用 app.use 来注册中间件。

app.use(function * (next) {  this.body = '123'  yield next})

而 use 函数做了一件很简略的事件: 把你的中间件置入 app.middleware 数组。

// 简化后的 use 函数app.use = function(fn){  this.middleware.push(fn);  return this;};

因为 use 函数同时返回了 this 指针，因而 app.use 得以能够链式调用。再回到咱们的话题: 中间件是如何运行起来的。 咱们看下 Koa 的启动代码:

http.createServer(app.callback()).listen(3000);// 或app.listen(3000)

因为 listen 是一个语法糖，因而 http申请 最终都是被 app.callback() 函数返回的一个 function 来执行。 咱们看看 callback 到底返回了一个什么函数, 上面是我去掉了一些无关紧要的 error 解决代码之后的源码:

app.callback = function(){  var fn = co.wrap(compose(this.middleware)); // 把所有中间件包装成一个fn函数  var self = this;  // 返回一个闭包  return function handleRequest(req, res){    var ctx = self.createContext(req, res); // 把Node原生的req和res包装成Koa的context对象    self.handleRequest(ctx, fn); // 开始执行中间件  }};

其实原理很简略了，就是把 http 申请利用 createContext函数包装为 context 对象，而后调用 app.handleRequest 把利用内所有中间件执行一遍并返回后果给浏览器。

还记得上文提到的一个问题: 为什么 request对象内能够用 this.req 拿到原生申请？ 原理在这里就不言而喻了，正是 self.createContext 把原生 req 设置在了 ctx 对象上（这里就不开展源码解说了）

当初流程根本分明了。但这里有个难点:

  1. fn 函数是如何可能把所有 Generator 中间件执行的？
  2. 中间件执行实现后是如何响应给浏览器后果的？

delegates 挂载属性到context

咱们如果读过koa文档，会发现在中间件中 this/ctx 上是能够拜访到 ctx.request 对象上的属性的。这个是因为 koa 在初始化context对象的过程中，把request上相干的属性挂载到了ctx.

这是中间件执行之前创立ctx的过程：

app.createContext = function(req, res){  var context = Object.create(this.context);  var request = context.request = Object.create(this.request); // ctx能够拜访request对象  var response = context.response = Object.create(this.response);  context.app = request.app = response.app = this; // ctx能够拜访app对象  context.req = request.req = response.req = req; //ctx能够拜访原生req对象  context.res = request.res = response.res = res;  request.ctx = response.ctx = context; // request对象能够拜访ctx  request.response = response; // request和rewspinse能够相互拜访  response.request = request;  context.onerror = context.onerror.bind(context);  context.originalUrl = request.originalUrl = req.url;  context.cookies = new Cookies(req, res, {    keys: this.keys,    secure: request.secure  });  context.accept = request.accept = accepts(req);  context.state = {};  return context;};

这段代码还是无法解释为什么ctx上能够拜访request对象的上的属性。然而这里有一点是有作用的：ctx对象下面挂载了request对象。因而，在ctx的办法中能够通过 this.request 拜访到request对象，这为ctx提供了拜访request属性的根底。

上述的问题的答案，其实在context对象初始化的过程当中。咱们看看context对象的初始化时做了个什么事件：

delegate(proto, 'request')  .method('acceptsLanguages')  .method('acceptsEncodings')  .method('acceptsCharsets')  .access('querystring')  .access('idempotent')  .access('socket')  .access('search')  ...

能够看到，这里调用delegate这个库，给context对象增加了很多办法。实际上从deleteate源码中得悉，delegate原型是这样的：

Delegator.prototype.method = function(name){  var proto = this.proto;  var target = this.target;  this.methods.push(name);  proto[name] = function(){    return this[target][name].apply(this[target], arguments);  };  return this;};

这个很显著就是给ctx增加办法函数，函数内调用指标对象的办法。access是通过getter，setter来拜访this[target]的属性。
至此，ctx能够拜访request和response属性的谜底就解开了。

中间件的合并和执行

中间件的执行流程和koa2是统一的。把中间件想作一个栈，申请会从顶部的第一个中间件开始解决，遇到yield next调用，就会进入下一个中间件中，直到最初没有yield next调用，再从栈底反弹，一个一个执行之前next之后的代码。

上文讲到了中间件执行次要靠这句代码合并为一个fn函数:

var fn = co.wrap(compose(this.middleware))

这里 compose 是来自 koa-compose 这个模块。 在前文《Koa教程-罕用中间件》中，咱们曾经理解了中间件的合并形式以及 koa-compose 的运作原理：总之就是通过 一直实例化Generator并作为参数传递给前一个Generator函数 的形式把多个 Generator 串联起来，最终执行第一个中间件就相当于串联执行所有中间件。

那么，co.wrap 是什么呢? 这里看下 co 源码 (co源码4.6.0加正文总共才237行):

co.wrap = function (fn) {  createPromise.__generatorFunction__ = fn;  return createPromise;  function createPromise() {    return co.call(this, fn.apply(this, arguments));  }};function co(gen) {  ...}

能够看到，co.wrap 仅仅就是返回了一个闭包，该闭包用于利用 co 来执行原函数（对于co是如何执行Generator的，本文暂不解说）。看到这里，会有点纳闷，wrap包裹一层这是不是有点多此一举啊？实际上我下面省略了一点点代码，这里 Koa 是为了兼容 ES7 可能不须要co来运行中间件的状况。这里fn函数赋值的原始代码如下:

// ES7 合并后的中间件函数能够间接执行。ES6 generator的形式须要借助CO执行。 fn函数屏蔽了底层差别var fn = this.experimental? compose_es7(this.middleware): co.wrap(compose(this.middleware));

至此，咱们曾经梳理出整个 http 申请的流程，即: Koa 收到 http 连贯回调后，对InCompingMessage进行包装为 ctx, 并调用中间件合并后的函数 fn 进行业务解决。业务解决的代码非常简单，就是以ctx为上下文执行中间件:

// handleRequest便是收到网络申请后中间件运行的终点app.handleRequest = function(ctx, fnMiddleware){  ctx.res.statusCode = 404;  onFinished(ctx.res, ctx.onerror);  // 留神这里: fnMiddleware.call(ctx) 就把中间件执行上下文设置为了 context 对象  fnMiddleware.call(ctx).then(function handleResponse() {    respond.call(ctx);  }).catch(ctx.onerror);};

在开发 Koa 利用时，咱们晓得在中间件中应用 this 就是在拜访 context 对象. 正是因为在 Koa 执行中间件函数时将上下文设置为了 context 对象。

response如何响应给浏览器的？

这个次要是在 co 执行中间件 resolve 之后利用了上文代码中看到的 respond 函数来实现。

  fnMiddleware.call(ctx).then(function handleResponse() {    respond.call(ctx);  }).catch(ctx.onerror);

respond函数次要是对ctx上设置的body内容进行解析，并抉择适合的办法响应给浏览器。这里限于篇幅不再具体解说了。

为什么能够不必 yield *

另外咱们发现，在 Koa 的中间件里，咱们通常用:

 yield next

来运行下一个中间件。通过下面的原理，咱们理解到所谓的 next 变量 实际上就是下一个中间件 Generator函数的实例，可是咱们会纳闷右值是一个Generator对象的时候 运行 Generator实例为什么没有应用 yield *？ 实践上，如果依照 Generator的原始执行形式，没有应用 yield * 的话，这个语句只会返回 next 这个遍历器对象而已，是无奈运行 next 函数的

这个问题的答案就在 co 源码外面，如果看过 co 的源码，会发现它是通过 右值.then(data=>{...}) 回调里一直递归调用 gen.next(data) 来实现主动执行。而 gen.next 又会返回一个新的右值 {value: xx, done:false} ，co通过 toPromise 函数对右值进行Promise化从而能够调用 then，而 toPromise函数中如果检测到这个右值是一个Generator遍历器对象，则会从新用 co 来 run 这个对象。

因而，co 外面能够反对应用了 yield * 的形式（这种形式 Generator默认会开展下一层的遍历器）；也能够反对 yield + 遍历器 的形式，这种形式是 co 本人检测到并运行这个迭代器的。

Koa2 内核

Koa2 次要是用 async await 代替了 Generator，用起来更不便了。async await 是 Generator 的语法糖，能够这样了解:

await --> 等于 yieldasync --> 等于 Generator函数申明: function * () {}调用 async 函数 --> 等于利用 co 来主动执行 Generator: co(function*(){})

co 运行器返回的是一个 Promise， async 函数运行后也是返回一个 Promise。

Koa2 外面间接应用了 ES6 语法来创立 Application 类型:

module.exports = class Application extends Emitter {}

Koa2 中的 app.use、app.listen 等实现与 Koa1 根本完全一致。区别开始呈现在 app.callback 函数里:

  callback() {    const fn = compose(this.middleware); // 合并中间件    if (!this.listenerCount('error')) this.on('error', this.onerror);    const handleRequest = (req, res) => {      const ctx = this.createContext(req, res);      return this.handleRequest(ctx, fn);    };    return handleRequest;  }  handleRequest(ctx, fnMiddleware) {    const res = ctx.res;    res.statusCode = 404;    const onerror = err => ctx.onerror(err);    const handleResponse = () => respond(ctx);    onFinished(res, onerror);    return fnMiddleware(ctx).then(handleResponse).catch(onerror);  }

能够看到 handleRequest 外面调用中间件函数 fnMiddleware 时不再设置上下文，而是间接传递 ctx 到中间件中。因而 Koa 在中间件里不是通过 this 获取上下文，而是用 ctx 变量。

另外一个次要区别就在于下面代码中这个 compose 了。

koa2的 compose模块

Koa2 应用了 4.x 版本的 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!')  }  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)      }    }  }}

这个 compose 就是专门针对 async 函数而设计的了。 它最终返回的是个 function (context, next) 这样的闭包函数。 在上文讲到的 Koa2 的申请入口里 fnMiddleware(ctx) 的 fnMiddleware 实际上就是在调用这个函数。能够看到这个函数只接管了 context 参数，而 next 参数是 undefined。

咱们再来看看这个函数外部做了啥。它实际上从 middleware数组的第 0 项开始触发执行(dispath(0))，相当于被动在调用中间件async函数:

 yourmid(ctx, next)

而这个 next 实际上传入的是下一个中间件函数。由此造成了递归调用。直到最初中间件没有了， fn = next 被赋值为undefined（因为next的值是undefined），而后回溯。回溯后返回的 Promise 交给 handleResponse 响应或错误处理:

const onerror = err => ctx.onerror(err);return fnMiddleware(ctx).then(handleResponse).catch(onerror);

能够看到 Koa2 的错误处理机制，跟 Koa1 也是一样的，都是中间件中一旦产生 throw Error，则会触发 fnMiddleware 的 catch，进而触发 context 对象的 onerror，在 ctx.onerror 外面会做出浏览器响应并调用 app.onerror 兜底。

以上就是 Koa2 的执行流程。跟 Koa1 差异不是很大，这里没有再过多开展了，如果心愿理解更具体的 Koa2 源码解读，这里举荐一篇知乎专栏吧

Koa 中协商缓存实现机制

咱们晓得在 http 协定中， 服务器端个别应用 http 报文的 if-none-match if-modify-since 字段来进行缓存协商。 Koa 提供了一个 request.fresh 函数来帮忙你确定是否返回 304.

这个 fresh 函数的实现基于 npm 模块 fresh. 它外部会查看以后 response 响应头的 etag 和 last-modifyed 与 申请头里的 对应字段进行比对判断。

这个能够用在 Node 响应浏览器的最初一环时。

koa-route

咱们先看一个简陋版的router是怎么做的。这个库叫做 koa-route （留神不是koa-router哦）

这个route库只做了一件事，就是帮咱们生成简略的 generator 中间件，中间件的内容就是判断以后申请的门路是否是合乎咱们的配置要求，合乎才执行。

其用法如下:

var _ = require('koa-route');app.use(_.get('/pets', pets.list));app.use(_.get('/pets/:name', pets.show));

其中pets.list假如就是咱们针对 /pets 门路的处理函数。

实际上 _.get() 会把你传入的path包装成一个对其进行判断的generator中间件。相似于：

function * (next) {    if (this.path === '/pets' && this.method === 'get') {        ...    }    else {        yield next    }}

看他的源码也只有聊聊几行，外围在于这个create函数：

这个红圈圈进去的局部就是理论的 _.get返回值，作为中间件给注册进了 Koa

koa-view

TODO

KOA源码学习

Koa1源码学习+co源码学习
Koa2源码学习
你晓得koa中间件执行原理吗