引子​

在编写代码时，我们应该有一些方法将程序像连接水管一样连接起来 -- 当我们需要获取一些数据时，可以去通过"拧"其他的部分来达到目的。这也应该是 IO 应有的方式。 -- Doug McIlroy. October 11, 1964

从早先的 unix开始，stream 便开始进入了人们的视野，在过去的几十年的时间里，它被证明是一种可依赖的编程方式，它可以将一个大型的系统拆成一些很小的部分，并且让这些部分之间完美地进行合作。在 unix 中，我们可以使用|符号来实现流。在 node 中，node 内置的stream 模块已经被多个核心模块使用，同时也可以被用户自定义的模块使用。和 unix 类似，node 中的流模块的基本操作符叫做.pipe()，同时你也可以使用一个后压机制来应对那些对数据消耗较慢的对象。

在 node 中，流可以帮助我们将事情的重点分为几份，因为使用流可以帮助我们将实现接口的部分分割成一些连续的接口，这些接口都是可重用的。接着，你可以将一个流的输出口接到另一个流的输入口，然后使用使用一些库来对流实现高级别的控制。

对于小型程序设计(small-program design)以及 unix 哲学来说，流都是一个重要的组成部分，但是除此之外还有一些重要的事情值得我们思考。永远要记得：双鸟在林不如一鸟在手。

为什么应该使用流​

在 node 中，I/O 都是异步的，所以在和硬盘以及网络的交互过程中会涉及到传递回调函数的过程。你之前可能会写出这样的代码：

var http = require("http");
var fs = require("fs");

var server = http.createServer(function(req, res) {
  fs.readFile(__dirname + "/data.txt", function(err, data) {
    res.end(data);
  });
});
server.listen(8000);

上面的这段代码并没有什么问题，但是在每次请求时，我们都会把整个data.txt文件读入到内存中，然后再把结果返回给客户端。想想看，如果data.txt文件非常大，在响应大量用户的并发请求时，程序可能会消耗大量的内存，这样很可能会造成用户连接缓慢的问题。

其次，上面的代码可能会造成很不好的用户体验，因为用户在接收到任何的内容之前首先需要等待程序将文件内容完全读入到内存中。

所幸的是，(req,res)参数都是流对象，这意味着我们可以使用一种更好的方法来实现上面的需求：

var http = require("http");
var fs = require("fs");

var server = http.createServer(function(req, res) {
  var stream = fs.createReadStream(__dirname + "/data.txt");
  stream.pipe(res);
});
server.listen(8000);

在这里，.pipe()方法会自动帮助我们监听data和end事件。上面的这段代码不仅简洁，而且data.txt文件中每一小段数据都将源源不断的发送到客户端。

除此之外，使用.pipe()方法还有别的好处，比如说它可以自动控制后端压力，以便在客户端连接缓慢的时候 node 可以将尽可能少的缓存放到内存中。

想要将数据进行压缩？我们可以使用相应的流模块完成这项工作!

var http = require("http");
var fs = require("fs");
var oppressor = require("oppressor");

var server = http.createServer(function(req, res) {
  var stream = fs.createReadStream(__dirname + "/data.txt");
  stream.pipe(oppressor(req)).pipe(res);
});
server.listen(8000);

通过上面的代码，我们成功的将发送到浏览器端的数据进行了 gzip 压缩。我们只是使用了一个 oppressor 模块来处理这件事情。

一旦你学会使用流 api，你可以将这些流模块像搭乐高积木或者像连接水管一样拼凑起来，从此以后你可能再也不会去使用那些没有流 API 的模块获取和推送数据了。

流模块基础​

在 node 中，一共有五种类型的流：readable,writable,transform,duplex 以及"classic"

pipe​

无论哪一种流，都会使用.pipe()方法来实现输入和输出。

.pipe()函数很简单，它仅仅是接受一个源头src并将数据输出到一个可写的流dst中：

src.pipe(dst);

.pipe(dst)将会返回dst因此你可以链式调用多个流:

a.pipe(b)
  .pipe(c)
  .pipe(d);

上面的代码也可以等价为：

a.pipe(b);
b.pipe(c);
c.pipe(d);

这和你在 unix 中编写流代码很类似：

a | b | c | d

只不过此时你是在 node 中编写而不是在 shell 中！

readable 流​

Readable 流可以产出数据，你可以将这些数据传送到一个 writable，transform 或者 duplex 流中，只需要调用pipe()方法:

readableStream.pipe(dst);

创建一个 readable 流​

现在我们就来创建一个 readable 流！

var Readable = require("stream").Readable;

var rs = new Readable();
rs.push("beep ");
rs.push("boop\n");
rs.push(null);

rs.pipe(process.stdout);

下面运行代码：

$ node read0.js
beep boop

在上面的代码中rs.push(null)的作用是告诉rs输出数据应该结束了。

需要注意的一点是我们在将数据输出到process.stdout之前已经将内容推送进 readable 流rs中，但是所有的数据依然是可写的。

这是因为在你使用.push()将数据推进一个 readable 流中时，一直要到另一个东西来消耗数据之前，数据都会存在一个缓存中。

然而，在更多的情况下，我们想要的是当需要数据时数据才会产生，以此来避免大量的缓存数据。

我们可以通过定义一个._read函数来实现按需推送数据:

var Readable = require("stream").Readable;
var rs = Readable();

var c = 97;
rs._read = function() {
  rs.push(String.fromCharCode(c++));
  if (c > "z".charCodeAt(0)) rs.push(null);
};

rs.pipe(process.stdout);

代码的运行结果如下所示:

$ node read1.js
abcdefghijklmnopqrstuvwxyz

在这里我们将字母a到z推进了 rs 中，但是只有当数据消耗者出现时，数据才会真正实现推送。

_read函数也可以获取一个size参数来指明消耗者想要读取多少比特的数据，但是这个参数是可选的。

需要注意到的是你可以使用util.inherit()来继承一个 Readable 流。

为了说明只有在数据消耗者出现时，_read函数才会被调用，我们可以将上面的代码简单的修改一下：

var Readable = require("stream").Readable;
var rs = Readable();

var c = 97 - 1;

rs._read = function() {
  if (c >= "z".charCodeAt(0)) return rs.push(null);

  setTimeout(function() {
    rs.push(String.fromCharCode(++c));
  }, 100);
};

rs.pipe(process.stdout);

process.on("exit", function() {
  console.error("\n_read() called " + (c - 97) + " times");
});
process.stdout.on("error", process.exit);

运行上面的代码我们可以发现如果我们只请求 5 比特的数据，那么_read只会运行 5 次：

$ node read2.js | head -c5
abcde
_read() called 5 times

在上面的代码中，setTimeout很重要，因为操作系统需要花费一些时间来发送程序结束信号。

另外,process.stdout.on('error',fn)处理器也很重要，因为当head不再关心我们的程序输出时，操作系统将会向我们的进程发送一个SIGPIPE信号，此时process.stdout将会捕获到一个EPIPE错误。

上面这些复杂的部分在和操作系统相关的交互中是必要的，但是如果你直接和 node 中的流交互的话，则可有可无。

如果你创建了一个 readable 流，并且想要将任何的值推送到其中的话，确保你在创建流的时候指定了 objectMode 参数,Readable({ objectMode: true })。

消耗一个 readable 流​

大部分时候，将一个 readable 流直接 pipe 到另一种类型的流或者使用 through 或者 concat-stream 创建的流中，是一件很容易的事情。但是有时我们也会需要直接来消耗一个 readable 流。

process.stdin.on("readable", function() {
  var buf = process.stdin.read();
  console.dir(buf);
});

代码运行结果如下所示：

$ (echo abc; sleep 1; echo def; sleep 1; echo ghi) | node consume0.js
<Buffer 61 62 63 0a>
<Buffer 64 65 66 0a>
<Buffer 67 68 69 0a>
null

当数据可用时，readable事件将会被触发，此时你可以调用.read()方法来从缓存中获取这些数据。

当流结束时，.read()将返回null，因为此时已经没有更多的字节可以供我们获取了。

你也可以告诉.read()方法来返回n个字节的数据。虽然所有核心对象中的流都支持这种方式，但是对于对象流来说这种方法并不可用。

下面是一个例子，在这里我们制定每次读取 3 个字节的数据：

process.stdin.on("readable", function() {
  var buf = process.stdin.read(3);
  console.dir(buf);
});

运行上面的例子，我们将获取到不完整的数据:

$ (echo abc; sleep 1; echo def; sleep 1; echo ghi) | node consume1.js
<Buffer 61 62 63>
<Buffer 0a 64 65>
<Buffer 66 0a 67>

这是因为多余的数据都留在了内部的缓存中，因此这个时候我们需要告诉 node 我们还对剩下的数据感兴趣，我们可以使用.read(0)来完成这件事：

process.stdin.on("readable", function() {
  var buf = process.stdin.read(3);
  console.dir(buf);
  process.stdin.read(0);
});

到现在为止我们的代码和我们所期望的一样了！

$ (echo abc; sleep 1; echo def; sleep 1; echo ghi) | node consume2.js
<Buffer 61 62 63>
<Buffer 0a 64 65>
<Buffer 66 0a 67>
<Buffer 68 69 0a>

我们也可以使用.unshift()方法来放置多余的数据。

使用unshift()方法能够防止我们进行不必要的缓存拷贝。在下面的代码中我们将创建一个分割新行的可读解析器:

var offset = 0;

process.stdin.on("readable", function() {
  var buf = process.stdin.read();
  if (!buf) return;
  for (; offset < buf.length; offset++) {
    if (buf[offset] === 0x0a) {
      console.dir(buf.slice(0, offset).toString());
      buf = buf.slice(offset + 1);
      offset = 0;
      process.stdin.unshift(buf);
      return;
    }
  }
  process.stdin.unshift(buf);
});

代码的运行结果如下所示：

$ tail -n +50000 /usr/share/dict/american-english | head -n10 | node lines.js
'hearties'
'heartiest'
'heartily'
'heartiness'
'heartiness\'s'
'heartland'
'heartland\'s'
'heartlands'
'heartless'
'heartlessly'

当然，已经有很多这样的模块比如 split 来帮助你完成这件事情，你完全不需要自己写一个。

writable 流​

一个 writable 流指的是只能流进不能流出的流:

src.pipe(writableStream);

创建一个 writable 流​

只需要定义一个._write(chunk,enc,next)函数，你就可以将一个 readable 流的数据释放到其中：

var Writable = require("stream").Writable;
var ws = Writable();
ws._write = function(chunk, enc, next) {
  console.dir(chunk);
  next();
};

process.stdin.pipe(ws);

代码运行结果如下所示：

$ (echo beep; sleep 1; echo boop) | node write0.js
<Buffer 62 65 65 70 0a>
<Buffer 62 6f 6f 70 0a>

第一个参数，chunk代表写进来的数据。

第二个参数enc代表编码的字符串，但是只有在opts.decodeString为false的时候你才可以写一个字符串。

