Ⅰ Koa 学习总结
Koa是基于Node.js的下一代web框架，由Express团队打造，特点：优雅、简洁、灵活、体积小。几乎所有功能都需要通过中间件实现。
即便没有给ctx.body 设置响应数据，或访问不存在的路由，页面也会显示Not Found，这是koa底层做了处理，不像原生Node或Express一样页面会一直处于响应状态。
Koa将Node的request 和 response对象都封装到了context中，每次请求都会创建一个ctx，并且在中间件中作为接收器使用。
以下是刚才访问时的ctx对象
即便使用ctx.res.write()也不会得到预期结果，比如：ctx.res.write('hello')，结果是hellook，会把message的值拼接上。
有关cookie和session单独介绍用法。
Koa中的路由和Express不同，Express是把路由集成在Express中，Koa则需要通过kao-router模块使用。
Koa最大的特色和最优的设计就是中间件，就是在匹配路由之前和匹配路由之后执行函数。
使用app.use()加载中间件。每个中间件接收两个参数，ctx对象和next函数，通过调用next将执行权交给下一个中间件。
中间件分为：
对于诸如js、css、img等静态资源采用koa-static中间件处理。
比如静态目录为static：
在模板中即可访问：
koa生态的模板引擎挺多的，比如ejs、art-template等。
使用方式和ejs一样。
性能上相比，art-template比ejs快很多，开发中用的最多的还是art-template。
http是无状态、无连接的。不会对之前发生过的请求和相应状态进行管理团物。也就是说，无法根据之前的状态进行本塌喊液次的请求处理。
比如访问淘宝首页并登录账号后，当再打开淘宝其他页面时，因为每一次的访问都是独立的，服务器并不知道你已经登录，所以还是不能下单或者加购物车之类的操作。
cookie是客户端第一次访问服务器的时候，服务器在下行HTTP报文时通过响应头的 set-cookie 字段给浏览器分配的一个具有特殊标识的文本信息，此后当客户端再次访问同一域名时，便会将该字段通过请求头携带到服务器。注意： 第一次访问服务器是不可能携带cookie的。
缺陷： 1、cookie的数据存放在客户端，不安全，容易被（CSRF）跨站请求伪造。攻击者可以借助受害者的 Cookie 骗取服务器的信任，可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器，从而在并未授权的情况下执行在权限保护之下的操作。2、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
通过 options 获取 cookie name:
通过 options 设置 cookie name 的 value:
通过buffer转成base64存进去，取出来是再转回中文。
session是另一种记录客户状态的机制，不同的是cookie保存在客户端浏览器中，而session保存在服务器上。
前面说过，cookie 是存放在客户端，不是很安全，用户可以自己手动把cookie种在客户端以欺骗服务器。而session是存储在服务渗樱端的，所以对于较重要的数据存储在session。
缺点： session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能。
当浏览器第一次请求服务器时，服务器端会创建一个session对象，生成一个类似于key-value的键值对， 然后将key(cookie)下发到客户端，当客户端再访问时，携带key(cookie)，找到对应的session(value)。 生产中用户的信息都保存在session中。
以上配置选项常用的就是key、maxAge、httpOver。
renew应用：比如我们登录账号写一篇博客，写了一半cookie过期了，当我们提交的时候就会退出登录，体验很不好，而且写好的博客丢失。
301和302重定向状态码区别。302为临时重定向，301永久重定向。Koa中默认为302。详细信息查看这篇博客 301和302重定向介绍
字符串 “back” 是特别提供Referrer支持的，当Referrer不存在时，使用 alt 或“/”。
要更改 “302” 的默认状态，只需在该调用之前或之后分配状态。要变更主体请在此调用之后:
解决跨域的方式有很多种，个人认为最好的方案是在服务器端设置支持跨域。
下面详细说明在koa2中设置具体的请求头信息：
在koa2中，解决跨域请求还可使用中间件 koa2-cors
node 发送邮件可以使用 nodemailer 三方模块。
安装：
使用说明：
更多详细配置信息及功能参照 官网
Ⅱ koa-基于node.js平台的下一代web开发框架入门
koa 是由 Express 原班人马打造的，致力于成为一个更小、更富有表现力、更健壮的 Web 框架。使用 koa 编写 web 应用，通过组合不同的 generator，可以免除重复繁琐的回调函数嵌套，并极大地提升错误处理的效率。koa 不在内核方法中绑定任何中间件，它仅仅提供了一个轻量优雅的函数库，使得编写 Web 应用变得得心应手。
Koa需要 node v7.6.0或更高版本来支持ES2015、异步方法
你可以安装自己支持的node版本。
在node < 7.6的版本中使用async 函数, 我们推荐使用babel's require hook.
为了解析和转译异步函数，你应该至少有transform-async-to-generator or transform-async-to-mole-method这2个插件。例如，在你的.babelrc文件中，应该有如下代码
也可以使用env preset并设置"node": "current"来替代.
Koa 应用是一个包含一系列中间件 generator 函数的对象。 这些中间件函数基于 request 请求以一个类似于栈的结构组成并依次执行。 Koa 类似于其他中间件系统（比如 Ruby's Rack 、Connect 等）， 然而 Koa 的核心设计思路是为中间源哪枝件层提供高级语法糖封装，以增强其互用性和健壮性，并使得编写中间件变得相当有趣。
Koa 包缓伏含了像 content-negotiation（内容协商）、cache freshness（缓存刷新）、proxy support（代理支持）和 redirection（重定向）等常用任务方法。 与提供庞大的函数支持不同，Koa只包含很小的一部分，因为Koa并不绑定任何中间件。
任何教程都是从 hello world 开始的，Koa也不例外^_^:
Koa 的中间件通过一种更加传统（您也许会很熟悉）的方式进行级联，摒弃雹敏了以往 node 频繁的回调函数造成的复杂代码逻辑。 然而，使用异步函数，我们可以实现"真正" 的中间件。与之不同，当执行到 yield next 语句时，Koa 暂停了该中间件，继续执行下一个符合请求的中间件('downstrem')，然后控制权再逐级返回给上层中间件('upstream')。
下面的例子在页面中返回 "Hello World"，然而当请求开始时，请求先经过 x-response-time 和 logging 中间件，并记录中间件执行起始时间。 然后将控制权交给 reponse 中间件。当一个中间件调用next()函数时，函数挂起并控件传递给定义的下一个中间件。在没有更多的中间件执行下游之后，堆栈将退出，并且每个中间件被恢复以执行其上游行为。
应用配置是 app 实例属性，目前支持的配置项如下：
Koa 应用并非是一个 1-to-1 表征关系的 HTTP 服务器。 一个或多个Koa应用可以被挂载到一起组成一个包含单一 HTTP 服务器的大型应用群。
如下为一个绑定3000端口的简单 Koa 应用，其创建并返回了一个 HTTP 服务器，为 Server#listen() 传递指定参数（参数的详细文档请查看nodejs.org）。
The app.listen(...) 实际上是以下代码的语法糖:
这意味着您可以同时支持 HTTPS 和 HTTPS，或者在多个端口监听同一个应用。
返回一个适合 http.createServer() 方法的回调函数用来处理请求。 您也可以使用这个回调函数将您的app挂载在 Connect/Express 应用上。
为应用添加指定的中间件，详情请看 Middleware
设置签名cookie密钥。
该密钥会被传递给KeyGrip, 当然，您也可以自己生成 KeyGrip. 例如:
在进行cookie签名时，只有设置 signed 为 true 的时候，才会使用密钥进行加密：
app.context是从中创建ctx的原型。 可以通过编辑app.context向ctx添加其他属性。当需要将ctx添加到整个应用程序中使用的属性或方法时，这将会非常有用。这可能会更加有效（不需要中间件）和/或更简单（更少的require()），而不必担心更多的依赖于ctx，这可以被看作是一种反向模式。
例如，从ctx中添加对数据库的引用：
注:
默认情况下Koa会将所有错误信息输出到 stderr， 除非 app.silent 是 true.当err.status是404或者err.expose时，默认错误处理程序也不会输出错误。要执行自定义错误处理逻辑，如集中式日志记录，您可以添加一个"错误"事件侦听器：
如果错误发生在 请求/响应 环节，并且其不能够响应客户端时，Contenxt 实例也会被传递到 error 事件监听器的回调函数里。
当发生错误但仍能够响应客户端时（比如没有数据写到socket中），Koa会返回一个500错误(Internal Server Error)。 无论哪种情况，Koa都会生成一个应用级别的错误信息，以便实现日志记录等目的。
Koa Context 将 node 的 request 和 response 对象封装在一个单独的对象里面，其为编写 web 应用和 API 提供了很多有用的方法。 这些操作在 HTTP 服务器开发中经常使用，因此其被添加在上下文这一层，而不是更高层框架中，因此将迫使中间件需要重新实现这些常用方法。
context 在每个 request 请求中被创建，在中间件中作为接收器(receiver)来引用，或者通过 this 标识符来引用：
许多 context 的访问器和方法为了便于访问和调用，简单的委托给他们的 ctx.request 和 ctx.response 所对应的等价方法， 比如说 ctx.type 和 ctx.length 代理了 response 对象中对应的方法，ctx.path 和 ctx.method 代理了 request 对象中对应的方法。
Ⅲ express和koa的区别
express和koa从整体上来看，koa是比express更加轻量，他没有内置的各种中间件的支持，更集中于请求处理。当然在express 4.0以后，也移除了一批中间件支持，向轻量化进发。这一点上差别其实不是特别大了。
最大的差别是中间件和回调的处理逻辑。express采用的是callback，koa采用的是async，这样在执行上铅者贺express的callback中就天然不支持异步的处理，在express中处理异步可能不是你想要的执行顺序。在这里，就有了koa的经典：洋葱模型。
除此之外，koa在响应上添加了上下文的概念，使用ctx存储各种响应信息，避免直接操作res。ctx能更好的帮助我们在多层级处理中传递信息，例如ctx.body可以多层级进行组合返回数槐派据。
express 3 -> 4 之后，移除了一大批中间件，其中和我们关系比较大的是bodyParser、compress、cookieSession、cookieParser、static、directory等。
除此之外，4改变了路由注册的方式（增量式），嫌谈增加了app.route、router = express.Router()的方式，中间件的app.use也支持path的注册。详见 Moving to Express 4 。
传送门
express和koa的区别
Ⅳ 如何优雅的在 koa 中处理错误
使用中间件统一处理错误
有了上面的说明，那现在我们就来看看在 koa 里面怎么优雅的实现统一错误处理。
答案就是使用强大的中间件！
我们可以在业务逻辑中间件（一般就是 MVC 中的 Controller）开始之前定义下面的中间件：
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
app.use(function* (next) {
try {
yield* next;
} catch(e) {
let status = e.status || 500;
let message = e.message || '服务器错误';
if (e instanceof JsonError) { // 错误是 json 错误
this.body = {
'status': status,
'message': message
};
if (status == 500) {
// 触发 koa 统一错误事件，可以打印出详细的错误堆栈 log
this.app.emit('error', e, this);
}
return;
}
this.status = status;
// 根据 status 渲染不同的页面
if (status == 403) {
this.body = yield this.render('403.html', {'err': e});
}
if (status == 404) {
this.body = yield this.render('404.html', {'err': e});
}
if (status == 500) {
this.body = yield this.render('500.html', {'err': e});
// 触发 koa 统一错误事件，可以打印出详细的错误堆栈 log
this.app.emit('error', e, this);
}
}
});
可以看到，我们直接执行 yield* next，然后 catch 执行过程中任何一个中间件的错误，然后根据错误的“特性”，分别进行不同的处理。
有了这个中间件，我们的业务逻辑 controller 中的代码就可以这样来触发错误：
JavaScript
1
2
3
4
5
6
7
8
9
10
11
const router = new (require('koa-router'));
router.get('/some_page', function* () {
// 直接抛出错误，被中间件捕获后当成 500 错误
throw new PageError('发生了一个致命错误');
throw new JsonError('发送了一个致命错误');
// 带 status 的错误，被中间件捕获后特殊处理
this.throw(403, new PageError('没有权限访问'));
this.throw(403, new JsonError('没有权限访问'));
});
对 Error 分类
上面的代码里面出现的 JsonError、PageError，实际上是继承于 Error 的两个构造器。代码如下：
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
const util = require('util');
exports.JsonError = JsonError;
exports.PageError = PageError;
function JsonError(message) {
Error.call(this, message);
}
util.inherits(JsonError, Error);
function PageError(message) {
Error.call(this, message);
}
util.inherits(PageError, Error);
通过继承 Error 构造器，我们可以将错误进行细分，从而能更精细的对错误进行处理。
Ⅳ nodejs-koa2（mvc模式）前后端分离 前端设计
前后端分离，前端nodejs运行环境，使用koa2集成负责资源分配与用户交互，实现token验证用户身份，路由控制。等！
自行 网络 解决；
"program": "${workspaceFolder}app.js"
此处就是是将app.js作为启动文件。${workspaceFolder}代表根目录，vsc启动时会在根目录下找到并加载app.js文件。
参数介绍： name 项目名称、 version 版本号、 description 项目描述、 main 项目启动文件、 scripts 启动快捷设置， author 作者， dependencies 第3方中间件名称及版本。
最重要的
“ dependencies ”这里添加一些要用到的包，以上是这次要用到的所有的包，版本自己更改。
“ scripts ”这里是一些nodejs的便捷命令，上线的时候会用到，直接在终端中，package.json同级目录 ，执行‘npm start’ 即 可启动app.js。
别的没啥太大作用瞎写即可。
启动相关配置，封装到config/init.js中，启动文件直接引用即可
3-6-1、init.js项目核心。
异常友好处理方法封装
路由配置
视图渲染
核心集成
3-6-2、config.js项目参数配置。为什么不用json文件 因为json不能加注释
3-6-3、token.js项目token相关方法封装。
执行后项目结构会增加两个文件
新增
src/hello.js。
views/index.html
浏览器访问： http://127.0.0.1:3000/koa/login
输入值获取token
获取的token如图：
先不用带token进行访问: http://127.0.0.1:3000/koa/ hello/jiaobaba,被token拦截，返回401
带上token访问： http://127.0.0.1:3000/koa/ hello/jiaobaba
测试页面渲染，及跳转html页面，直接访问 http://127.0.0.1:3000/koa /views
结束！！！！！！
需要源码联系我