共计 5977 个字符，预计需要花费 15 分钟才能阅读完成。
Koa 是一款设计优雅的轻量级 Node.js 框架，它主要提供了一套巧妙的中间件机制与简练的 API 封装，因此源码阅读起来也十分轻松，不论你从事前端或是后端研发，相信都会有所收获。
目录结构
首先将源码下载到本地，可以看到 Koa 的源码只包含下述四个文件：
lib
├── application.js
├── context.js
├── request.js
└── response.js
application.js
application.js 为 Koa 的主程序入口文件，在 package.json 的 main 字段有定义。它主要负责 HTTP 服务的注册、封装请求相应对象，并初始化中间件数组并通过 compose 方法进行执行。
context.js
context.js 的核心工作为将请求与响应方法集成到一个上下文 (Context) 中，上下文中的大多数方法都是直接委托到了请求与响应对象上，本身并没做什么改变，它能为编写 Web 应用程序提供便捷。
request.js
request.js 将 http 库的 request 方法进行抽象与封装，通过它可以访问到各种请求信息。
response.js
response.js 与 request 功能类似，它是对 response 对象的抽象与封装。
中间件
示例
对于 Koa 的中间件机制相信大家都耳熟能详了，现在让我们来看看源码实现。在这里还是先举一个最简单的例子：
const Koa = require(‘koa’);
const app = new Koa();
app.use((ctx, next) => {
console.log(‘enter 1’);
next();
console.log(‘out 1’);
});
app.use((ctx, next) => {
console.log(‘enter 2’);
next();
console.log(‘out 2’);
});
app.use((ctx, next) => {
console.log(‘enter 3’);
next();
console.log(‘out 3’);
});
app.listen(3000);
现在让我们来访问应用：curl 127.0.0.1:3000，可以看到以下输出结果：
enter 1
enter 2
enter 3
out 3
out 2
out 1
next 是什么？
通过以上的结果进行分析，当我们执行 next()的时候，可能程序的执行权交给了下一个中间件，next 函数会等待下一个中间件执行完毕，然后接着执行，这样的执行机制被称为“洋葱模型”，因为它就像请求穿过一层洋葱一样，先从外向内一层一层执行，再从内向外一层一层返回，而 next 就是进行下一层的一把钥匙：
原理
聊完了理想，现在我们来聊现实。首先来看看 app.use 函数：
use(fn) {
if (typeof fn !== ‘function’) throw new TypeError(‘middleware must be a function!’);
if (isGeneratorFunction(fn)) {
deprecate(‘Support for generators will be removed in v3. ‘ +
‘See the documentation for examples of how to convert old middleware ‘ +
‘https://github.com/koajs/koa/blob/master/docs/migration.md’);
fn = convert(fn);
}
debug(‘use %s’, fn._name || fn.name || ‘-‘);
this.middleware.push(fn);
return this;
}
整个函数只做了一件事情，将中间件函数添加到了实例中的 middleware 数组，其他的即是对类型进行校验，若不为函数则直接报 TypeError，若为生成器则发出 deprecated 警告并使用 koa-convert[注 1]对其转化。
中间件在什么时候执行的呢？首先我们找到 listen 的回调函数：
const server = http.createServer(this.callback());
然后来看看这个神奇的 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;
}
函数首先将中间件使用 koa-compose 进行处理，那个 compose 到底是个什么呢？不如直接来看源码吧（省略掉了注释与类型检测）：
function compose (middleware) {
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)
}
}
}
}
首先我们把目光放到 index 与 i 两个变量上，当执行执行 compose(middleware)函数时，会返回一个闭包函数 distpach(0)，闭包函数执行时，dispatch 函数内部的判断逻辑如下：
若 i 小于等于 index 则报出错误：’next() called multiple times’。
若 i 大于 index 时，将 i 赋予 index，此时 i 与 index 相等。
逻辑很简单，但这样做的目的是什么呢？假若程序按着预期执行，每个中间件内部都执行 next()，假若有 3 个中间件，那么当每次执行 dispatch(i)时，到 Line8 之前 index 与 i 的值分别为：-1/0, 0/1, 1/2，可以看出 i 始终要大于 index，index 的闭包变量每次在执行完函数后都会加 1，因此可以知道的是若同一个中间件执行了两次，index 就会等于 i，再执行一次 index 就会大于 i，由此可知，index 的存在意义在于限制 next 能执行不超过 1 次。
Line9 到 Line11 用于取出 middleware 中的当前中间件，若数组为最大索引标识，则会将 fn 等于 next 函数，意味着将再执行一次越级的索引 i + 1，由于取不到值，于是就执行到 Line11 返回 Promise.resolve()。
当函数执行到 Line13，则会运行当前中间件，并将是否执行下一个中间件 dispatch(i + 1)的决定权传递到 next 参数，将运行结果返回，返回函数的运行结果的意义在于每次执行 next 的返回结果都是下一个中间件的执行结果的 Promise 对象。
回到 callback
让我们继续看 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;
}
首先来看看 Line3，因为 Application 继承与 Emitter，故此方法是用于监听实例中的 error 事件的，当 listenerCount 的数值为 0 时，表示没有监听过，则注册监听函数。
接着生成一个 handleRequest 回调，当每个请求过来时，都会创建 ctx 上下文对象，并将中间件函数传入实例方法 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);
}
在这里多出了几个函数：
on-finished，监听请求是否正常结束。
respond，当中间件执行完毕后，处理 response 对象的 status 与 body 的字段。
回到示例
回到示例，是否恍如隔日？现在的代码还困扰你吗？让我们稍作修改：
app.use((ctx, next) => {
console.log(‘enter 1’);
next();
console.log(‘out 1’);
});
app.use((ctx, next) => {
console.log(‘enter 2’);
});
app.use((ctx, next) => {
console.log(‘enter 3’);
next();
console.log(‘out 3’);
});
此时你能准确的知道执行结果吗？此时打印顺序为：enter 1 -> enter 2 -> out 1。因为只有 next 才是进入到下一中间件的钥匙。若再将程序改一改：
app.use(async (ctx, next) => {
console.log(‘enter 1’);
next();
console.log(‘out 1’);
});
app.use(async (ctx, next) => {
console.log(‘enter 2’);
await next();
console.log(‘out 2’);
});
此时执行结果为：enter1 -> enter2 -> out 1 -> out2，这你能答对吗？你不需要记住范式与结果，回想一下核心的 compose 函数：return Promise.resolve(fn(context, dispatch.bind(null, i + 1)))，首先中间件全为 async 函数，若使用 await next()，则会等待下一个中间件返回 resolve 状态才会执行此代码，如果某一个 Promise 中间件不使用 await 关键字呢？它会在主进程上进行排队等待，等到函数执行栈返回到当前函数后立即执行。对于此示例来讲，当进入到第二个中间件，遇到 await 关键字时，console.log(‘out 2’)则不会再执行，而是进入到微任务队列中，此时主进程已无其他任务，则函数退出当前栈，返回到了第一个函数中，此时输出 out 1，当第一个中间件执行结束后，事件循环才会将中间件 2 的微任务取出来执行，因此你见到了上述的输出顺序。
上下文
通过上述分析，我们了解到 http.createServer 中有一个 callback 函数，它不仅负责执行 compose 函数，也会调用 createContext 方法创建函数上下文，源码如下：
createContext(req, res) {
const context = Object.create(this.context);
const request = context.request = Object.create(this.request);
const response = context.response = Object.create(this.response);
context.app = request.app = response.app = this;
context.req = request.req = response.req = req;
context.res = request.res = response.res = res;
request.ctx = response.ctx = context;
request.response = response;
response.request = request;
context.originalUrl = request.originalUrl = req.url;
context.state = {};
return context;
}
可以由这个函数得知，ctx 对象包含了 `context.jsrequest.js、response.js` 的代码。通过访问 req 与 res 的源代码，大家可以发现在 request 与 response 对象中封装了许许多多 http 库的请求方法与各类工具函数，若对 http 底层实现感兴趣的小伙伴可以仔细读一下 request 与 response 文件，否则多查阅几遍官网文档，大概了解其中的 api 即可。
而对于 context.js，其实十分简单，它也封装了部分工具方法，并使用 node-delegates 进行委托方法与属性，对于此类方法的时间，估计 koa3 会将这一部分进行重构为 Proxy 吧。
注解
1. koa-convert 转化
在 Koa 版本号为 1.x 时，中间件都是使用 Generator 实现的，因此可以通过官方提供的 koa-convert 临时对其进行转化与兼容，基本用法为：
function * legacyMiddleware (next) {
// before
yield next
// after
}
app.use(convert(legacyMiddleware))
然后打开源码发现，核心代码大概如下：
function convert (mw) {
return (ctx, next) => co.call(ctx, mw.call(ctx, createGenerator(next)))
}
convert 函数将生成器通过 co 进行包装为 Promise 函数，在 ctx 上下文进行执行，并传入 next 函数。
总结
凡是涉及到原理性的东西，感觉自己很难避免自顾自说，用图片进行可视化的方式会更加直观，易于理解，希望之后自己多多使用图片来阐述原理。
通过源码分析，我们知道了 Koa 的核心思想建立于中间件机制，它是一个设计十分简洁、巧妙的 Web 框架，扩展性极强，egg.js 就是建立于 Koa 之上的上层框架。