第三个参数，next(err)是一个回调函数，使用这个回调函数你可以告诉数据消耗者可以写更多的数据。你可以有选择性的传递一个错误对象error，这时会在流实体上触发一个emit事件。

在从一个 readable 流向一个 writable 流传数据的过程中，数据会自动被转换为Buffer对象，除非你在创建 writable 流的时候制定了decodeStrings参数为false,Writable({decodeStrings: false})。

如果你需要传递对象，需要指定objectMode参数为true，Writable({ objectMode: true })。

向一个 writable 流中写东西​

如果你需要向一个 writable 流中写东西，只需要调用.write(data)即可。

process.stdout.write('beep boop\n');

为了告诉一个 writable 流你已经写完毕了，只需要调用.end()方法。你也可以使用.end(data)在结束前再写一些数据。

var fs = require("fs");
var ws = fs.createWriteStream("message.txt");

ws.write("beep ");

setTimeout(function() {
  ws.end("boop\n");
}, 1000);

运行结果如下所示:

$ node writing1.js
   $ cat message.txt
beep boop

如果你需要调整内部缓冲区大小，那么需要在创建可写流对象时设置highWaterMark。在调用.write()方法返回 false 时，说明写入的数据大小超过了该值。

为了避免读写速率不匹配而造成内存上涨，可以监听drain事件，等待可写流内部缓存被清空再继续写入。

transform 流  ​

你可以将 transform 流想象成一个流的中间部分，它可以读也可写，但是并不保存数据，它只负责处理流经它的数据。

duplex 流​

Duplex 流是一个可读也可写的流，就好像一个电话，可以接收也可以发送语音。一个 rpc 交换是一个 duplex 流的最好的例子。如果你看到过下面这样的代码：

a.pipe(b).pipe(a);

那么你需要处理的就是一个 duplex 流对象。

classic 流​

Classic 流是一个古老的接口，最早出现在 node 0.4 中。虽然现在不怎么用，但是我们最好还是来了解一下它的工作原理。

无论何时，只要一个流对象注册了一个data监听器，它就会自动的切换到classic模式，并且根据旧 API 的方式运行。

classic readable 流​

Classic readable 流只是一个事件发射器，当有数据消耗者出现时发射emit事件，当输出数据完毕时发射end事件。

我们可以同构检查stream.readable来检查一个 classic 流对象是否可读。

下面是一个简单的 readable 流对象的例子，程序的运行结果将会输出A到J：

var Stream = require("stream");
var stream = new Stream();
stream.readable = true;

var c = 64;
var iv = setInterval(function() {
  if (++c >= 75) {
    clearInterval(iv);
    stream.emit("end");
  } else stream.emit("data", String.fromCharCode(c));
}, 100);

stream.pipe(process.stdout);

运行结果如下所示:

$ node classic0.js
ABCDEFGHIJ

为了从一个 classic readable 流中读取数据，你可以注册data和end监听器。下面是一个使用旧 readable 流方式从process.stdin中读取数据的例子:

process.stdin.on("data", function(buf) {
  console.log(buf);
});
process.stdin.on("end", function() {
  console.log("**END**");
});

运行结果如下所示:

$ (echo beep; sleep 1; echo boop) | node classic1.js
<Buffer 62 65 65 70 0a>
<Buffer 62 6f 6f 70 0a>
**END**

需要注意的一点是当你在一个流对象上注册了一个data监听器，你就将这个流放在了兼容模式下，此时你不能使用两个 stream2 的 api。

如果你自己创建流对象，永远不要绑定data和end监听器。如果你需要和旧版本的流兼容，最好使用第三方库来实现.pipe()方法。

例如，你可以使用 through 模块来避免显式的使用data和end监听器:

var through = require("through");
process.stdin.pipe(through(write, end));

function write(buf) {
  console.log(buf);
}
function end() {
  console.log("**END**");
}

程序运行结果如下所示:

$ (echo beep; sleep 1; echo boop) | node through.js
<Buffer 62 65 65 70 0a>
<Buffer 62 6f 6f 70 0a>
**END**

你也可以使用 concat-stream 模块来将整个流的内容缓存起来:

var concat = require("concat-stream");
process.stdin.pipe(
  concat(function(body) {
    console.log(JSON.parse(body));
  })
);

程序运行结果如下所示:

$ echo '{"beep":"boop"}' | node concat.js
{ beep: 'boop' }

Classic readable 流拥有.pause()和.resume()逻辑来暂停一个流，但是这都是可选的。如果你想要使用.pause()和.resume()方法，你应该使用 through 模块来帮助你处理缓存。

classic writable 流​

Classic writable 流非常简单。其中只定义了.write(buf)，.end(buf)，以及.desctory()方法。其中.end(buf)的参数 buf 是可选参数，但是一般来说 node 程序员还是喜欢使用.end(buf)这种写法。

接下来读什么​

• node 核心 stream 模块文档
• 你可以使用readable-stream模块来确保你的 stream2 代码兼容 node 0.8 及其之前的代码。在你npm install readable-stream之后直接require('readable-stream')而不要require('stream')。

本文参考自 stream-handbook，原文地址https://github.com/substack/stream-handbook

欢迎! 首先您应该知道的三件事情:

1. 当您读到这里，实际上您读了很多关于 Node.js 的优秀文章 - 这是对 Node.js 最佳实践中排名最高的内容的总结和分享

2. 这里是最大的汇集，且每周都在增长 - 当前，超过 50 个最佳实现，样式指南，架构建议已经呈现。每天都有新的 issue 和 PR 被创建，以使这本在线书籍不断更新。我们很乐于见到您能在这里做出贡献，不管是修复一些代码的错误，或是提出绝妙的新想法。请查看我们的milestones

3. 大部分的条目包含额外的信息 - 大部分的最佳实践条目的旁边，您将发现 🔗Read More 链接，它将呈现给您示例代码，博客引用和更多信息

目录​

1. 项目结构实践 (5)
2. 异常处理实践 (11)
3. 编码规范实践 (12)
4. 测试和总体质量实践 (8)
5. 进入生产实践 (16)
6. ⭐ 新: 安全实践(23)
7. Performance Practices (coming soon)

1. 项目结构实践

1.1 组件式构建你的解决方案​

TL;DR: 大型项目的最坏的隐患就是维护一个庞大的，含有几百个依赖的代码库 - 当开发人员准备整合新的需求的时候，这样一个庞然大物势必减缓了开发效率。反之，把您的代码拆分成组件，每一个组件有它自己的文件夹和代码库，并且确保每一个组件小而简单。查看正确的项目结构的例子请访问下面的 ‘更多’ 链接。

否则: 当编写新需求的开发人员逐步意识到他所做改变的影响，并担心会破坏其他的依赖模块 - 部署会变得更慢，风险更大。当所有业务逻辑没有被分开，这也会被认为很难扩展

🔗 更多: 组件结构

1.2 分层设计组件，保持 Express 在特定的区域​

TL;DR: 每一个组件都应该包含'层级' - 一个专注的用于接入网络，逻辑，数据的概念。这样不仅获得一个清晰的分离考量，而且使仿真和测试系统变得异常容易。尽管这是一个普通的模式，但接口开发者易于混淆层级关系，比如把网络层的对象（Express req, res）传给业务逻辑和数据层 - 这会令您的应用彼此依赖，并且只能通过 Express 使用。

否则: 对于混淆了网络层和其它层的应用，将不易于测试，执行 CRON 的任务，其它非-Express 的调用者无法使用

🔗 更多: 应用分层

1.3 封装公共模块成为 NPM 的包​

TL;DR: 由大量代码构成的一个大型应用中，贯彻全局的，比如日志，加密和其它类似的公共组件，应该进行封装，并暴露成一个私有的 NPM 包。这将使其在更多的代码库和项目中被使用变成了可能。

否则: 您将不得不重造部署和依赖的轮子

🔗 更多: 通过需求构建

1.4 分离 Express 'app' and 'server'​

TL;DR: 避免定义整个Express应用在一个单独的大文件里， 这是一个不好的习惯 - 分离您的 'Express' 定义至少在两个文件中： API 声明(app.js) 和 网络相关(WWW)。对于更好的结构，是把你的 API 声明放在组件中。

否则: 您的 API 将只能通过 HTTP 的调用进行测试（慢，并且很难产生测试覆盖报告）。维护一个有着上百行代码的文件也不是一个令人开心的事情。

🔗 更多: 分离 Express 'app' and 'server'

1.5 使用易于设置环境变量，安全和分级的配置​

TL;DR: 一个完美无瑕的配置安装应该确保 (a) 元素可以从文件中，也可以从环境变量中读取 (b) 密码排除在提交的代码之外 (c) 为了易于检索，配置是分级的。仅有几个包可以满足这样的条件，比如rc, nconf 和 config。

否则: 不能满足任意的配置要求将会使开发，运维团队，或者两者，易于陷入泥潭。

🔗 更多: 配置最佳实践

2. 错误处理最佳实践

2.1 使用 Async-Await 和 promises 用于异步错误处理​

TL;DR: 使用回调的方式处理异步错误可能是导致灾难的最快的方式(a.k.a the pyramid of doom)。对您的代码来说，最好的礼物就是使用规范的 promise 库或 async-await 来替代，这会使其像 try-catch 一样更加简洁，具有熟悉的代码结构。

否则: Node.js 回调特性, function(err, response), 是导致不可维护代码的一个必然的方式。究其原因，是由于混合了随意的错误处理代码，臃肿的内嵌，蹩脚的代码模式。

🔗 更多: 避免回调

2.2 仅使用内建的错误对象​

TL;DR: 很多人抛出异常使用字符串类型或一些自定义类型 - 这会导致错误处理逻辑和模块间的调用复杂化。是否您 reject 一个 promise，抛出异常或发出(emit)错误 - 使用内建的错误对象将会增加设计一致性，并防止信息的丢失。

否则: 调用某些模块，将不确定哪种错误类型会返回 - 这将会使恰当的错误处理更加困难。更坏的情况是，使用特定的类型描述错误，会导致重要的错误信息缺失，比如 stack trace！

🔗 更多: 使用内建错误对象

2.3 区分运行错误和程序设计错误​

TL;DR: 运行错误（例如, API 接受到一个无效的输入）指的是一些已知场景下的错误，这类错误的影响已经完全被理解，并能被考虑周全的处理掉。同时，程序设计错误（例如，尝试读取未定义的变量）指的是未知的编码问题，影响到应用得当的重启。

否则: 当一个错误产生的时候，您总是得重启应用，但为什么要让 ~5000 个在线用户不能访问，仅仅是因为一个细微的，可以预测的，运行时错误？相反的方案，也不完美 – 当未知的问题（程序问题）产生的时候，使应用依旧可以访问，可能导致不可预测行为。区分两者会使处理更有技巧，并在给定的上下文下给出一个平衡的对策。

🔗 更多: 运行错误和程序设计错误

2.4 集中处理错误，不要在 Express 中间件中处理错误​

