摘要：本文来自心谭博客深入源码架构设计前端面试设计模式手册教程实战等更多专题，请来导航页领取食用所有系列文章都放在了。欢迎交流和最近读了的源码，理清楚了架构设计与用到的第三方库。
本文来自《心谭博客·深入koa源码：架构设计》
前端面试、设计模式手册、Webpack4教程、NodeJs实战等更多专题，请来导航页领取食用
所有系列文章都放在了Github。欢迎交流和Star ✿✿ ヽ(°▽°)ノ ✿
最近读了 koa 的源码，理清楚了架构设计与用到的第三方库。本系列将分为 3 篇，分别介绍 koa 的架构设计和 3 个核心库的原理，最终会手动实现一个简易的 koa。
koa 的实现都在仓库的lib目录下，如下图所示，只有 4 个文件：
对于这四个文件，根据用途和封装逻辑，可以分为 3 类：req 和 res，上下文以及 application。
req 和 res对应的文件是：request.js 和 response.js。分别代表着客户端请求信息和服务端返回信息。
这两个文件在实现逻辑上完全一致。对外暴露都是一个对象，对象上的属性都使用了getter或setter来实现读写控制。
上下文对应的文件是：context.js。存了运行环境的上下文信息，例如cookies。
除此之外，因为request和response都属于上下文信息，所以通过delegate.js库来实现了对request.js和response.js上所有属性的代理。例如以下代码：
/**
* Response delegation.
*/
delegate(proto, "response")
.method("attachment")
.method("redirect");
/**
* Request delegation.
*/
delegate(proto, "request")
.method("acceptsLanguages")
.method("acceptsEncodings");
使用代理的另外一个好处就是：更方便的访问 req 和 res 上的属性。比如在开发 koa 应用的时候，可以通过ctx.headers来读取客户端请求的头部信息，不需要写成ctx.res.headers了（这样写没错）。
注意：req 和 res 并不是在context.js中被绑定到上下文的，而是在application被绑定到上下文变量ctx中的。原因是因为每个请求的 req/res 都不是相同的。
Application对应的文件是: application.js。这个文件的逻辑是最重要的，它的作用主要是：
给用户暴露服务启动接口
针对每个请求，生成新的上下文
处理中间件，将其串联
对外暴露接口使用 koa 时候，我们常通过listen或者callback来启动服务器：
const app = new Koa(); app.listen(3000); // listen启动 http.createServer(app.callback()).listen(3000); // callback启动
这两种启动方法是完全等价的。因为listen方法内部，就调用了callback，并且将它传给http.createServer。接着看一下callback这个方法主要做了什么：
调用koa-compose将中间件串联起来（下文再讲）。
生成传给http.createServer()的函数，并且返回。
http.createServer传给函数参数的请求信息和返回信息，都被这个函数拿到了。并且传给createContext方法，生成本次请求的上下文。
将生成的上下文传给第 1 步生成的中间件调用链，这就是为什么我们在中间件处理逻辑的时候能够访问ctx
生成新的上下文这里上下文的方法对应的是createContext方法。这里我觉得更像语法糖，是为了让 koa 使用者使用更方便。比如以下这段代码：
// this.request 是 request.js 暴露出来的对象，将其引用保存在context.request中 // 用户可以直接通过 ctx.属性名 来访问对应属性 const request = (context.request = Object.create(this.request)); // 这个req是本次请求信息，是由 http.createServer 传递给回调函数的 context.req = request.req = response.req = req;
读到这里，虽然可以解释 ctx.headers 是 ctx.request.headers 的语法糖这类问题。但是感觉怪怪的。就以这个例子，ctx.headers 访问的是 ctx.reqeust 上的 headers，而不是本次请求信息上的headers。本次请求信息挂在了ctx.req上。
让我们再回到reqeust.js的源码，看到了headers的 getter 实现：
get headers() {
return this.req.headers;
}
ok，看来这里的this就是指的上下文环境咯。那么肯定是在application.js中某个地方改变了this的指向。果然，在application.js的构造函数中可以看到：
this.request = Object.create(request);
application 实例上的 request 被传递给了 context.request，此时 this 自然指向了 context。
可以看到，koa 为了让开发者使用方便，在上下文上做了很多工作。
中间件机制中间件的设计是 koa 最重要的部分，实现上用到了koa-compose库来串联中间件，形成“洋葱模型”。关于这个库，放在第二篇关于 koa 核心库的介绍中说明。
application 中处理中间件的函数是use和handleRequest：
use函数：传入async/await函数，并将其放入 application 实例上的middleware数组中。如果传入是 generator，会调用koa-conver库将其转化为async/await函数。
handleRequest(ctx, fnMiddleware)函数：传入的fnMiddleware是已经串联好的中间件，函数所做的工作就是再其后再添加一个返回给客户端的函数和错误处理函数。返回给客户端的函数其实就是respond函数，里面通过调用res.end()来向客户端返回信息，整个流程就走完了。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/104916.html
摘要：最近读了的源码，理清楚了架构设计与用到的第三方库。本系列将分为篇，分别介绍的架构设计和个核心库，最终会手动实现一个简易的。本文来自心谭博客深入源码核心库原理所有系列文章都放在了。这一段逻辑封装在了核心库里面。 最近读了 koa2 的源码，理清楚了架构设计与用到的第三方库。本系列将分为 3 篇，分别介绍 koa 的架构设计和 3 个核心库，最终会手动实现一个简易的 koa。这是系列第 2...
摘要：阅读好的框架的源码有很多好处，从大神的视角去理解整个框架的设计思想。使用其实某个框架阅读源码的时候，首先我们要会去用这个框架，因为用了我们才知道，某个是怎么用，哪里有坑，哪里设计的精妙。 阅读好的框架的源码有很多好处，从大神的视角去理解整个框架的设计思想。大到架构设计，小到可取的命名风格，还有设计模式、实现某类功能使用到的数据结构和算法等等。 使用koa 其实某个框架阅读源码的时候，首...
摘要：阅读好的框架的源码有很多好处，从大神的视角去理解整个框架的设计思想。使用其实某个框架阅读源码的时候，首先我们要会去用这个框架，因为用了我们才知道，某个是怎么用，哪里有坑，哪里设计的精妙。 阅读好的框架的源码有很多好处，从大神的视角去理解整个框架的设计思想。大到架构设计，小到可取的命名风格，还有设计模式、实现某类功能使用到的数据结构和算法等等。 使用koa 其实某个框架阅读源码的时候，首...
摘要：感谢大神的免费的计算机编程类中文书籍收录并推荐地址，以后在仓库里更新地址，声音版全文狼叔如何正确的学习简介现在，越来越多的科技公司和开发者开始使用开发各种应用。 说明 2017-12-14 我发了一篇文章《没用过Node.js，就别瞎逼逼》是因为有人在知乎上黑Node.js。那篇文章的反响还是相当不错的，甚至连著名的hax贺老都很认同，下班时读那篇文章，竟然坐车的还坐过站了。大家可以很...
摘要：感谢大神的免费的计算机编程类中文书籍收录并推荐地址，以后在仓库里更新地址，声音版全文狼叔如何正确的学习简介现在，越来越多的科技公司和开发者开始使用开发各种应用。 说明 2017-12-14 我发了一篇文章《没用过Node.js，就别瞎逼逼》是因为有人在知乎上黑Node.js。那篇文章的反响还是相当不错的，甚至连著名的hax贺老都很认同，下班时读那篇文章，竟然坐车的还坐过站了。大家可以很...
阅读 3476·2021-09-06 15:13
阅读 1526·2021-09-02 10:19
阅读 2473·2019-08-30 15:52
阅读 917·2019-08-29 15:25
阅读 1564·2019-08-26 18:36
阅读 495·2019-08-26 13:23
阅读 1331·2019-08-26 10:46
阅读 3498·2019-08-26 10:41
