共计 7851 个字符，预计需要花费 20 分钟才能阅读完成。
本文 github 地址：https://github.com/HCThink/h-blog/blob/master/source/koa2/readme.md
github 首页 (star+watch，一手动态直达)：https://github.com/HCThink/h-blog
掘金 link , 掘金 专栏
segmentfault 主页
原创禁止私自转载
koa2
koa homepage
优秀的下一代 web 开发框架。Koa 应用程序不是 HTTP 服务器的 1 对 1 展现。可以将一个或多个 Koa 应用程序安装在一起以形成具有单个 HTTP 服务器的更大应用程序。
基础使用
快速搭建简易 koa server 服务
koa 搭建一个服务还是很简单的, 主要代码如下，完整代码如下. 切到主目录下，
安装依赖：yarn
执行入口：yarn start
koa demo 目录
koa demo 主文件
import Koa from ‘koa’;
import https from ‘https’;
import open from ‘open’;
const Log = console.log;
const App = new Koa();
App.use(async (ctx, next) => {
ctx.body = ‘Hello World’;
Log(‘mid1 start…’);
await next();
Log(‘mid1 end…’);
});
App.use(async (ctx, next) => {
debugger;
Log(‘mid2 start…’);
await next();
Log(‘mid2 end…’);
});
App.use((ctx, next) => {
Log(‘mid3…’);
});
// 服务监听：两种方式。
App.listen(3000); // 语法糖
// http.createServer(app.callback()).listen(3000);
https.createServer(App.callback()).listen(3001);
open(‘http://localhost:3000’);
// 如下为执行顺序，实际上 http 会握手，所以输出多次
// 如下执行特征也就是洋葱圈，实际上熟悉 async、await 则不会比较意外。
// mid1 start…
// mid2 start…
// mid3…
// mid2 end…
// mid1 end…
koa2 特性
封装并增强 node http server[request, response]，简单易容。
洋葱圈处理模型。
基于 async/await 的灵活强大的中间件机制。
通过委托使得 api 在使用上更加便捷易用。
api
参考官网提供的基本 api，不在赘述：https://koa.bootcss.com/
部分 api 实现，参考：源码分析
常用 api
app.listen: 服务端口监听
app.callback: 返回适用于 http.createServer() 方法的回调函数来处理请求。你也可以使用此回调函数将 koa 应用程序挂载到 Connect/Express 应用程序中。
app.use(function): 挂载中间件的主要方法。
核心对象
context
Koa Context 将 node 的 request 和 response 对象封装到单个对象中，为编写 Web 应用程序和 API 提供了许多有用的方法。这些操作在 HTTP 服务器开发中频繁使用，它们被添加到此级别而不是更高级别的框架，这将强制中间件重新实现此通用功能。__每个__ 请求都将创建一个 Context，并在中间件中作为接收器引用，或者 ctx 标识符。
ctx.res request
ctx.req：response
ctx.request：koa request tool
ctx.response：koa response tool
ctx.cookies
ctx.request.accepts(types): type 值可能是一个或多个 mime 类型的字符串，如 application/json，扩展名称如 json，或数组 [“json”, “html”, “text/plain”]。
request.acceptsCharsets(charsets)
…
更多参考
洋葱圈
使用层面
koa 洋葱圈执行机制图解
koa 洋葱圈
koa demo, koa demo 源码
洋葱圈简易实现版
执行方式：tsc onionRings.ts –lib ‘es2015’ –sourceMap && node onionRings.js
洋葱圈简易实现版 main, 洋葱圈简易实现版 源码
简易实现 外部中间件
参考：koa-bodyparser
main code
public use(middleware: Function) {
this.middList.push(middleware);
}
// 执行器
private async deal(i: number = 0) {
debugger;
if (i >= this.middList.length) {
return false;
}
await this.middList[i](this, this.deal.bind(this, i + 1));
}
实现思路
use 方法注册 middleware。
deal 模拟一个执行器: 大致思路就是将下一个 middleware 作为上一个 middleware 的 next 去 await，用以保证正确的执行顺序和中断。
问题
如果习惯了回调的思路，你会不会有这种疑惑：洋葱圈机制于在 一个中间件中调用另一个中间件，被调中间件执行成功，回到当前中间件继续往后执行，这样不断调用，中间件很多的话，会不会形成一个很深的函数调用栈？从而影响性能，同时形成「xx 地狱」？— ps（此问题源于分享时原同事 小龙 的提问。）
实际上这是个很好的问题，对函数执行机制比较了解才会产生的疑问。排除异步代码处理，我们很容易用同步方式模拟出这种调用层级。参考：同步方式。这种模式存在明显的调用栈问题。
我可以负责任的回答：不会的，下一个问题。???? ????
不会的原因在 generator 中详细介绍，一两句说不清楚。实际上我认为这里是有语法门槛的。在 generator 之前，用任何方式处理这个问题，都显得怪异，而且难以解调用决层级带来的性能, 调试等带来问题。
详细说明参考：generator 真. 协程
源码
KOA 源码特别精简, 不像 Express 封装的功能那么多, git 源码：【https://github.com/koajs/koa】
工程
koa2 的源码工程结构非常简洁，一目了然, 没有花里胡哨的东西。
主文件
├── History.md
├── ….
├── Readme.md
├── benchmarks
├── docs // doc
│ ├── api ……
├── lib // 源码
│ ├── application.js // 入口文件，封装了 context，request，response，核心的中间件处理流程。
│ ├── context.js // context.js 处理应用上下文，里面直接封装部分 request.js 和 response.js 的方法
│ ├── request.js // request.js 处理 http 请求
│ └── response.js // response.js 处理 http 响应
├── package.json
└── test // 测试模块
├── application
….
package.json
jest 做测试
node 版本
{
“engines”: {
“node”: “^4.8.4 || ^6.10.1 || ^7.10.1 || >= 8.1.4”
}
}
主入口：“main”: “lib/application.js”
koa 核心模块
封装的 http server（node）
核心对象 context, request、response
中间件机制和剥洋葱模型的实现
错误捕获和错误处理
源码
application.jsapplication.js 是 koa 的入口，继承了 events , 所以框架有事件监听和事件触发的能力。application 还暴露了一些常用的 api，比如 toJSON、listen、use 等等。
context.js
request.js
response.js
特殊处理
委托
摘自 context.js：context.js
const proto = module.exports = {
// …
};
delegate(proto, ‘response’)
.method(‘attachment’)
.method(‘redirect’)
.method(‘remove’)
.method(‘vary’)
.method(‘set’)
.method(‘append’)
.method(‘flushHeaders’)
.access(‘status’)
.access(‘message’)
.access(‘body’)
.access(‘length’)
.access(‘type’)
.access(‘lastModified’)
.access(‘etag’)
.getter(‘headerSent’)
.getter(‘writable’);
delegate(proto, ‘request’)
.method(‘acceptsLanguages’)
.method(‘acceptsEncodings’)
.method(‘acceptsCharsets’)
.method(‘accepts’)
.method(‘get’)
.method(‘is’)
.access(‘querystring’)
.access(‘idempotent’)
.access(‘socket’)
.access(‘search’)
.access(‘method’)
.access(‘query’)
.access(‘path’)
.access(‘url’)
.access(‘accept’)
.getter(‘origin’)
.getter(‘href’)
.getter(‘subdomains’)
.getter(‘protocol’)
.getter(‘host’)
.getter(‘hostname’)
.getter(‘URL’)
.getter(‘header’)
.getter(‘headers’)
.getter(‘secure’)
.getter(‘stale’)
.getter(‘fresh’)
.getter(‘ips’)
.getter(‘ip’);
koa 为了方便串联中间件，提供了一个 context 对象，并且把核心的 response，request 对象挂载在上面，但是这样往往就造成使用上写法冗余，eg：ctx.response.body, 而且某些对象还是经常使用的，这很不方便，所以产生了 delegates 库，用于委托操作, 委托之后，就可以在 ctx 上直接使用部分委托属性：ctx.body。源码分析如下
delegates 源码解析
delegates 库源码文件
middleware 机制
koa-compose
koa 中 use 用来注册中间件，实际上是将多个中间件放入一个缓存队列中 this.middleware.push(fn);，然后通过 koa-compose 这个插件进行递归组合。
因此严格来讲 middleware 的执行结构的组织并不在 koa 源码中完成，而是在依赖库 koa-compose 中。koa 中使用：const fn = compose(this.middleware); 完成中间件的组合。
koa-compose 核心逻辑如下，主要思路大致是：通过包装 middleware List 返回一个 组装好的执行器。组装思路是：将下一个 middleware 进行包装【执行器 + promise 化】作为上一个 middleware 的 next【dispatch.bind(null, i + 1)】。同时给中间件提供 context 对象。
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
// 函数洋葱的最后补上一个 Promise.resolve();
if (!fn) return Promise.resolve()
try {
// middleware 是 async 函数，返回 promise。Promise.resolve 确保中间件执行完成
// 提供 ctx，next fn: dispatch.bind(null, i + 1)
return Promise.resolve(fn(context, dispatch.bind(null, i + 1)));
} catch (err) {
return Promise.reject(err)
}
}
}
koa-compose
koa-compose 是一个非常精简的库，不做单独分析了，他提供了一种主调型的递归: fn(context, dispatch.bind(null, i + 1)) , 这种方式可以认为是 ’ 懒递归 ’，将递归的执行交给主调者控制，这样能够在更合适的时机执行后续处理, 但如果某个中间件不调用 next，那么其后的中间件就不被执行了。这和 js 协程【generator】有机制上的类似，都是使用者来控制 next 的执行时机，可类比学习。
generator
易用性处理
koa 非常易用，原因是 koa 在源码层面做了大量的 委托 和针对复杂对象的封装，如 request, response 的 get/set. 用以提高工具的可用度，易用度。实际上我认为这一点是现代框架非常重要的东西，脱离用户的库都不是好库。koa 是好库。
delegates 上面说过，参考：delegates。
get/set
request, response 两个文件千行代码，80% 左右的都是 get、set，参考：
request.js
response.js
另一方面，表现在 application.js 的 createContext 方法中，通过挂载引用和委托配合 get set 的实践配合提升易用度，单独不太好讲，分析注释在源码中。
异常捕获
中间件异常捕获，koa1 中间件基于 generator + co, koa2 中间件基于 async/await, async 函数返回 promise，所以只要在组合中间件后 catch 即可捕获中间件异常 fnMiddleware(ctx).then(handleResponse).catch(onerror);
框架层发生错误的捕获机制, 这个通过继承 event 模块很容易实现监听。this.on(‘error’, this.onerror); 注册的 error 事件，在 context.onerror 中被 emit this.app.emit(‘error’, err, this);
http 异常处理：Execute a callback when a HTTP request closes, finishes, or errors.onFinished(res, onerror); // application.handleRequest
中间件交互
初用中间件可能会有一个疑问：中间件如何通信？
事实上这是个设计取舍逻辑, 中间件之间的数据交互并不是麻烦事，特别是在 ECMAScript 推出 async await 之后，但问题是这样做的意义不大，原因是所有的中间件是可任意插拔组合的，这种不确定性，导致了中间件之间的数据交互就变得不稳定，最起码的数据格式就没办法固定，就更别谈处理了。灵活的插件机制导致中间件之间的交互难有统一层面的实现。
另一方面从中间件的定位来看，其之间也没必要交互，中间件不能脱离 http 的请求响应而独立存在，他是服务于整个过程的，也因此所有的中间件第一个参数就是 ctx，这个对象挂载了 request 和 response，以及 koa 提供的封装和工具操作。
核心点
中断
这是洋葱圈非常核心的支撑点, 我们稍微留意就能发现 koa 中间件执行机制于普通 js 的执行顺序很不一致, 我们看如下代码：
app.use(async (cxt, next) => {
Log(1);
await next();
Log(2);
});
app.use(async (cxt, next) => {
Log(3);
await next();
Log(4);
});
上述代码执行顺序也就是洋葱圈：Log(1) -> await next (Log(3)) -> await next -> Log(4) -> Log(2).
为了保证代码按照洋葱模型的执行顺序执行，程序需要在调用 next 的时候让代码等待，我称之为中断。
实际上以前想要实现这种执行顺序，只能依赖 cb，promise.then 来模拟，而且即便实现了，在写法上也显得臃肿和别扭，要么是写出很胖的函数，要么是写出很长的函数。而且没法处理调用栈的问题。
async/await 可以比较优雅的实现这种具有同步执行特征的前端代码来处理异步，代码执行到 await 这里，等待 await 表达式的执行，执行完成之后，接着往后执行。
实际上这很类似于 generator 的 yield，特性。async 也就是 generator + 执行器的一个语法糖, 参考：
async / await
co
generator
async？no，it’s generator
koa.use 得确直接使用 async 函数处理中间件及其中可能存在的异步, 而 async/await 实现上是基于 generator。async 在使用上可讲的点通常在他的 task 放在哪，以及执行时机 和 timeout，promise 的执行顺序等。真正的中断特性得益于 generator。
一位不愿透漏姓名的同事问了我一个问题，怎么证明 async 是 generator + 执行器 的语法糖？这是不得不讨论一个问题。相关的讨论参考：Async / Await > #generator 部分探讨
生态
koa 中间件并没有一个统一的 market 之类的地方，说实话找起来不是那么方便。如果你想找中间件的话，可以在 npm 上用 koa- 做关键字检索：https://www.npmjs.com/search?…
官方 middleware
源码使用的中间件
koa-compose 上面已有分析
koa-is-json
function isJSON(body) {
if (!body) return false;
if (‘string’ == typeof body) return false;
if (‘function’ == typeof body.pipe) return false;
if (Buffer.isBuffer(body)) return false;
return true;
}
koa-convert 用于兼容处理 generator 中间件，基本可以认为是 co + generator 中间件【也依赖 koa-compose 进行组织】
other koa
社区常用中间件合集：some middleware
参考 & 鸣谢
https://koa.bootcss.com/
http://nodejs.cn/api/fs.html#…
https://juejin.im/post/5ba786…