TL;DR: 错误处理逻辑，比如给管理员发送邮件，日志应该封装在一个特定的，集中的对象当中，这样当错误产生的时候，所有的终端（例如 Express 中间件，cron 任务，单元测试）都可以调用。

否则: 错误处理的逻辑不放在一起将会导致代码重复和非常可能不恰当的错误处理。

🔗 更多: 集中处理错误

2.5 对 API 错误使用 Swagger 文档化​

TL;DR: 让你的 API 调用者知道哪种错误会返回，这样他们就能完全的处理这些错误，而不至于系统崩溃。Swagger，REST API 的文档框架，通常处理这类问题。

否则: 任何 API 的客户端可能决定崩溃并重启，仅仅因为它收到一个不能处理的错误。注意：API 的调用者可能是你（在微服务环境中非常典型）。

🔗 更多: 使用 Swagger 记录错误

2.6 当一个特殊的情况产生，停掉服务是得体的​

TL;DR: 当一个不确定错误产生（一个开发错误，最佳实践条款#3) - 这就意味着对应用运转健全的不确定。一个普通的实践将是建议仔细地重启进程，并使用一些‘启动器’工具，比如 Forever 和 PM2。

否则: 当一个未知的异常被抛出，意味着某些对象包含错误的状态（例如某个全局事件发生器由于某些内在的错误，不在产生事件），未来的请求可能失败或者行为异常。

🔗 更多: 停掉服务

2.7 使用一个成熟的日志工具提高错误的可见性​

TL;DR: 一系列成熟的日志工具，比如 Winston，Bunyan 和 Log4J，会加速错误的发现和理解。忘记 console.log 吧。

否则: 浏览 console 的 log，和不通过查询工具或者一个好的日志查看器，手动浏览繁琐的文本文件，会使你忙于工作到很晚。

🔗 更多: 使用好用的日志工具

2.8 使用你最喜欢的测试框架测试错误流​

TL;DR: 无论专业的自动化测试或者简单的手动开发测试 - 确保您的代码不仅满足正常的场景，而且处理并且返回正确的错误。测试框架，比如 Mocha & Chai 可以非常容易的处理这些问题（在"Gist popup"中查看代码实例） 。

否则: 没有测试，不管自动还是手动，您不可能依赖代码去返回正确的错误。而没有可以理解的错误，那将毫无错误处理可言。

🔗 更多: 测试错误流向

2.9 使用 APM 产品发现错误和宕机时间​

TL;DR: 监控和性能产品 (别名 APM) 先前一步的检测您的代码库和 API，这样他们能自动的，像使用魔法一样的强调错误，宕机和您忽略的性能慢的部分。

否则: 您花了很多的力气在测量 API 的性能和错误，但可能您从来没有意识到真实场景下您最慢的代码块和他们对 UX 的影响。

🔗 更多: 使用 APM 产品

2.10 捕获未处理的 promise rejections​

TL;DR: 任何在 promise 中被抛出的异常将被收回和遗弃，除非开发者没有忘记去明确的处理。即使您的代码调用的是 process.uncaughtException！解决这个问题可以注册到事件 process.unhandledRejection。

否则: 您的错误将被回收，无踪迹可循。没有什么可以需要考虑。

🔗 更多: 捕获未处理的 promise rejection

2.11 快速查错，验证参数使用一个专门的库​

TL;DR: 这应该是您的 Express 最佳实践中的一部分 – assert API 输入避免难以理解的漏洞，这类漏洞以后会非常难以追踪。而验证代码通常是一件乏味的事情，除非使用一些非常炫酷的帮助库比如 Joi。

否则: 考虑这种情况 – 您的功能期望一个数字参数 “Discount” ，然而调用者忘记传值，之后在您的代码中检查是否 Discount!=0 （允许的折扣值大于零），这样它将允许用户使用一个折扣。OMG，多么不爽的一个漏洞。你能明白吗？

🔗 更多: 快速查错

3. 编码风格实践

3.1 使用 ESLint​

TL;DR: ESLint是检查可能的代码错误和修复代码样式的事实上的标准，不仅可以识别实际的间距问题, 而且还可以检测严重的反模式代码, 如开发人员在不分类的情况下抛出错误。尽管 ESlint 可以自动修复代码样式，但其他的工具比如prettier和beautify在格式化修复上功能强大，可以和 Eslint 结合起来使用。

否则: 开发人员将必须关注单调乏味的间距和线宽问题, 并且时间可能会浪费在过多考虑项目的代码样式。

3.2 Node.js 特定的插件​

TL;DR: 除了仅仅涉及 vanilla JS 的 ESLint 标准规则，添加 Node 相关的插件，比如eslint-plugin-node, eslint-plugin-mocha and eslint-plugin-node-security

否则: 许多错误的 Node.js 代码模式可能在检测下逃生。例如，开发人员可能需要某些文件，把一个变量作为路径名 (variableAsPath) ，这会导致攻击者可以执行任何 JS 脚本。Node.JS linters 可以检测这类模式，并及早预警。

3.3 在同一行开始一个代码块的大括号​

TL;DR: 代码块的第一个大括号应该和声明的起始保持在同一行中。

代码示例​

// 建议
function someFunction() {
  // 代码块
}

// 避免
function someFunction() {
  // 代码块
}

否则: 不遵守这项最佳实践可能导致意外的结果，在 Stackoverflow 的帖子中可以查看到，如下：

🔗 更多: "Why does a results vary based on curly brace placement?" (Stackoverflow)

3.4 不要忘记分号​

TL;DR: 即使没有获得一致的认同，但在每一个表达式后面放置分号还是值得推荐的。这将使您的代码, 对于其他阅读代码的开发者来说，可读性，明确性更强。

否则: 在前面的章节里面已经提到，如果表达式的末尾没有添加分号，JavaScript 的解释器会在自动添加一个，这可能会导致一些意想不到的结果。

3.5 命名您的方法​

TL;DR: 命名所有的方法，包含闭包和回调, 避免匿名方法。当剖析一个 node 应用的时候，这是特别有用的。命名所有的方法将会使您非常容易的理解内存快照中您正在查看的内容。

否则: 使用一个核心 dump（内存快照）调试线上问题，会是一项非常挑战的事项，因为你注意到的严重内存泄漏问题极有可能产生于匿名的方法。

3.6 变量、常量、函数和类的命名约定​

TL;DR: 当命名变量和方法的时候，使用 lowerCamelCase ，当命名类的时候，使用 UpperCamelCase （首字母大写），对于常量，则 UPPERCASE 。这将帮助您轻松地区分普通变量/函数和需要实例化的类。使用描述性名称，但使它们尽量简短。

否则: JavaScript 是世界上唯一一门不需要实例化，就可以直接调用构造函数（"Class"）的编码语言。因此，类和函数的构造函数由采用 UpperCamelCase 开始区分。

代码示例​

  // 使用UpperCamelCase命名类名
  class SomeClassExample () {

    // 常量使用const关键字，并使用lowerCamelCase命名
    const config = {
      key: 'value'
    };

    // 变量和方法使用lowerCamelCase命名
    let someVariableExample = 'value';
    function doSomething() {

    }

  }

3.7 使用 const 优于 let，废弃 var​

TL;DR: 使用const意味着一旦一个变量被分配，它不能被重新分配。使用 const 将帮助您免于使用相同的变量用于不同的用途，并使你的代码更清晰。如果一个变量需要被重新分配，以在一个循环为例，使用let声明它。let 的另一个重要方面是，使用 let 声明的变量只在定义它的块作用域中可用。 var是函数作用域，不是块级作用域，既然您有 const 和 let 让您随意使用，那么不应该在 ES6 中使用 var。

否则: 当经常更改变量时，调试变得更麻烦了。

🔗 更多: JavaScript ES6+: var, let, or const?

3.8 先 require, 而不是在方法内部​

TL;DR: 在每个文件的起始位置，在任何函数的前面和外部 require 模块。这种简单的最佳实践，不仅能帮助您轻松快速地在文件顶部辨别出依赖关系，而且避免了一些潜在的问题。

否则: 在 Node.js 中，require 是同步运行的。如果从函数中调用它们，它可能会阻塞其他请求，在更关键的时间得到处理。另外，如果所 require 的模块或它自己的任何依赖项抛出错误并使服务器崩溃，最好尽快查明它，如果该模块在函数中 require 的，则可能不是这样的情况。

3.9 require 文件夹，而不是文件​

TL;DR: 当在一个文件夹中开发库/模块，放置一个文件 index.js 暴露模块的 内部，这样每个消费者都会通过它。这将作为您模块的一个接口，并使未来的变化简单而不违反规则。

否则: 更改文件内部结构或签名可能会破坏与客户端的接口。

代码示例​

// 建议
module.exports.SMSProvider = require("./SMSProvider");
module.exports.SMSNumberResolver = require("./SMSNumberResolver");

// 避免
module.exports.SMSProvider = require("./SMSProvider/SMSProvider.js");
module.exports.SMSNumberResolver = require("./SMSNumberResolver/SMSNumberResolver.js");

3.10 使用 === 操作符​

TL;DR: 对比弱等于 ==，优先使用严格的全等于 === 。==将在它们转换为普通类型后比较两个变量。在 === 中没有类型转换，并且两个变量必须是相同的类型。

否则: 与 == 操作符比较，不相等的变量可能会返回 true。

代码示例​

"" == "0"; // false
0 == ""; // true
0 == "0"; // true

false == "false"; // false
false == "0"; // true

false == undefined; // false
false == null; // false
null == undefined; // true

" \t\r\n " == 0; // true

如果使用===， 上面所有语句都将返回 false。

3.11 使用 Async Await, 避免回调​

TL;DR: Node 8 LTS 现已全面支持异步等待。这是一种新的方式处理异步请求，取代回调和 promise。Async-await 是非阻塞的，它使异步代码看起来像是同步的。您可以给你的代码的最好的礼物是用 async-await 提供了一个更紧凑的，熟悉的，类似 try catch 的代码语法。

否则: 使用回调的方式处理异步错误可能是陷入困境最快的方式 - 这种方式必须面对不停地检测错误，处理别扭的代码内嵌，难以推理编码流。

🔗更多: async await 1.0 引导

3.12 使用 (=>) 箭头函数​

TL;DR: 尽管使用 async-await 和避免方法作为参数是被推荐的, 但当处理那些接受 promise 和回调的老的 API 的时候 - 箭头函数使代码结构更加紧凑，并保持了根方法上的语义上下文 (例如 'this')。

否则: 更长的代码（在 ES5 方法中）更易于产生缺陷，并读起来很是笨重。

🔗 更多: 这是拥抱箭头函数的时刻

4. 测试和总体的质量实践

4.1 至少，编写 API（组件）测试​

TL;DR: 大多数项目只是因为时间表太短而没有进行任何自动化测试，或者测试项目失控而正被遗弃。因此，优先从 API 测试开始，这是最简单的编写和提供比单元测试更多覆盖率的事情（你甚至可能不需要编码而进行 API 测试，像Postman。之后，如果您有更多的资源和时间，继续使用高级测试类型，如单元测试、DB 测试、性能测试等。

否则: 您可能需要花很长时间编写单元测试，才发现只有 20%的系统覆盖率。

4.2 使用一个 linter 检测代码问题​

TL;DR: 使用代码 linter 检查基本质量并及早检测反模式。在任何测试之前运行它, 并将其添加为预提交的 git 钩子, 以最小化审查和更正任何问题所需的时间。也可在Section 3中查阅编码样式实践

否则: 您可能让一些反模式和易受攻击的代码传递到您的生产环境中。

4.3 仔细挑选您的持续集成（CI）平台​

TL;DR: 您的持续集成平台（cicd）将集成各种质量工具（如测试、lint），所以它应该是一个充满活力的生态系统，包含各种插件。jenkins曾经是许多项目的默认选项，因为它有最大的社区，同时也是一个非常强大的平台，这样的代价是要求一个陡峭的学习曲线。如今，使用 SaaS 工具，比如CircleCI及其他，安装一套 CI 解决方案，相对是一件容易的事情。这些工具允许构建灵活的 CI 管道，而无需管理整个基础设施。最终，这是一个鲁棒性和速度之间的权衡 - 仔细选择您支持的方案。

否则: 一旦您需要一些高级定制，选择一些细分市场供应商可能会让您停滞不前。另一方面，伴随着 jenkins，可能会在基础设施设置上浪费宝贵的时间。

🔗 更多: 挑选 CI 平台

4.4 经常检查易受攻击的依赖​

TL;DR: 即使是那些最有名的依赖模块，比如 Express，也有已知的漏洞。使用社区和商业工具，比如 🔗 npm audit ，集成在您的 CI 平台上，在每一次构建的时候都会被调用，这样可以很容易地解决漏洞问题。

否则: 在没有专用工具的情况下，使代码清除漏洞，需要不断地跟踪有关新威胁的在线出版物，相当繁琐。

4.5 测试标签化​

TL;DR: 不同的测试必须运行在不同的情景：quick smoke，IO-less，当开发者保存或提交一个文件，测试应该启动；完整的端到端的测试通常运行在一个新的 pull request 被提交之后，等等。这可以通过对测试用例设置标签，比如关键字像#cold #api #sanity，来完成。这样您可以对您的测试集进行 grep，调用需要的子集。例如，这就是您通过Mocha仅仅调用 sanity 测试集所需要做的：mocha --grep 'sanity'。

否则: 运行所有的测试，包括执行数据库查询的几十个测试，任何时候开发者进行小的改动都可能很慢，这使得开发者不愿意运行测试。

4.6 检查测试覆盖率，它有助于识别错误的测试模式​

TL;DR: 代码覆盖工具比如 Istanbul/NYC，很好用有 3 个原因：它是免费的（获得这份报告不需要任何开销），它有助于确定测试覆盖率降低的部分，以及最后但非最不重要的是它指出了测试中的不匹配：通过查看颜色标记的代码覆盖报告您可以注意到，例如，从来不会被测到的代码片段像 catch 语句（即测试只是调用正确的路径，而不调用应用程序发生错误时的行为）。如果覆盖率低于某个阈值，则将其设置为失败的构建。

否则: 当你的大部分代码没有被测试覆盖时，就不会有任何自动化的度量指标告诉你了。

4.7 检查过期的依赖包​

TL;DR: 使用您的首选工具 (例如 “npm outdated” or npm-check-updates 来检测已安装的过期依赖包, 将此检查注入您的 CI 管道, 甚至在严重的情况下使构建失败。例如, 当一个已安装的依赖包滞后 5 个补丁时 (例如:本地版本是 1.3.1 的, 存储库版本是 1.3.8 的), 或者它被其作者标记为已弃用, 可能会出现严重的情况 - 停掉这次构建并防止部署此版本。

否则: 您的生产环境将运行已被其作者明确标记为有风险的依赖包

4.8 对于 e2e testing，使用 docker-compose​

TL;DR: 端对端(e2e)测试包含现场数据，由于它依赖于很多重型服务如数据库，习惯被认为是 CI 过程中最薄弱的环节。Docker-compose 通过制定类似生产的环境，并使用一个简单的文本文件和简单的命令，轻松化解了这个问题。它为了 e2e 测试，允许制作所有相关服务，数据库和隔离网络。最后但并非最不重要的一点是，它可以保持一个无状态环境，该环境在每个测试套件之前被调用，然后立即消失。

否则: 没有 docker-compose，团队必须维护一个测试数据库在每一个测试环境上，包含开发机器，保持所有数据同步，这样测试结果不会因环境不同而不同。

5. 上线实践

5.1. 监控!​

TL;DR: 监控是一种在顾客之前发现问题的游戏 – 显然这应该被赋予前所未有的重要性。考虑从定义你必须遵循的基本度量标准开始（我的建议在里面），到检查附加的花哨特性并选择解决所有问题的解决方案。市场已经淹没其中。点击下面的 ‘The Gist’ ，了解解决方案的概述。

否则: 错误 === 失望的客户. 非常简单.

🔗 更多: 监控!

5.2. 使用智能日志增加透明度​

TL;DR: 日志可以是调试语句的一个不能说话的仓库，或者表述应用运行过程的一个漂亮仪表板的驱动。从第 1 天计划您的日志平台：如何收集、存储和分析日志，以确保所需信息（例如，错误率、通过服务和服务器等完成整个事务）都能被提取出来。

否则: 您最终像是面对一个黑盒，不知道发生了什么事情，然后你开始重新写日志语句添加额外的信息。

🔗 更多: 使用智能日志增加透明度

5.3. 委托可能的一切（例如：gzip，SSL）给反向代理​

TL;DR: Node 处理 CPU 密集型任务，如 gzipping，SSL termination 等，表现糟糕。相反，使用一个 ‘真正’ 的中间件服务像 Nginx，HAProxy 或者云供应商的服务。

否则: 可怜的单线程 Node 将不幸地忙于处理网络任务，而不是处理应用程序核心，性能会相应降低。

🔗 更多: 委托可能的一切（例如：gzip，SSL）给反向代理

5.4. 锁住依赖​

TL;DR: 您的代码必须在所有的环境中是相同的，但是令人惊讶的是，NPM 默认情况下会让依赖在不同环境下发生偏移 – 当在不同的环境中安装包的时候，它试图拿包的最新版本。克服这种问题可以利用 NPM 配置文件， .npmrc，告诉每个环境保存准确的（不是最新的）包的版本。另外，对于更精细的控制，使用 NPM “shrinkwrap”。*更新：作为 NPM5，依赖默认锁定。新的包管理工具，Yarn，也默认锁定。

否则: QA 测试通过的代码和批准的版本，在生产中表现不一致。更糟糕的是，同一生产集群中的不同服务器可能运行不同的代码。

🔗 更多: 锁住依赖

5.5. 使用正确的工具保护进程正常运行​

TL;DR: 进程必须继续运行，并在失败时重新启动。对于简单的情况下，“重启”工具如 PM2 可能足够，但在今天的“Dockerized”世界 – 集群管理工具也值得考虑

否则: 运行几十个实例没有明确的战略和太多的工具（集群管理，docker，PM2）可能导致一个 DevOps 混乱

🔗 更多: 使用正确的工具保护进程正常运行

5.6. 利用 CPU 多核​

TL;DR: 在基本形式上，node 应用程序运行在单个 CPU 核心上，而其他都处于空闲状态。复制 node 进程和利用多核，这是您的职责 – 对于中小应用，您可以使用 Node Cluster 和 PM2. 对于一个大的应用，可以考虑使用一些 Docker cluster（例如 k8s，ECS）复制进程或基于 Linux init system（例如 systemd）的部署脚本

否则: 您的应用可能只是使用了其可用资源中的 25% (!)，甚至更少。注意，一台典型的服务器有 4 个或更多的 CPU，默认的 Node.js 部署仅仅用了一个 CPU（甚至使用 PaaS 服务，比如 AWS beanstalk，也一样）。

🔗 更多: 利用所有的 CPU

5.7. 创建一个“维护端点”​

TL;DR: 在一个安全的 API 中暴露一组系统相关的信息，比如内存使用情况和 REPL 等等。尽管这里强烈建议依赖标准和作战测试工具，但一些有价值的信息和操作更容易使用代码完成。

否则: 您会发现，您正在执行许多“诊断部署” – 将代码发送到生产中，仅仅只为了诊断目的提取一些信息。

🔗 更多: 创建一个 '维护端点'

5.8. 使用 APM 产品发现错误和宕机时间​

TL;DR: 监控和性能的产品（即 APM）先前一步地评估代码库和 API，自动的超过传统的监测，并测量在服务和层级上的整体用户体验。例如，一些 APM 产品可以突显导致最终用户负载过慢的事务，同时指出根本原因。

否则: 你可能会花大力气测量 API 性能和停机时间，也许你永远不会知道，真实场景下哪个是你最慢的代码部分，这些怎么影响用户体验。

🔗 更多: 使用 APM 产品发现错误和宕机时间

5.9. 使您的代码保持生产环境就绪​

TL;DR: 在意识中抱着最终上线的想法进行编码，从第 1 天开始计划上线。这听起来有点模糊，所以我编写了一些与生产维护密切相关的开发技巧（点击下面的要点）

否则: 一个世界冠军级别的 IT/运维人员也不能拯救一个编码低劣的系统。

🔗 更多: 使您的代码保持生产环境就绪

5.10. 测量和保护内存使用​

TL;DR: Node.js 和内存有引起争论的联系：V8 引擎对内存的使用有稍微的限制（1.4GB），在 node 的代码里面有内存泄漏的很多途径 – 因此监视 node 的进程内存是必须的。在小应用程序中，你可以使用 shell 命令周期性地测量内存，但在中等规模的应用程序中，考虑把内存监控建成一个健壮的监控系统。

否则: 您的内存可能一天泄漏一百兆，就像曾发生在沃尔玛的一样。

🔗 更多: 测量和保护内存使用

5.11. Node 外管理您的前端资源​

TL;DR: 使用专门的中间件（nginx，S3，CDN）服务前端内容，这是因为在处理大量静态文件的时候，由于 node 的单线程模型，它的性能很受影响。

否则: 您的单个 node 线程将忙于传输成百上千的 html/图片/angular/react 文件，而不是分配其所有的资源为了其擅长的任务 – 服务动态内容

🔗 更多: Node 外管理您的前端资源

5.12. 保持无状态，几乎每天都要停下服务器​

TL;DR: 在外部数据存储上，存储任意类型数据（例如用户会话，缓存，上传文件）。考虑间隔地停掉您的服务器或者使用 ‘serverless’ 平台（例如 AWS Lambda），这是一个明确的强化无状态的行为。

否则: 某个服务器上的故障将导致应用程序宕机，而不仅仅是停用故障机器。此外，由于依赖特定服务器，伸缩弹性会变得更具挑战性。

🔗 更多: 保持无状态，几乎每天都要停下服务器

5.13. 使用自动检测漏洞的工具​

TL;DR: 即使是最有信誉的依赖项，比如 Express，会有使系统处于危险境地的已知漏洞（随着时间推移）。通过使用社区的或者商业工具，不时的检查漏洞和警告（本地或者 Github 上），这类问题很容易被抑制，有些问题甚至可以立即修补。

否则: 否则: 在没有专用工具的情况下，使代码清除漏洞，需要不断地跟踪有关新威胁的在线出版物。相当繁琐。

🔗 更多: 使用自动检测漏洞的工具

5.14. 在每一个 log 语句中指明 ‘TransactionId’​

TL;DR: 在每一个请求的每一条 log 入口，指明同一个标识符，transaction-id: {某些值}。然后在检查日志中的错误时，很容易总结出前后发生的事情。不幸的是，由于 Node 异步的天性自然，这是不容易办到的，看下代码里面的例子

否则: 在没有上下文的情况下查看生产错误日志，这会使问题变得更加困难和缓慢去解决。

🔗 更多: 在每一个 log 语句中指明 ‘TransactionId’

5.15. 设置 NODE_ENV=production​

TL;DR: 设置环境变量 NODE_ENV 为‘production’ 或者 ‘development’，这是一个是否激活上线优化的标志 - 很多 NPM 的包通过它来判断当前的环境，据此优化生产环境代码。

否则: 遗漏这个简单的属性可能大幅减弱性能。例如，在使用 Express 作为服务端渲染页面的时候，如果未设置 NODE_ENV，性能将会减慢大概三分之一！

🔗 更多: 设置 NODE_ENV=production

5.16. 设计自动化、原子化和零停机时间部署​

TL;DR: 研究表明，执行许多部署的团队降低了严重上线问题的可能性。不需要危险的手动步骤和服务停机时间的快速和自动化部署大大改善了部署过程。你应该达到使用 Docker 结合 CI 工具，使他们成为简化部署的行业标准。

否则: 长时间部署 -> 线上宕机 & 和人相关的错误 -> 团队部署时不自信 -> 更少的部署和需求

6. 安全最佳实践

6.1. 拥护 linter 安全准则​

TL;DR: 使用安全相关的 linter 插件，比如eslint-plugin-security，尽早捕获安全隐患或者问题，最好在编码阶段。这能帮助察觉安全的问题，比如使用 eval，调用子进程，或者根据字面含义（比如，用户输入）引入模块等等。点击下面‘更多’获得一个安全 linter 可以检测到的代码示例。

Otherwise: 在开发过程中, 可能一个直白的安全隐患, 成为生产环境中一个严重问题。此外, 项目可能没有遵循一致的安全规范, 而导致引入漏洞, 或敏感信息被提交到远程仓库中。

🔗 更多: Lint 规范

6.2. 使用中间件限制并发请求​

TL;DR: DOS 攻击非常流行而且相对容易处理。使用外部服务，比如 cloud 负载均衡, cloud 防火墙, nginx, 或者（对于小的，不是那么重要的 app）一个速率限制中间件(比如express-rate-limit)，来实现速率限制。

否则: 应用程序可能受到攻击, 导致拒绝服务, 在这种情况下, 真实用户会遭受服务降级或不可用。

🔗 更多: 实施速率限制

6.3 把机密信息从配置文件中抽离出来，或者使用包对其加密​

TL;DR: 不要在配置文件或源代码中存储纯文本机密信息。相反, 使用诸如 Vault 产品、Kubernetes/Docker Secrets 或使用环境变量之类的安全管理系统。最后一个结果是, 存储在源代码管理中的机密信息必须进行加密和管理 (滚动密钥(rolling keys)、过期时间、审核等)。使用 pre-commit/push 钩子防止意外提交机密信息。

否则: 源代码管理, 即使对于私有仓库, 也可能会被错误地公开, 此时所有的秘密信息都会被公开。外部组织的源代码管理的访问权限将无意中提供对相关系统 (数据库、api、服务等) 的访问。

🔗 更多: 安全管理

6.4. 使用 ORM/ODM 库防止查询注入漏洞​

TL;DR: 要防止 SQL/NoSQL 注入和其他恶意攻击, 请始终使用 ORM/ODM 或 database 库来转义数据或支持命名的或索引的参数化查询, 并注意验证用户输入的预期类型。不要只使用 JavaScript 模板字符串或字符串串联将值插入到查询语句中, 因为这会将应用程序置于广泛的漏洞中。所有知名的 Node.js 数据访问库(例如Sequelize, Knex, mongoose)包含对注入漏洞的内置包含措施。

否则: 未经验证或未脱敏处理的用户输入，可能会导致操作员在使用 MongoDB 进行 NoSQL 操作时进行注入, 而不使用适当的过滤系统或 ORM 很容易导致 SQL 注入攻击, 从而造成巨大的漏洞。

🔗 更多: 使用 ORM/ODM 库防止查询注入

6.5. 通用安全最佳实际集合​

TL;DR: 这些是与 Node.js 不直接相关的安全建议的集合-Node 的实现与任何其他语言没有太大的不同。单击 "阅读更多" 浏览。

🔗 更多: 通用安全最佳实际

6.6. 调整 HTTP 响应头以加强安全性​

TL;DR: 应用程序应该使用安全的 header 来防止攻击者使用常见的攻击方式，诸如跨站点脚本(XSS)、点击劫持和其他恶意攻击。可以使用模块，比如 helmet轻松进行配置。

否则: 攻击者可以对应用程序的用户进行直接攻击, 导致巨大的安全漏洞

🔗 更多: 在应用程序中使用安全的 header

6.7. 经常自动检查易受攻击的依赖库​

TL;DR: 在 npm 的生态系统中, 一个项目有许多依赖是很常见的。在找到新的漏洞时, 应始终将依赖项保留在检查中。使用工具，类似于npm audit 或者 snyk跟踪、监视和修补易受攻击的依赖项。将这些工具与 CI 设置集成, 以便在将其上线之前捕捉到易受攻击的依赖库。

否则: 攻击者可以检测到您的 web 框架并攻击其所有已知的漏洞。

🔗 更多: 安全依赖

6.8. 避免使用 Node.js 的 crypto 库处理密码，使用 Bcrypt​

TL;DR: 密码或机密信息(API 密钥)应该使用安全的哈希+salt 函数(如 "bcrypt")来存储, 因为性能和安全原因, 这应该是其 JavaScript 实现的首选。

否则: 在不使用安全功能的情况下，保存的密码或秘密信息容易受到暴力破解和字典攻击, 最终会导致他们的泄露。

🔗 更多: 使用 Bcrypt

6.9. 转义 HTML、JS 和 CSS 输出​

TL;DR: 发送给浏览器的不受信任数据可能会被执行, 而不是显示, 这通常被称为跨站点脚本(XSS)攻击。使用专用库将数据显式标记为不应执行的纯文本内容(例如:编码、转义)，可以减轻这种问题。

否则: 攻击者可能会将恶意的 JavaScript 代码存储在您的 DB 中, 然后将其发送给可怜的客户端。

🔗 更多: 转义输出

6.10. 验证传入的 JSON schemas​

TL;DR: 验证传入请求的 body payload，并确保其符合预期要求, 如果没有, 则快速报错。为了避免每个路由中繁琐的验证编码, 您可以使用基于 JSON 的轻量级验证架构，比如jsonschema or joi

否则: 您疏忽和宽松的方法大大增加了攻击面, 并鼓励攻击者尝试许多输入, 直到他们找到一些组合, 使应用程序崩溃。

🔗 更多: 验证传入的 JSON schemas

6.11. 支持黑名单的 JWT​

TL;DR: 当使用 JSON Web Tokens(例如, 通过Passport.js), 默认情况下, 没有任何机制可以从发出的令牌中撤消访问权限。一旦发现了一些恶意用户活动, 只要它们持有有效的标记, 就无法阻止他们访问系统。通过实现一个不受信任令牌的黑名单，并在每个请求上验证，来减轻此问题。

否则: 过期或错误的令牌可能被第三方恶意使用，以访问应用程序，并模拟令牌的所有者。

🔗 更多: 为 JSON Web Token 添加黑名单

6.12. 限制每个用户允许的登录请求​

TL;DR: 一类保护暴力破解的中间件，比如express-brute，应该被用在 express 的应用中，来防止暴力/字典攻击；这类攻击主要应用于一些敏感路由，比如/admin 或者 /login，基于某些请求属性, 如用户名, 或其他标识符, 如正文参数等。

否则: 攻击者可以发出无限制的密码匹配尝试, 以获取对应用程序中特权帐户的访问权限。

🔗 更多: 限制登录频率

6.13. 使用非 root 用户运行 Node.js​

TL;DR: Node.js 作为一个具有无限权限的 root 用户运行，这是一种普遍的情景。例如，在 Docker 容器中，这是默认行为。建议创建一个非 root 用户，并保存到 Docker 镜像中（下面给出了示例），或者通过调用带有"-u username" 的容器来代表此用户运行该进程。

否则: 在服务器上运行脚本的攻击者在本地计算机上获得无限制的权利 (例如，改变 iptable，引流到他的服务器上)

🔗 更多: 使用非 root 用户运行 Node.js

6.14. 使用反向代理或中间件限制负载大小​

TL;DR: 请求 body 有效载荷越大, Node.js 的单线程就越难处理它。这是攻击者在没有大量请求(DOS/DDOS 攻击)的情况下，就可以让服务器跪下的机会。在边缘上（例如，防火墙，ELB）限制传入请求的 body 大小，或者通过配置express body parser仅接收小的载荷，可以减轻这种问题。

否则: 您的应用程序将不得不处理大的请求, 无法处理它必须完成的其他重要工作, 从而导致对 DOS 攻击的性能影响和脆弱性。

🔗 更多: 限制负载大小

6.15. 避免 JavaScript 的 eval 声明​

TL;DR: eval 是邪恶的, 因为它允许在运行时执行自定义的 JavaScript 代码。这不仅是一个性能方面的问题, 而且也是一个重要的安全问题, 因为恶意的 JavaScript 代码可能来源于用户输入。应该避免的另一种语言功能是 new Function 构造函数。setTimeout 和 setInterval 也不应该传入动态 JavaScript 代码。

否则: 恶意 JavaScript 代码查找传入 eval 或其他实时判断的 JavaScript 函数的文本的方法, 并将获得在该页面上 javascript 权限的完全访问权。此漏洞通常表现为 XSS 攻击。

🔗 更多: 避免 JavaScript 的 eval 声明

6.16. 防止恶意 RegEx 让 Node.js 的单线程过载执行​

TL;DR: 正则表达式，在方便的同时，对 JavaScript 应用构成了真正的威胁，特别是 Node.js 平台。匹配文本的用户输入需要大量的 CPU 周期来处理。在某种程度上，正则处理是效率低下的，比如验证 10 个单词的单个请求可能阻止整个 event loop 长达 6 秒，并让 CPU 引火烧身。由于这个原因，偏向第三方的验证包，比如validator.js，而不是采用正则，或者使用safe-regex来检测有问题的正则表达式。

否则: 写得不好的正则表达式可能容易受到正则表达式 DoS 攻击的影响, 这将完全阻止 event loop。例如，流行的moment包在 2017 年的 11 月，被发现使用了错误的 RegEx 用法而易受攻击。

🔗 更多: 防止恶意正则

6.17. 使用变量避免模块加载​

TL;DR: 避免通过作为参数的路径 requiring/importing 另一个文件, 原因是它可能源自用户输入。此规则可扩展为访问一般文件(即:fs.readFile())或使用来自用户输入的动态变量访问其他敏感资源。Eslint-plugin-security linter 可以捕捉这样的模式, 并尽早提前警告。

否则: 恶意用户输入可以找到用于获得篡改文件的参数, 例如, 文件系统上以前上载的文件, 或访问已有的系统文件。

🔗 更多: 安全地加载模块

6.18. 在沙箱中运行不安全代码​

TL;DR: 当任务执行在运行时给出的外部代码时(例如, 插件), 使用任何类型的沙盒执行环境保护主代码，并隔离开主代码和插件。这可以通过一个专用的过程来实现 (例如:cluster.fork()), 无服务器环境或充当沙盒的专用 npm 包。

否则: 插件可以通过无限循环、内存超载和对敏感进程环境变量的访问等多种选项进行攻击

🔗 更多: 在沙箱中运行不安全代码

6.19. 使用子进程时要格外小心​

TL;DR: 尽可能地避免使用子进程，如果您仍然必须这样做，验证和清理输入以减轻 shell 注入攻击。更喜欢使用 "child_process"。execFile 的定义将只执行具有一组属性的单个命令, 并且不允许 shell 参数扩展。倾向于使用child_process.execFile，从定义上来说，它将仅仅执行具有一组属性的单个命令，并且不允许 shell 参数扩展。

否则: 由于将恶意用户输入传递给未脱敏处理的系统命令, 直接地使用子进程可能导致远程命令执行或 shell 注入攻击。

🔗 更多: 处理子进程时要格外小心

6.20. 隐藏客户端的错误详细信息​

TL;DR: 默认情况下, 集成的 express 错误处理程序隐藏错误详细信息。但是, 极有可能, 您实现自己的错误处理逻辑与自定义错误对象(被许多人认为是最佳做法)。如果这样做, 请确保不将整个 Error 对象返回到客户端, 这可能包含一些敏感的应用程序详细信息。

否则: 敏感应用程序详细信息(如服务器文件路径、使用中的第三方模块和可能被攻击者利用的应用程序的其他内部工作流)可能会从 stack trace 发现的信息中泄露。

🔗 更多: 隐藏客户端的错误详细信息

6.21. 对 npm 或 Yarn，配置 2FA​

TL;DR: 开发链中的任何步骤都应使用 MFA(多重身份验证)进行保护, npm/Yarn 对于那些能够掌握某些开发人员密码的攻击者来说是一个很好的机会。使用开发人员凭据, 攻击者可以向跨项目和服务广泛安装的库中注入恶意代码。甚至可能在网络上公开发布。在 npm 中启用 2 因素身份验证（2-factor-authentication）, 攻击者几乎没有机会改变您的软件包代码。

否则: Have you heard about the eslint developer who's password was hijacked?

6.22. 修改 session 中间件设置​

TL;DR: 每个 web 框架和技术都有其已知的弱点-告诉攻击者我们使用的 web 框架对他们来说是很大的帮助。使用 session 中间件的默认设置, 可以以类似于X-Powered-Byheader 的方式向模块和框架特定的劫持攻击公开您的应用。尝试隐藏识别和揭露技术栈的任何内容(例如:Nonde.js, express)。

否则: 可以通过不安全的连接发送 cookie, 攻击者可能会使用会话标识来标识 web 应用程序的基础框架以及特定于模块的漏洞。

🔗 更多: cookie 和 session 安全

6.23. 通过显式设置进程应崩溃的情况，以避免 DOS 攻击​

TL;DR: 当错误未被处理时, Node 进程将崩溃。即使错误被捕获并得到处理，许多最佳实践甚至建议退出。例如, Express 会在任何异步错误上崩溃 - 除非使用 catch 子句包装路由。这将打开一个非常惬意的攻击点, 攻击者识别哪些输入会导致进程崩溃并重复发送相同的请求。没有即时补救办法, 但一些技术可以减轻苦楚: 每当进程因未处理的错误而崩溃，都会发出警报，验证输入并避免由于用户输入无效而导致进程崩溃，并使用 catch 将所有路由处理包装起来，并在请求中出现错误时, 考虑不要崩溃(与全局发生的情况相反)。

否则: 这只是一个起到教育意义的假设: 给定许多 Node.js 应用程序, 如果我们尝试传递一个空的 JSON 正文到所有 POST 请求 - 少数应用程序将崩溃。在这一点上, 我们可以只是重复发送相同的请求, 就可以轻松地搞垮应用程序。

fill-available​

width:fill-available表示撑满可用空间

举例来说，页面中一个<div>元素，该<div>元素的width表现就是fill-available自动填满剩余的空间

该属性高度也可用

使用场景：

1. 可以让元素的100%自动填充特性不仅仅在block水平元素上，也可以应用在其他元素，如span
2. 可以在非flex等高级布局下，轻松实现元素占据剩余空间的效果
3. 待发掘

兼容性：

值得注意的是绝大部分浏览器只支持-webkit前缀的fill-available

fit-content​

width:fit-content表示将元素宽度收缩为内容宽度

高度也可用

使用场景：

1. 可以赋予block的元素收缩的效果
2. 配合margin:auto轻松实现向内自适应同时的居中效果

兼容性：

使用时最好也加上-webkit前缀的fit-content

min-content​

width:min-content表示采用内部元素最小宽度值最大的那个元素的宽度作为最终容器的宽度

最小宽度值： 替换元素，例如图片的最小宽度值就是图片呈现的宽度，对于文本元素，如果全部是中文，则最小宽度值就是一个中文的宽度值；如果包含英文，因为默认英文单词不换行，所以，最小宽度可能就是里面最长的英文单词的宽度

兼容性：

max-content​

width:max-content表示采用内部元素宽度值最大的那个元素的宽度作为最终容器的宽度。如果出现文本，则相当于文本不换行

兼容性：

max​

/* property: max(expression [, expression]) */
width: max(10vw, 4em, 80px);

兼容性：

不容乐观，混个眼熟就算了

min​

/* property: min(expression [, expression]) */
width: min(1vw, 4em, 80px);

兼容性：

同样不容乐观，看看算了

以上所有属性在IE中都无效

基础​

原始数据类型​

• boolean
• number
• string
• null
• undefined
• Symbol
• void
• any

任意值​

• any

类型推论​

在定义变量时如果进行了赋值，那么变量的类型就会被自动设置为值的类型，反之，如果没有进行赋值，则会被设置为any

联合类型​

• type1 | type2
• 联合类型的变量在被赋值的时候，会根据类型推论的规则推断出一个类型，比如 string|number 类型的变量，当被赋值为 number 类型时不能使用 xxx.length

接口 interface​

• 确定属性 赋值的时候，变量的形状必须和接口的形状保持一致(不能多也不能少属性)
• 可选属性 key?: type
• 任意属性 [propName: string]: any
  • 一旦定义任意属性，确定属性和可选属性的类型必须是它的类型的子集
• 只读属性 readonly key: type

数组类型​

• 「类型 + 方括号」表示法
  • eg: let arr: number[] = [1, 2, 3];
• 数组泛型
  • eg: let arr: Array<number> = [1,2,3]
• 用接口表示数组

  • interface NumberArray {
      [index: number]: number;
    }
    let fibonacci: NumberArray = [1, 1, 2, 3, 5];
    
• 类数组
  • 类数组不是数组类型，有自己的类型

  • function sum() {
      let args: {
        [index: number]: number;
        length: number;
        callee: Function;
      } = arguments;
    }
    
  • 常用的类数组都有自己的接口定义，如 IArguments, NodeList, HTMLCollection

函数类型​

• 函数声明

  • function sum(x: number, y: number): number {
      return x + y;
    }
    

• 函数表达式

  • let mySum: (x: number, y: number) => number = function(
      x: number,
      y: number
    ): number {
      return x + y;
    };
    
    // 利用类型推断进行简化
    let mySum = function(x: number, y: number): number {
      return x + y;
    };
    

• 接口定义

  • interface SearchFunc {
      (source: string, subString: string): boolean;
    }
    
    let mySearch: SearchFunc;
    mySearch = function(source: string, subString: string) {
      return source.search(subString) !== -1;
    };
    

• 可选参数

  • x?: type

• 剩余参数

  • 同 es6

• 函数重载

  • 匹配多种完全不同的入参格式

  • function reverse(x: number): number;
    function reverse(x: string): string;
    function reverse(x: number | string): number | string {
      if (typeof x === "number") {
        return Number(
          x
            .toString()
            .split("")
            .reverse()
            .join("")
        );
      } else if (typeof x === "string") {
        return x
          .split("")
          .reverse()
          .join("");
      }
    }
    

类型断言​

• 语法
  • 值 as 类型
• 用途
  • 将一个联合类型断言为其中一个类型
  • 将一个父类断言为更加具体的子类
  • 将任何一个类型断言为 any
  • 将 any 断言为一个具体的类型
  • 要使得 A 能够被断言为 B，只需要 A 兼容 B 或 B 兼容 A 即可
• 双重断言（不要使用）
• 关系
  • 与类型转换
  • 与类型声明
  • 与泛型

声明文件​

• 新语法

  • declare var 声明全局变量
  • declare let 声明全局变量
  • declare const 声明不可变全局变量
  • declare function 声明全局方法
  • declare class 声明全局类
  • declare enum 声明全局枚举类型
  • declare namespace 声明（含有子属性的）全局对象
  • interface 和 type 声明全局类型
  • export 导出变量
  • export namespace 导出（含有子属性的）对象
  • export default ES6 默认导出
  • export = commonjs 导出模块
  • export as namespace UMD 库声明全局变量
  • declare global 扩展全局变量
  • declare module 扩展模块
  • /// <reference /> 三斜线指令

• 声明语句

  • 当引入了第三方代码的时候，ts 无法识别第三方代码的全局变量，例如可以通过declare var jQuery: (selector: string) => any;使用 jQuery

• 声明文件

  • 当把声明语句放到一个单独文件中，就是声明文件
  • 声明文件以.d.ts为后缀
  • 社区已经有不少声明文件了，使用@types 统一管理第三方库的声明文件npm install @types/jquery --save-dev
  • 可以在这个页面搜索
  • 如果没有生效，可以检查下 tsconfig.json 中的 files、include 和 exclude 配置，确保其包含了 xxx.d.ts 文件
  • 只能定义类型，不能在声明语句中定义具体实现

• declare namespace

  • declare namespace jQuery {
      function ajax(url: string, settings?: any): void;
      const version: number;
      class Event {
        blur(eventType: EventType): void;
      }
      enum EventType {
        CustomClick,
      }
      <!-- 可以进行深层嵌套 -->
      namespace fn {
        function extend(object: any): void;
      }
    }
    
    <!-- 如果只有extend方法，也可以这样写 -->
    declare namespace jQuery.fn {
      function extend(object: any): void;
    }
    

  • interface 和 type 可以放在 namespace 下防止命名冲突

  • declare namespace jQuery {
      interface AjaxSettings {
        method?: "GET" | "POST";
        data?: any;
      }
      function ajax(url: string, settings?: AjaxSettings): void;
    }
    

• 多个声明可以合并，类似于函数的重载

• npm 包

  • 倒入的 npm 包的声明文件位置
    • 与 npm 包绑定在一起。package.json 中的 types 字段或者 index.d.ts 文件
    • 如果 npm 包维护者没有提供声明文件，其他人会把声明文件发布到@types 中
    • 如果上面两种都没找到，那么就要自己写了
  • 自己写声明文件
    • tsconfig.json 同级目录下创建 types 目录，管理声明文件
    • 需要配置 tsconfig.json 中的 paths 和 baseUrl 字段

    • {
        "compilerOptions": {
          "module": "commonjs",
          "baseUrl": "./",
          "paths": {
            "*": ["types/*"]
          }
        }
      }
      

• 导入导出

  • npm 包中的声明文件中，使用 declare 只会声明一个局部变量
  • 使用 export 导出时，可以不用写 declare
  • 可以使用 declare 声明多个变量，再使用 export 一次性导出
  • commonjs
    • 导出
      • 整体导出 module.exports = foo
      • 单个导出 exports.bar = bar
    • 导入
      • 方式 1
        • const foo = require('foo');
        • const bar = require('foo').bar;
      • 方式 2
        • import * as foo from 'foo';
        • import { bar } from 'foo';
      • 方式 3
        • import foo = require('foo');
        • import bar = foo.bar;
  • UMD 库
    • export as namespace
  • 在 npm 包或 UMD 库中扩展全局变量
    • declare global
  • 模块插件
    • declare module

• 声明文件中的依赖

  • import

  • 三斜线

    • 场景

      • 当我们在书写一个全局变量的声明文件时
      • 当我们需要依赖一个全局变量的声明文件时

    • // types/jquery-plugin/index.d.ts
      
      /// <reference types="jquery" />
      /// <reference path="JQuery.d.ts" />
      
      declare function foo(options: JQuery.AjaxSettings): string;
      

• 自动生成声明文件

  • {
      "compilerOptions": {
        "module": "commonjs",
        "outDir": "lib",
        "declaration": true
        "declarationDir": "设置生成 .d.ts 文件的目录",
        "declarationMap": "对每个 .d.ts 文件，都生成对应的 .d.ts.map（sourcemap）文件",
        "emitDeclarationOnly": "仅生成 .d.ts 文件，不生成 .js 文件"
      }
    }
    

• 寻找声明文件流程

  1. 寻找package.json中的types或者typing字段指定的地址
  2. 第 1 步没有，就会在项目根目录下寻找是否存在 index.d.ts 文件
  3. 第 2 步没有，就会寻找入口文件(package.json 中的 main 字段指定的入口文件)的目录下的同名不同后缀的.d.ts文件

• 将声明文件发布到 @types 下

  • DefinitelyTyped

内置对象​

• TypeScript 核心库的定义文件
• ECMAScript 的内置对象
  • Boolean、Error、Date、RegExp 等
• DOM 和 BOM 的内置对象
  • Document、HTMLElement、Event、NodeList 等
• Node.js
  • TypeScript 核心库的定义中不包含 Node.js 部分
  • 使用 ts 写 node 时，要引入第三方声明文件 npm install @types/node --save-dev

进阶​

类型别名​

• 给一个类型起个新名字
• type
  • 类型可以是联合类型

type Name = string;
type NameResolver = () => string;
type NameOrResolver = Name | NameResolver;
function getName(n: NameOrResolver): Name {
  if (typeof n === "string") {
    return n;
  } else {
    return n();
  }
}

字符串字面量类型​

• 用来约束取值只能是某几个字符串中的一个
• type

type EventNames = "click" | "scroll" | "mousemove";
function handleEvent(ele: Element, event: EventNames) {
  // do something
}

handleEvent(document.getElementById("hello"), "scroll"); // 没问题
handleEvent(document.getElementById("world"), "dblclick"); // 报错，event 不能为 'dblclick'

// index.ts(7,47): error TS2345: Argument of type '"dblclick"' is not assignable to parameter of type 'EventNames'.

元组​

• 数组合并了相同类型的对象，而元组（Tuple）合并了不同类型的对象
• let tom: [string, number] = ['Tom', 25];

枚举​

• 用于取值被限定在一定范围内的场景
• 简单例子

enum Days {
  Sun,
  Mon,
  Tue,
  Wed,
  Thu,
  Fri,
  Sat,
}
// 枚举成员会被赋值为从 0 开始递增的数字，同时也会对枚举值到枚举名进行反向映射

console.log(Days["Sun"] === 0); // true
console.log(Days["Mon"] === 1); // true
console.log(Days["Tue"] === 2); // true
console.log(Days["Sat"] === 6); // true

console.log(Days[0] === "Sun"); // true
console.log(Days[1] === "Mon"); // true
console.log(Days[2] === "Tue"); // true
console.log(Days[6] === "Sat"); // true

• 手动赋值

enum Days {
  Sun = 7,
  Mon = 1,
  Tue,
  Wed,
  Thu,
  Fri,
  Sat,
}

console.log(Days["Sun"] === 7); // true
console.log(Days["Mon"] === 1); // true
console.log(Days["Tue"] === 2); // true
console.log(Days["Sat"] === 6); // true

// 其实等价于enum Days {Sun = 7, Mon = 1, Tue=2, Wed=3, Thu=4, Fri=5, Sat=6};
// 所以可能会出现手动赋值和自动赋值重复的情况，因此要不全部手动赋值，要不全部自动赋值

• 常数枚举
  • const enum

const enum Directions {
  Up,
  Down,
  Left,
  Right,
}

let directions = [
  Directions.Up,
  Directions.Down,
  Directions.Left,
  Directions.Right,
];

类​

• 基础部分参考 js 的类
• 访问修饰符
  • public 公有
  • private 私有，不能在类的外部被访问
  • protected 受保护的，只能在类和子类中被访问
• readonly
  • 只允许出现在属性声明或索引签名或构造函数中
  • 如果 readonly 和其他访问修饰符同时存在的话，需要写在其后面
• 构造函数参数修饰符
  • 修饰符和 readonly 可以使用在构造函数参数中，等同于类中定义该属性同时给该属性赋值
• 抽象类
  • 不允许被实例化
  • 抽象类中的抽象方法必须被子类实现

类与接口​

• 类实现接口
  • implements 关键字
  • 一个类可以实现多个接口
• 接口继承接口
  • extends 关键字
• 接口继承类
  • 当声明一个类的时候，相当于同时创建了一个对应的类型
  • 接口继承类时只会继承类的实例属性和实例方法

泛型​

• todo

声明合并​

• 函数合并
• 接口合并
  • 对同一个接口进行多次定义，只要内部属性不冲突，就会合并
  • 接口中方法的合并，与函数合并一样
• 类合并
  • 同接口合并

工程​

eslint​

npm install --save-dev eslint
npm install --save-dev typescript @typescript-eslint/parser
npm install --save-dev @typescript-eslint/eslint-plugin
npm install --save-dev prettier
npm install --save-dev eslint-plugin-react

.eslintrc
module.exports = {
    parser: '@typescript-eslint/parser',
    plugins: ['@typescript-eslint'],
    rules: {
        // 禁止使用 var
        'no-var': "error",
        // 优先使用 interface 而不是 type
        '@typescript-eslint/consistent-type-definitions': [
            "error",
            "interface"
        ]
    }
}

vscode setting.json
{
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "eslint.autoFixOnSave": true,
    "eslint.validate": [
        "javascript",
        "javascriptreact",
        {
            "language": "typescript",
            "autoFix": true
        },
        {
            "language": "typescriptreact",
            "autoFix": true
        }
    ],
    "typescript.tsdk": "node_modules/typescript/lib"
}


// .prettierrc.js
module.exports = {
    // 一行最多 100 字符
    printWidth: 100,
    // 使用 4 个空格缩进
    tabWidth: 4,
    // 不使用缩进符，而使用空格
    useTabs: false,
    // 行尾需要有分号
    semi: true,
    // 使用单引号
    singleQuote: true,
    // 对象的 key 仅在必要时用引号
    quoteProps: 'as-needed',
    // jsx 不使用单引号，而使用双引号
    jsxSingleQuote: false,
    // 末尾不需要逗号
    trailingComma: 'none',
    // 大括号内的首尾需要空格
    bracketSpacing: true,
    // jsx 标签的反尖括号需要换行
    jsxBracketSameLine: false,
    // 箭头函数，只有一个参数的时候，也需要括号
    arrowParens: 'always',
    // 每个文件格式化的范围是文件的全部内容
    rangeStart: 0,
    rangeEnd: Infinity,
    // 不需要写文件开头的 @prettier
    requirePragma: false,
    // 不需要自动在文件开头插入 @prettier
    insertPragma: false,
    // 使用默认的折行标准
    proseWrap: 'preserve',
    // 根据显示样式决定 html 要不要折行
    htmlWhitespaceSensitivity: 'css',
    // 换行符使用 lf
    endOfLine: 'lf'
};

编译选项​

参考文档​

• TypeScript Playground
• 了不起的 TypeScript 入门教程
• 一文读懂 TypeScript 泛型及应用
• TypeScript 入门教程
• TypeScript官方中文文档

Why HTTPS 为什么会产生​

HTTPS 产生的原因在于 HTTP 本身的不安全性

HTTP 的不安全主要体现在三个方面

1. 通信使用不加密的明文，通信的内容容易被窃听
2. 无法验证通信双方的身份，有可能遭遇伪装
3. 无法验证报文内容的完整性，有可能获取到的内容已被篡改

因为上述三个原因，使用 HTTP 的互联网是完全不可靠不安全的，直至 HTTPS 的诞生

学习 HTTPS 前置知识​

对称加密​

加密解密都使用同一个密钥，该密钥我们称为共享密钥

非对称加密​

加密和解密使用不同的密钥，取其中一个作为公钥可传播到公开场合，另一个作为私钥自己保管，两个密钥地位完全等同，其神奇之处在于经过一个密钥加密的内容，只有使用另一个密钥才能解密 非对称加密有两种场景

1. 公钥加密，私钥解密：只有私钥的拥有者才能获取到真正的内容
2. 私钥加密，公钥解密：内容接收者用于验证内容发送者的身份

非对称加密对比对称加密，安全性更高，但是同时带来的副作用是资源消耗变大，因为公钥和私钥的产生需要大量的计算，加解密也需要大量的计算

RSA​

常见的非对称加密算法之一

ECDHE​

常见的非对称加密算法之一

HTTPS 内容​

为了规避 HTTP 的不安全性，HTTPS 在 HTTP 协议之下，增设了一层 SSL/TLS 协议，在该层中，进行了数据的加密

HTTPS 的数据传输使用了对称加密的方式，客户端和服务端都使用客户端生成的同一个密钥，但是问题关键是客户端如何把密钥安全的送到服务端手中。这里，HTTPS 使用了非对称加密，将共享密钥作为内容发送过去，因此 HTTPS 总体上使用了对称加密和非对称加密混合的加密机制。 那么，为什么不在数据传输的过程中也使用非对称加密的方式呢？答案是考虑到非对称加密需要大量的计算，占用资源多，且连接繁琐，耗时长，因此采用对称加密的方式。

在使用非对称加密的过程中，必然涉及到公钥的发送与接收，那么 HTTPS 又如何保证公钥的真实性呢？ 这里，HTTPS 引入了由数字证书认证机构(CA，Certificate Authority)和其相关机关颁发的公开密钥证书

与证书相关的流程见下图： 这里使用了前置知识中的私钥加密，公钥解密,内容接收者用于验证内容发送者的身份的知识，CA 使用自己的私钥对服务器的公钥进行了加密得到证书，之后客户端使用 CA 的公钥对证书解密，从而验证 CA 的真实性和服务器公钥的真实性

下图是 HTTPS 的通信步骤

1. 客户端发送 ClientHello 报文开始 SSL 通信，包含一个随机数 client_random，SSL 版本，加密组件列表等信息
2. 服务器发送 ServerHello 作为回应，包含一个随机数 server_random，SSL 版本，加密组件等信息
3. 服务器发送 Certificate 报文，包含公钥证书
4. 服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束
5. SSL 第一次握手结束之后，客户端以 Client Key Exchange 报 文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
6. 接着客户端继续发送 Change Cipher Spec 报文。该报文会提 示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
7. 客户端发送 Finished 报文。该报文包含连接至今全部报文的 整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确 解密该报文作为判定标准。
8. 服务器同样发送 Change Cipher Spec 报文
9. 服务器同样发送 Finished 报文
10. 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接 就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用 层协议的通信，即发送 HTTP 请求
11. 应用层协议通信，即发送 HTTP 响应。
12. 最后由客户端断开连接。断开连接时，发送 close_notify 报文。

大家可能看了上面的这些步骤一脸懵 其实总的来说，步骤 1-4 这一个 TTL 中，主要目的是服务器把配对的公钥发送给客户端； 步骤 5-9 这一个 TTL 中，目的是客户端使用刚刚获得的公钥，把之后对称加密用的密钥进行加密，发送给服务端； 之后就是双方使用对称加密进行数据通信，直至连接断开

以上是 TSL 的传统握手，当然随着时代发展，TSL 也进行了升级，现在主流的版本是 TLS/1.2, 之前的 TLS1.0、TLS1.1 都被认为是不安全的，在不久的将来会被完全淘汰。

安全性上，传统的 TSL 通信使用 RSA 算法作为非对称加密算法， TSL1.2 中使用了 ECDHE参考 1 参考 2作为加密算法，性能较 RSA 更好，使用 RSA 算法时服务器的私钥是固定的，一旦中间人拿到了服务器私钥，并且截获之前所有报文的时候，那么就能拿到 pre_random、server_random 和 client_random 并根据对应的随机数函数生成 secret，也就是拿到了 TLS 最终的会话密钥，每一个历史报文都能通过这样的方式进行破解。 但 ECDHE 在每次握手时都会生成临时的密钥对，即使私钥被破解，之前的历史消息并不会收到影响。这种一次破解并不影响历史信息的性质也叫前向安全性。 RSA 算法不具备前向安全性，而 ECDHE 具备，因此在 TLS1.3 中彻底取代了 RSA。

性能上，TSL1.3 通过 Session-ticket 进行会话复用减少重新生成密钥的时间，以及使用 PSK（Pre-Shared Key，在发送 Session-ticket 同时带上应用数据）做到了 0-RTT 连接

记录一次代码回滚导致的加班

2020年5月9日下午五点。 滕某人本来今天高高兴兴，心想着又是可以下早班的一天，只要把这些小改动发上线就OK了，还不是轻轻松松。可是一顿操作之后把代码提审通过，发到预发环境一看，？？？怎么改的东西有的生效了有的没生效，会不会是代码提得不对，嗯，一定是这样，再提一遍。gitlab上一看，呐尼，no commit，可是本地代码和线上代码的确是不一样呀，怎么会no commit呢？一番冥思苦想后，脑海中浮现了两个小时前的场景。

时间回溯到2020年5月9日下午三点。 打开gitlab，source branch填上我的分支，target branch填上今天的hotfix分支（这里其实没有点上，默认master了），回车，指定代码审核人，OK，走你！！！五分钟后，回gitlab一看，嗯，审核通过了，可是。。。，怎么有种奇怪的赶脚，艹了，我怎么把代码直接提到master上去了，他（指审核人）竟然还给我通过了，这么盲目信任我的吗，可是我好菜的。。。我这次的改动依赖后端，可千万不能发线上，得赶紧把master代码回滚一下， -那个谁，刚刚提的merge request，提错分支了，你赶紧把master回滚一下。 -xxxxxx(祖安语),好了，我给你revert一下。 作为一个平时只会push操作的git菜鸟，面对revert这样的陌生词汇，一脸蒙蔽的点了一下头，又忙起了手上的活，之后又提了做了一些改动，提了几个commit。

OK，事情的经过回溯完毕，问过大佬后，原因明了了：master代码回滚是通过revert方式的，从而导致我之后提交的时候显示no commit，为什么呢。

revert操作，中文意思是反转，顾名思义，是将之前有问题的commit操作的逆操作，作为一个新的commit，提交了上去，比如之前我加了一行有问题的代码，通过revert，我相当于又进行了一次提交，提交的内容是删除了那行有问题的代码，从而达到恢复代码的目的。可是，在revert操作下， 有问题的那个commit和revert的commit都是保留在了commit记录中的，git分支都是向前走而非回退，导致了之后我想把代码提上去，是提不上去的，因为那个commit之前已经提过了(在回滚的时候那个commit是有问题的commit，可是之后走正常流程了，该commit就是正常的commit了，可是git无法判断有没有问题)，因此显示的是no commit。

当时的解决方法是对那个revert的commit，我再revert一次，从而抵消了revert带来的影响。

从发现问题，到找原因，到解决问题，再到重新发预发，确认，再发线上，确认，时间也不知不觉地到了晚上八点，哎，都八点了，直接等到九点打车吧（公司九点后打车免费）--又被996了 --其实互联网人的996，就是能力不行导致的瞎折腾，还是得学习进步呀 -- END

new​

new 关键字作为 JS 中通过正常途径实例化一个类的唯一方法，经常出现在我们的视线中，那么其原理又是如何呢？它到底做了什么事情？

先看一段代码

// 定义类 类名字是 classA
function classA() {
  this.name = 1;
}
classA.prototype.show = function() {
  alert(this.name);
};
// 用new实例化
var b = new classA();
b.show();

这是一个常见的使用 new 创建实例的例子

new 其实干了如下几件事

1. 创建了一个对象 a(a 是随便取的)
2. 将该对象的proto属性设置为 classA 的 prototype
3. 将 classA 中的 this 指向对象 a，也就是之后的this.name=1等同于a.name=1
4. 执行 classA 函数
5. 将对象 a 返回出去

接下来通过 JS 模拟一下 new 的操作

function classA() {
  this.name = "start";
}
classA.prototype.sayName = function() {
  console.log(this.name);
};

function NEW(className) {
  let res = {}; // 新建一个对象
  res.__proto__ = className.prototype; // 通过原型链继承classA的方法
  className.call(res); // 通过call修改classA的this指向，并且调用classA这个函数，在这个过程中内部的name属性会被赋值
  return res;
}
let a = NEW(classA);
a.sayName();
a.name = "a";
a.sayName();

以上就是new的作用，如果在实例化的时候忘记使用new了，其实就是简单地调用了一下那个函数，函数内部的 this 其实指向的是外部，

function classA() {
  this.name = "start";
}
classA.prototype.sayName = function() {
  console.log(this.name);
};
let a = classA();
try {
  a.sayName();
} catch (e) {
  console.log(e);
}
console.log(name);

上述代码运行后会发生报错，打印的name是start，可见this默认被绑到了外部（浏览器端为 window，nodejs 端为 global）

注意以上是在函数体内，如果在全局环境中浏览器的依然为window，但是 nodejs 端为{}

由以上的所讲的new的原理，进一步，我们可以解释如下现象

function classA() {
  this.name = "start";
  let obj = { a: 1 };
  return obj;
}
classA.prototype.sayName = function() {
  console.log(this.name);
};
let a = classA();
console.log(a.a); // 1
a.sayName(); // 报错

因为在return最后的res之前，使用call调用了classA这个函数，结果直接返回出来了，因此所获得的并不是我们想要的结果

构造函数中绝对不能 return 数据

浅拷贝VS深拷贝​

function isReferenceType (o) {
  return o instanceof Object
}

function deepClone (obj) {
  if (!isReferenceType(obj)) {
    return obj
  }

  if (obj instanceof RegExp) return new RegExp(obj)
  if (obj instanceof Function) return obj.bind({})

  let newObj = new obj.constructor()
  Reflect.ownKeys(obj).forEach(key => {
    newObj[key] = deepClone(obj[key])
  })

  return newObj
}

let arr = [1, 2, 3];
arr.push(arr);
var obj = {
  a: 1,
  arr,
  func: () => {
    console.log("aaa");
  },
  date: new Date(),
  reg: new RegExp(/test/),
  none: undefined,
};
obj.obj = obj;
console.log(deepClone(obj));
//   return JSON.parse(JSON.stringify(obj))
// }
// console.log(jsonDeepClone({
//   a: 1,
//   func: ()=>{
//     console.log('aaa');
//   },
//   date: new Date(),
//   reg: new RegExp(/test/),
//   none: undefined
// }));

call和apply​

Function.prototype.call = function() {
  let [context, ...args] = [...arguments];
  if (!context) {
    context = typeof window === "undefined" ? global : window;
  }
  // 注意，这里必须要context.func 不能是一个简单的变量，因为需要给函数一个运行的上下文，即context
  context.func = this;
  let res = context.func(...args);
  delete context.func;
  // context中实际并无func这个key，要删除恢复原样
  return res;
};
Function.prototype.apply = function() {
  let [context, args] = arguments;
  if (!context) {
    context = typeof window === "undefined" ? global : window;
  }
  context.func = this;
  let res;
  if (!args) res = context.func();
  else res = context.func(...args);
  delete context.func;
  return res;
};

function getName(age, address) {
  console.log(this.name);
  console.log({ age, address });
}
let obj = {
  name: "teefing",
};
getName.apply(obj, [22, "hangzhou"]);
getName.call(obj, 22, "hangzhou");