本文测试使用环境：
系统：macOS Mojave 10.14.2
CPU：4 核 2.3 GHz
Node: 10.15.1

从 Node 线程说起

一般人理解 Node 是单线程的，所以 Node 启动后线程数应该为 1，我们做实验看一下。

1
2
3

setInterval(() => {
  console.log(new Date().getTime())
}, 3000)

可以看到 Node 进程占用了 7 个线程。为什么会有 7 个线程呢？

我们都知道，Node 中最核心的是 v8 引擎，在 Node 启动后，会创建 v8 的实例，这个实例是多线程的。

• 主线程：编译、执行代码。
• 编译/优化线程：在主线程执行的时候，可以优化代码。
• 分析器线程：记录分析代码运行时间，为 Crankshaft 优化代码执行提供依据。
• 垃圾回收的几个线程。

所以大家常说的 Node 是单线程的指的是 JavaScript 的执行是单线程的，但 Javascript 的宿主环境，无论是 Node 还是浏览器都是多线程的。

Node 有两个编译器：
full-codegen：简单快速地将 js 编译成简单但是很慢的机械码。
Crankshaft：比较复杂的实时优化编译器，编译高性能的可执行代码。

某些异步 IO 会占用额外的线程

还是上面那个例子，我们在定时器执行的同时，去读一个文件：

1
2
3
4
5
6
7

const fs = require('fs')

setInterval(() => {
    console.log(new Date().getTime())
}, 3000)

fs.readFile('./index.html', () => {})

线程数量变成了 11 个，这是因为在 Node 中有一些 IO 操作（DNS，FS）和一些 CPU 密集计算（Zlib，Crypto）会启用 Node 的线程池，而线程池默认大小为 4，因为线程数变成了 11。

我们可以手动更改线程池默认大小：

1

process.env.UV_THREADPOOL_SIZE = 64

一行代码轻松把线程变成 71 😊

cluster 是多线程吗？

Node 的单线程也带来了一些问题，比如对 cpu 利用不足，某个未捕获的异常可能会导致整个程序的退出等等。因为 Node 中提供了 cluster 模块，cluster 实现了对 child_process 的封装，通过 fork 方法创建子进程的方式实现了多进程模型。比如我们最常用到的 pm2 就是其中最优秀的代表。

我们看一个 cluster 的 demo：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
  console.log(`主进程 ${process.pid} 正在运行`);
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`工作进程 ${worker.process.pid} 已退出`);
  });
} else {  
  // 工作进程可以共享任何 TCP 连接。
  // 在本例子中，共享的是 HTTP 服务器。
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('Hello World');
  }).listen(8000);
  console.log(`工作进程 ${process.pid} 已启动`);
}

这个时候看下活动监视器：

一共有 9 个进程，其中一个主进程，cpu 个数 * cpu 核数 = 2 * 4 = 8 个 子进程。

所以无论 child_process 还是 cluster，都不是多线程模型，而是多进程模型。虽然开发者意识到了单线程模型的问题，但是没有从根本上解决问题，而且提供了一个多进程的方式来模拟多线程。从前面的实验可以看出，虽然 Node （V8）本身是具有多线程的能力的，但是开发者并不能很好的利用这个能力，更多的是由 Node 底层提供的一些方式来使用多线程。Node 官方说：

You can use the built-in Node Worker Pool by developing a C++ addon. On older versions of Node, build your C++ addon using NAN, and on newer versions use N-API. node-webworker-threads offers a JavaScript-only way to access Node’s Worker Pool.

但是对于 JavaScript 开发者，一直没有一个标准的、好用的方式来使用 Node 的多线程能力。

真 - Node 多线程

直到 Node 10.5.0 的发布，官方才给出了一个实验性质的模块 worker_threads 给 Node 提供真正的多线程能力。

先看下简单的 demo：

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

const {
  isMainThread,
  parentPort,
  workerData,
  threadId,
  MessageChannel,
  MessagePort,
  Worker
} = require('worker_threads');

function mainThread() {
  for (let i = 0; i < 5; i++) {
    const worker = new Worker(__filename, { workerData: i });
    worker.on('exit', code => { console.log(`main: worker stopped with exit code ${code}`); });
    worker.on('message', msg => {
      console.log(`main: receive ${msg}`);
      worker.postMessage(msg + 1);
    });
  }
}

function workerThread() {
  console.log(`worker: workerDate ${workerData}`);
  parentPort.on('message', msg => {
    console.log(`worker: receive ${msg}`);
  }),
  parentPort.postMessage(workerData);
}

if (isMainThread) {
  mainThread();
} else {
  workerThread();
}

上述代码在主线程中开启五个子线程，并且主线程向子线程发送简单的消息。

由于 worker_thread 目前仍然处于实验阶段，所以启动时需要增加 --experimental-worker flag，运行后观察活动监视器：

不多不少，正好多了五个子线程。😊

worker_thread 模块

worker_thread 核心代码

worker_thread 模块中有 4 个对象和 2 个类。

• isMainThread: 是否是主线程，源码中是通过 threadId === 0 进行判断的。
• MessagePort: 用于线程之间的通信，继承自 EventEmitter。
• MessageChannel: 用于创建异步、双向通信的通道实例。
• threadId: 线程 ID。
• Worker: 用于在主线程中创建子线程。第一个参数为 filename，表示子线程执行的入口。
• parentPort: 在 worker 线程里是表示父进程的 MessagePort 类型的对象，在主线程里为 null
• workerData: 用于在主进程中向子进程传递数据（data 副本）

来看一个进程通信的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

const assert = require('assert');
const {
  Worker,
  MessageChannel,
  MessagePort,
  isMainThread,
  parentPort
} = require('worker_threads');
if (isMainThread) {
  const worker = new Worker(__filename);
  const subChannel = new MessageChannel();
  worker.postMessage({ hereIsYourPort: subChannel.port1 }, [subChannel.port1]);
  subChannel.port2.on('message', (value) => {
    console.log('received:', value);
  });
} else {
  parentPort.once('message', (value) => {
    assert(value.hereIsYourPort instanceof MessagePort);
    value.hereIsYourPort.postMessage('the worker is sending this');
    value.hereIsYourPort.close();
  });
}

更多详细用法可以查看官方文档。

多进程 vs 多线程

根据大学课本上的说法：“进程是资源分配的最小单位，线程是CPU调度的最小单位”，这句话应付考试就够了，但是在实际工作中，我们还是要根据需求合理选择。

下面对比一下多线程与多进程：

上述比较仅表示一般情况，并不绝对。

work_thread 让 Node 有了真正的多线程能力，算是不小的进步。

React Hooks 是 16.7.0-alpha 版本的新特性，安装即可享用。

React Hooks 简介

React Hooks 是对 React function 组件的一种扩展，通过一些特殊的函数，让无状态组件拥有状态组件才拥有的能力。

Hooks 是 React 函数组件中的一类特殊函数，通常以 use 开头，比如 useRef，useState，useReducer 等。通常在我们写 React 组件的时候，如果这个组件比较复杂，拥有自己的生命周期或者 state，就将其写成 class 组件；如果这个组件仅仅用来展示，就将其写成 function 组件。

React Hooks 使用 function 组件的写法，通过 useState 这样的 API 解决了 function 组件没有 state 的问题，通过 useEffect 来解决生命周期的问题，通过自定义 hooks 来复用业务逻辑。

Hooks 解决哪些问题

• 复用与状态有关的逻辑，之前引申出来 HOC 的概念，但是 HOC 会导致组件树的臃肿。
• 解决组件随着业务扩展变得难以维护的问题。
• 使用更容易理解并且对初学者更友好的 function 组件。

用法

Hooks 主要分三种：

• State hooks: 允许开发者在 function 组件中使用 state。
• Effect hooks: 允许开发者在 function 组件中使用生命周期和 side effect。
• Custom hooks: 自定义 hooks，可以在里面使用 State Hooks 和 Effect Hooks，达到组件之间逻辑复用。

State Hooks

看一下官方给出的 demo

1
2
3
4
5
6
7
8
9
10
11
12
13
14

import { useState } from 'react';

function Example() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

这里的 useState 就是一个 hook，返回一个数组，第一个 count 表示一个 state，默认值为 0；第二个 setCount 相当于 class function 中的 setState，表示对 count 的更新操作。

这样写的好处是每个 state 独立管理，避免状态复杂的时候 state 臃肿。

基本用法描述如下：

1
2

const [state, setState] = useState(initialState);
setState(newState);

useState 返回一个数组，第一个值是一个 stateful（有状态）的值，第二个值是更新这个状态值的函数。在初始渲染的时候，返回的 state 与 initialState 相同，在后续重新渲染时，useState 返回的第一个值将始终是应用更新后的最新 state(状态) 。

setState 函数用于更新 state(状态) ，它接受一个新的 state(状态) 值，并将组件排入重新渲染的队列。

由于 setState 使用函数式的更新方式，所以可以传递函数给 setState，该函数将接收先前的值，并返回更新的值。

1
2
3
4
5
6
7
8
9
10
11

function Counter({initialCount}) {
  const [count, setCount] = useState(initialCount);
  return (
    <>
      Count: {count}
      <button onClick={() => setCount(0)}>Reset</button>
      <button onClick={() => setCount(prevCount => prevCount + 1)}>+</button>
      <button onClick={() => setCount(prevCount => prevCount - 1)}>-</button>
    </>
  );
}

上述代码可以使用上次的 state 来计算新的 state。与 React 类组件中的 setState 不同，useState 不会自动合并更新对象。所以如果要更新的 state 依赖前一个 state 的时候，需要使用对象扩展的方式：

1
2
3
4

setState(prevState => {
  // Object.assign 也是可行的
  return {...prevState, ...updatedValues};
});

initialState 参数既可以是一个值，也可以是一个函数，如果初始状态是高开销的计算结果，则可以改为提供函数，该函数仅在初始渲染时执行：

1
2
3
4

const [state, setState] = useState(() => {
  const initialState = someExpensiveComputation(props);
  return initialState;
});

initialState 参数只有在初始渲染期间才会使用，在随后的渲染中，它会被忽略。

Effect Hooks

Effect Hooks 允许在组件中执行副作用（side effects），类似于类中的生命周期方法。通常我们需要在 componentDidMount 和 componentDidUpdate 写一些操作，可能是更新数据，也可能是更新 Dom。除此之外，我们还会在 componentWillUnmount 的时候解绑一些事件监听防止内存泄露。这些都导致了组件维护成本的增大。而在 function 组件中，又没有这些生命周期，因此 Hooks 使用 Effect Hooks 来取代这些生命周期，完成一部分能力。

看一下官方给出的动态更改 title 的 demo：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

import { useState, useEffect } from 'react';

function Example() {
  const [count, setCount] = useState(0);

  // Similar to componentDidMount and componentDidUpdate:
  useEffect(() => {
    // Update the document title using the browser API
    document.title = `You clicked ${count} times`;
  });

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

在 useEffect 之前，我们需要在 componentDidMount 和 componentDidUpdate 中同时去调用更改 title 的方法，以完成组件初始化的状态和数据更新的状态。useEffect 传递一个函数给 React，React 在组件渲染完成后和更新后调用这个函数来完成上述功能。默认情况下，它在第一次渲染之后和每次更新之后都运行。

可以将 useEffect Hook 视为 componentDidMount，componentDidUpdate 和 componentWillUnmount 的组合。

那 useEffect 什么时候执行 componentWillUnmount 的操作呢？

如果 useEffect 中返回一个函数，在 React 卸载当前的组件的时候，会执行这个函数，用于清理 effect。

对比需要清理 effect 和不需要清理 effect 的两种写法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

function FriendStatusWithCounter(props) {
  const [count, setCount] = useState(0);
  useEffect(() => {
    document.title = `You clicked ${count} times`;
  });

  const [isOnline, setIsOnline] = useState(null);
  useEffect(() => {
    ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);
    return () => {
      ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);
    };
  });

  function handleStatusChange(status) {
    setIsOnline(status.isOnline);
  }

  return (/*...*/);
}  

通过跳过 Effect 来优化性能。

通常，每次组件渲染或者更新都去执行某些逻辑会带来无谓的消耗，所以我们经常会写这样的代码：

1
2
3
4
5

componentDidUpdate(prevProps, prevState) {
  if (prevState.count !== this.state.count) {
    document.title = `You clicked ${this.state.count} times`;
  }
}

只有组件更新前后的 state.count 发生变化的时候，才去更新 title。

用 Hooks 可以更简单地处理这个问题

1
2
3

useEffect(() => {
  document.title = `You clicked ${count} times`;
}, [count]); // Only re-run the effect if count changes

给 useEffect 传入第二个参数，这个参数是一个数组。如果组件重新渲染，只有这个 count 发生变化的时候 React 才会执行函数 中的内容，否则会直接跳过这个 effect。如果数组中是多个参数，那么只要其中一个发生变化，React 都会执行函数中的内容。

这也适用于具有清理阶段的 effect ：

1
2
3
4
5
6

useEffect(() => {
  ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);
  return () => {
    ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);
  };
}, [props.friend.id]); // Only re-subscribe if props.friend.id changes

如果希望 effect 只在组件 componentDidMount 和 componentWillUnmount 的时候执行，则只需要给第二个参数传一个空数组即可。传入一个空数组 [] 输入告诉 React 你的 effect 不依赖于组件中的任何值，因此该 effect 仅在 mount 时运行，并且在 unmount 时执行清理，从不在更新时运行。

Hooks 的规则

React Hooks 其实不仅仅是功能层面的增强，也给 React 注入了新的软件思想。这就是最近几年开始流行的 “约定大于配置”，比如 Hooks 函数必须使用 use 开头，还有接下来要讲的规则。前面在我的文章 webpack4 新特性 也提到了这个内容。

只在顶层调用 Hooks

Hooks 只能在顶层调用，不要在循环，条件或嵌套函数中调用 Hook。原因是 React 需要保证每次组件渲染的时候都以相同的顺序调用 Hooks。

假如一个组件中有多个 Hooks，React 如何知道哪个 state(状态) 对应于哪个 useState 调用呢？答案是 React 依赖于调用 Hooks 的顺序。本质上来说 Hooks 就是数组（React hooks: not magic, just arrays）。每次执行 useState 都会改变下标，如果 useState 被包裹在 condition 中，那每次执行的下标就可能对不上，导致 useState 更新错数据。

只能在 React Function 中调用 Hooks

Hooks 只能在 React function 组件中调用，或者在自定义 Hooks 中调用。通过遵循此规则，可以确保组件中的所有 stateful （有状态）逻辑在其源代码中清晰可见。

eslint

eslint-plugin-react-hooks 可以保证强制执行上述两个规则。

1

$ npm install eslint-plugin-react-hooks@next

1
2
3
4
5
6
7
8
9
10
11

// Your ESLint configuration
{
  "plugins": [
    // ...
    "react-hooks"
  ],
  "rules": {
    // ...
    "react-hooks/rules-of-hooks": "error"
  }
}

自定义 Hooks

自定义 Hooks 就是将组件之间需要共有的逻辑抽出来写成单独的函数。与一般的函数的区别是，自定义 Hooks 是一个以 use 开头的函数，内部可以调用其它的 Hooks。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

import { useState, useEffect } from 'react';

function useFriendStatus(friendID) {
  const [isOnline, setIsOnline] = useState(null);

  function handleStatusChange(status) {
    setIsOnline(status.isOnline);
  }

  useEffect(() => {
    ChatAPI.subscribeToFriendStatus(friendID, handleStatusChange);
    return () => {
      ChatAPI.unsubscribeFromFriendStatus(friendID, handleStatusChange);
    };
  });

  return isOnline;
}

export useFriendStatus;

在另外一个组件中，将其引入后，就可以使用了

1
2
3
4
5
6
7
8
9
10
11

import {useFriendStatus} from 'hooks/xxx.js';

function FriendListItem(props) {
  const isOnline = useFriendStatus(props.friend.id);

  return (
    <li style={{ color: isOnline ? 'green' : 'black' }}>
      {props.friend.name}
    </li>
  );
}

可以看出，自定义 Hooks 就是一个 JavaScript 函数而已，并没有什么特别。不过需要注意的是，自定义 Hooks 函数也必须以 use 开头（规约优先）。

useContext

1

const context = useContext(Context);

接受一个 context（上下文）对象（从 React.createContext 返回的值）并返回当前 context 值，当提供程序更新时，此 Hook 将使用最新的 context 值触发重新渲染。

useReducer

1

const [state, dispatch] = useReducer(reducer, initialState);

useReducer 可以理解为 Redux 的 Hooks，接受的第一个参数是 (state, action) => newState 的 reducer，并返回与 dispatch 方法配对的当前状态。

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

const initialState = {count: 0};

function reducer(state, action) {
  switch (action.type) {
    case 'reset':
      return initialState;
    case 'increment':
      return {count: state.count + 1};
    case 'decrement':
      return {count: state.count - 1};
    default:
      // A reducer must always return a valid state.
      // Alternatively you can throw an error if an invalid action is dispatched.
      return state;
  }
}

function Counter({initialCount}) {
  const [state, dispatch] = useReducer(reducer, {count: initialCount});
  return (
    <>
      Count: {state.count}
      <button onClick={() => dispatch({type: 'reset'})}>
        Reset
      </button>
      <button onClick={() => dispatch({type: 'increment'})}>+</button>
      <button onClick={() => dispatch({type: 'decrement'})}>-</button>
    </>
  );
}

useReducer 接受可选的第三个参数 initialAction，表示在组件初始化期间执行的操作。比如利用 props 传递的值来初始化 state 的操作。

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
35
36
37

const initialState = {count: 0};

function reducer(state, action) {
  switch (action.type) {
    case 'reset':
      return {count: action.payload};
    case 'increment':
      return {count: state.count + 1};
    case 'decrement':
      return {count: state.count - 1};
    default:
      // A reducer must always return a valid state.
      // Alternatively you can throw an error if an invalid action is dispatched.
      return state;
  }
}

function Counter({initialCount}) {
  const [state, dispatch] = useReducer(
    reducer,
    initialState,
    {type: 'reset', payload: initialCount},
  );

  return (
    <>
      Count: {state.count}
      <button
        onClick={() => dispatch({type: 'reset', payload: initialCount})}>
        Reset
      </button>
      <button onClick={() => dispatch({type: 'increment'})}>+</button>
      <button onClick={() => dispatch({type: 'decrement'})}>-</button>
    </>
  );
}

useRef

1

const refContainer = useRef(initialValue);

useRef 返回一个可变的 ref 对象，通过 .current 属性对其进行访问，返回的对象将存留在整个组件的生命周期中。

1
2
3
4
5
6
7
8
9
10
11
12
13

function TextInputWithFocusButton() {
  const inputEl = useRef(null);
  const onButtonClick = () => {
    // `current` points to the mounted text input element
    inputEl.current.focus();
  };
  return (
    <>
      <input ref={inputEl} type="text" />
      <button onClick={onButtonClick}>Focus the input</button>
    </>
  );
}

useImperativeMethods

1

useImperativeMethods(ref, createInstance, [inputs]);

useImperativeMethods 与 forwardRef 共同使用，表示强制方法。通过 ref 将子组件的某个方法暴露给父组件。

子组件：

1
2
3
4
5
6
7
8
9
10

function FancyInput(props, ref) {
  const inputRef = useRef();
  useImperativeMethods(ref, () => ({
    focus: () => {
      inputRef.current.focus();
    }
  }));
  return <input ref={inputRef} ... />;
}
FancyInput = forwardRef(FancyInput);

父组件：

1
2
3
4
5
6
7
8
9
10
11

function FancyParent() {
  const fancyInputRef = useRef(null);
  useEffect(() => {
    fancyInputRef.current.focus(); 
  });

  return (
    <FancyInput ref={fancyInputRef} />
  );
}

useLayoutEffect

用法与 useEffect 相同，但在所有 DOM 变化后同步触发。使用它来从 DOM 读取布局并同步重新渲染。 在浏览器绘制之前 useLayoutEffect 将同步刷新。

useEffect 中的函数会在 layout(布局) 和 paint(绘制) 后触发。 这使得它适用于许多常见的 side effects ，例如设置订阅和事件处理程序，因为大多数类型的工作不应阻止浏览器更新屏幕。

但是如果 effect 不能够推迟，比如要 DOM 改变必须在下一次绘制之前同步触发，使用 useLayoutEffect 会更加合适。

Hooks API

参考 Hooks API Reference

总结

Hooks 通过设定某些特殊函数，在 React 组件内部“钩住”其生命周期和 state，帮助开发者解决一些逻辑复用的问题，通过自定义的 Hooks 对代码进行抽象，让我们写出更加符合函数式编程的规范，同时也减少了层层嵌套带来的问题。

参考文档

• 精读《React Hooks》
• React docs - Introducing Hooks
  

Koa 是一个非常轻量的 web 开发框架，由 Express 团队打造。相较于 Express，Koa 使用 async 函数解决异步的问题，并且完全脱离中间件，非常优雅，而且 Koa 代码简洁友好，很适合初学者阅读。

Koa 代码结构

可以看到 Koa 的结构非常简单，lib 文件夹下面放着 koa 的核心文件：

application.js

application 是 koa 的入口文件，export 出一个 Application 的类（继承自 events.Emitter）。application 有以下几个主要（public）的 api：

• listen: 实现对 http.createServer() 的封装，传入的参数 callback 中完成中间件合并，错误监听以及上下文的创建和 request 的处理。

• use: 我们通常使用 app.use(function) 将中间件添加到应用程序。use 方法中，koa 将中间件（函数）添加到 this.middleware 数组中。

• callback: koa-compose 将中间件组合在一起, 然后返回一个 request 回调函数，同时给 listen 作为回调。

• toJSON: 返回一个去除私有属性（_开头）的对象。

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

module.exports = class Application extends Emitter {
  listen(...args) {
    debug('listen');
    const server = http.createServer(this.callback());
    return server.listen(...args);
  }
  
  use(fn) {
    if (typeof fn !== 'function') throw new TypeError('middleware must be a function!');
    this.middleware.push(fn);
    return this;
  }
  
  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;
  }
}

context.js

context 是我们在使用 koa 中最常接触到的 ctx，就是一个暴露出来的对象。context 中实现了对 cookie 的 get set 操作，这也是我们可以直接使用 ctx 对 cookie 操作的原理。除此之外，ctx 中最重要的是 delegate，也就是委托。我们简单看一下代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

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');

以上的 proto 就是 ctx，实现了对 response 对象的代理，比如我们可以通过使用 ctx.status 来访问 ctx.response.status。

同样的，request 上面的属性和方法也被代理到了 ctx 中：

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

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');

ctx.hostname 即是 ctx.request.hostname。

request.js && response.js

request.js 和 response.js 中完成对 Koa Request/Response 对象的封装，可以通过 request.xxx/response.xxx 对其进行操作。其中使用了很多 get 和 set 方法。

实现一个简单的 moa

• 首先需要完成对 http 模块的封装，可以使用创建服务器。
• 然后完成 request 和 response 对象的封装，以及将其代理到 context 对象上。
• 然后需要处理中间件以及实现洋葱模型。
• 最后需要完成对错误的处理和异常捕获。

SRI 全称 Subresource Integrity - 子资源完整性，是指浏览器通过验证资源的完整性（通常从 CDN 获取）来判断其是否被篡改的安全特性。

通过给 link 标签或者 script 标签增加 integrity 属性即可开启 SRI 功能，比如：

1

<script type="text/javascript" src="//s.url.cn/xxxx/xxx.js?_offline=1" integrity="sha256-mY9nzNMPPf8oL3CJss7THIEoXAC2ToW1tEX0NBhMvuw= sha384-ncIKElSEk2OR3YfjNLRSY35mzt0CUwrpNDVS//iD3dF9vxrWeZ7WPlAPJTqGkSai" crossorigin="anonymous"></script>

integrity 值分成两个部分，第一部分指定哈希值的生成算法（sha256、sha384 及 sha512），第二部分是经过 base64 编码的实际哈希值，两者之间通过一个短横（-）分割。integrity 值可以包含多个由空格分隔的哈希值，只要文件匹配其中任意一个哈希值，就可以通过校验并加载该资源。上述例子中我使用了 sha256 和 sha384 两张 hash 方案。

备注：crossorigin="anonymous" 的作用是引入跨域脚本，在 HTML5 中有一种方式可以获取到跨域脚本的错误信息，首先跨域脚本的服务器必须通过 Access-Controll-Allow-Origin 头信息允许当前域名可以获取错误信息，然后是当前域名的 script 标签也必须声明支持跨域，也就是 crossorigin 属性。link、img 等标签均支持跨域脚本。如果上述两个条件无法满足的话， 可以使用 try catch 方案。

为什么要使用 SRI

在 Web 开发中，使用 CDN 资源可以有效减少网络请求时间，但是使用 CDN 资源也存在一个问题，CDN 资源存在于第三方服务器，在安全性上并不完全可控。

CDN 劫持是一种非常难以定位的问题，首先劫持者会利用某种算法或者随机的方式进行劫持（狡猾大大滴），所以非常难以复现，很多用户出现后刷新页面就不再出现了。之前公司有同事做游戏的下载器就遇到这个问题，用户下载游戏后解压不能玩，后面通过文件逐一对比找到原因，原来是 CDN 劫持导致的。怎么解决的呢？听说是找 xx 交了保护费，后面也是利用文件 hash 的方式，想必原理上也是跟 SRI 相同的。

所幸的是，目前大多数的 CDN 劫持只是为了做一些夹带，比如通过 iframe 插入一些贴片广告，如果劫持者别有用心，比如 xss 注入之类的，还是非常危险的。

开启 SRI 能有效保证页面引用资源的完整性，避免恶意代码执行。

浏览器如何处理 SRI

• 当浏览器在 script 或者 link 标签中遇到 integrity 属性之后，会在执行脚本或者应用样式表之前对比所加载文件的哈希值和期望的哈希值。
• 当脚本或者样式表的哈希值和期望的不一致时，浏览器必须拒绝执行脚本或者应用样式表，并且必须返回一个网络错误说明获得脚本或样式表失败。

使用 SRI

通过使用 webpack 的 html-webpack-plugin 和 webpack-subresource-integrity 可以生成包含 integrity 属性 script 标签。

1
2
3
4
5
6
7
8
9
10
11
12
13

import SriPlugin from 'webpack-subresource-integrity';
 
const compiler = webpack({
    output: {
        crossOriginLoading: 'anonymous',
    },
    plugins: [
        new SriPlugin({
            hashFuncNames: ['sha256', 'sha384'],
            enabled: process.env.NODE_ENV === 'production',
        })
    ]
});

那么当 script 或者 link 资源 SRI 校验失败的时候应该怎么做呢？

比较好的方式是通过 script 的 onerror 事件，当遇到 onerror 的时候重新 load 静态文件服务器之间的资源：

1
2
3

<script type="text/javascript" src="//11.url.cn/aaa.js"
        integrity="sha256-xxx sha384-yyy"
        crossorigin="anonymous" onerror="loadjs.call(this, event)"></script>

loadjs:

1
2
3
4
5
6
7
8
9
10
11
12

function loadjs (event) {
  // 上报
  ...
  // 重新加载 js
  return new Promise(function (resolve, reject) {
    var script = document.createElement('script')
    script.src = this.src.replace(/\/\/11.src.cn/, 'https://x.y.z') // 替换 cdn 地址为静态文件服务器地址
    script.onload = resolve
    script.onerror = reject
    document.getElementsByTagName('head')[0].appendChild(script);
  })
}

这种方式的缺点是目前 onerror 中的 event 参数无法区分究竟是什么原因导致的错误，可能是资源不存在，也可能是 SRI 校验失败，不过目前来看，除非有统计需求，无差别对待并没有多大问题。

除此之外，我们还需要使用 script-ext-html-webpack-plugin 将 onerror 事件注入进去：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

const ScriptExtHtmlWebpackPlugin = require('script-ext-html-webpack-plugin');

module.exports = {
  //...
  plugins: [
    new HtmlWebpackPlugin(),
    new SriPlugin({
      hashFuncNames: ['sha256', 'sha384']
    }),
    new ScriptExtHtmlWebpackPlugin({
      custom: {
        test: /.js*/,
        attribute: 'onerror="loadjs.call(this, event)" onsuccess="loadSuccess.call(this)"'
      }
    })
  ]
}

然后将 loadjs 和 loadSuccess 两个方法注入到 html 中，可以使用 inline 的方式。

还在知乎上看到一位大神另辟蹊径，通过 jsonp 的方式解决 CDN 劫持。个人感觉这种方式目前能够完美应对 CDN 劫持的主要原因是运营商通过文件名匹配的方式进行劫持，作者的方式就是通过 onerror 检测拦截，并且去掉资源文件的 js 后缀以应对 CDN 劫持。

应对流量劫持，前端能做哪些工作？

Kong 是一款基于 OpenResty 的 API 网关平台，在客户端和（微）服务之间转发 API 通信。Kong 通过插件的方式扩展自己的功能，其中包括身份验证、安全控制、流量控制、熔断机制、日志、黑名单、API 分发等等众多功能。下图是官网给出的传统项目架构和使用 Kong 的架构：

Next-Generation API Platform for Modern Architectures。

可以看到，使用 Kong 之后，内部服务开发者只需要 focus 具体业务的实现，网关层提供 API 分发、管理、维护等功能，开发者只需要简单的配置就可以把自己开发的服务发布出去，同时置于网关的保护之下。

OpenResty 简介

OpenResty® 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。

Kong 三大组件

• Kong Server ：基于 nginx 的服务器，用来接收 API 请求。
• Apache Cassandra/PostgreSQL：用来存储操作数据，本文以 PostgreSQL 为例进行讲解。
• Kong dashboard：UI 管理工具。

Kong 特性

• 可扩展：通过简单地添加机器来进行水平扩展，可以用较低的负载处理任何请求。
• 模块化：通过 RESTful API 安装和配置插件。
• 在任何基础设施上运行：Kong 可以部署在云端、机房、或者混合环境，包括单个或多个数据中心。

安装以及使用

Kong 可以安装运行在大部分 Linux 分布式平台和 macOS 上。全部安装方式请查看 安装 Kong 社区版。

macOS Homebrew

(1) 安装 Kong

1
2

$ brew tap kong/kong
$ brew install kong

(2) 准备数据库

安装 PostgresSQL，在 Kong 启动之前指定数据库和用户。

1

$ CREATE USER kong; CREATE DATABASE kong OWNER kong;

由于对 Postgres 并不熟悉，我使用 GUI 工具 pgAdmin4 完成 User 和 Database 的创建。

(3) 准备 kong 配置文件

kong 默认使用 /etc/kong/kong.conf 作为启动的配置文件，因此我们在 /etc/kong/ 目录下创建 kong.conf 文件，内容如下：

1
2
3
4

database = postgres
pg_port = 5432
pg_user = kong
pg_password = **** # 如果你刚才设置密码的话

全部 kong 的配置文件你可以查看 kong.conf.default。

(4) 启动 kong

1
2

$ kong migrations up
$ kong start

这个时候 kong 就启动起来了。然后我们可以通过下面的命令测试：

1

$ curl -i http://localhost:8001/

(5) 更多 kong 的命令

1
2
3
4
5

$ kong check /etc/kong/kong.conf # 检验 kong 配置文件是否正确
$ kong migrations up [-c /etc/kong/kong.conf] # 通过配置文件准备数据存储
$ kong start [-c /etc/kong/kong.conf] # 启动 kong
$ kong stop 
$ kong reload

(6) kong 启动后监听了 4 个端口

• 8000: Kong 监听来自客户端的 HTTP 请求的，并将此请求转发到上游服务。
• 8443: 与 8000 端口相同，不过只监听 HTTPS 请求。
• 8001: 管理员对 Kong 进行配置管理的端口。
• 8444: 管理员监听 HTTPS 请求的端口。

Docker

(1) 创建一个名为 kong-net 的 network

1

$ docker network create kong-net

(2) 启动数据库（PostgreSQL）

1
2
3
4
5
6

$ docker run -d --name kong-database \
              --network=kong-net \
              -p 5432:5432 \
              -e "POSTGRES_USER=kong" \
              -e "POSTGRES_DB=kong" \
              postgres:9.6

这个时候命令行会显示 Unable to find image 'postgres:9.6' locally，然后会自动帮我买下载 postgres 的 image。

(3) 准备数据库

1
2
3
4
5
6

$ docker run --rm \
    --network=kong-net \
    -e "KONG_DATABASE=postgres" \
    -e "KONG_PG_HOST=kong-database" \
    -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
    kong:latest kong migrations up

(4) 启动 Kong

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$ docker run -d --name kong \
    --network=kong-net \
    -e "KONG_DATABASE=postgres" \
    -e "KONG_PG_HOST=kong-database" \
    -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
    -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
    -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
    -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
    -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
    -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \
    -p 8000:8000 \
    -p 8443:8443 \
    -p 8001:8001 \
    -p 8444:8444 \
    kong:latest

(5) 使用 Kong

1

$ curl -i http://localhost:8001/

更详细的内容可以查看 5 分钟快速开始

kong-dashboard

Kong dashboard 是一个基于 node 实现的管理 Kong 网关设置的 GUI 工具。

使用 npm：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# Install Kong Dashboard
npm install -g kong-dashboard

# Start Kong Dashboard
kong-dashboard start --kong-url http://localhost:8001

# Start Kong Dashboard on a custom port
kong-dashboard start \
  --kong-url http://localhost:8001 \
  --port [port]

# Start Kong Dashboard with basic auth
kong-dashboard start \
  --kong-url http://localhost:8001 \
  --basic-auth user1=password1 user2=password2

# See full list of start options
kong-dashboard start --help

使用 Docker：

1
2
3
4
5
6
7
8
9
10
11
12
13

# Start Kong Dashboard
docker run --rm -p 8080:8080 pgbi/kong-dashboard start --kong-url http://kong:8001

# Start Kong Dashboard on a custom port
docker run --rm -p [port]:8080 pgbi/kong-dashboard start --kong-url http://kong:8001

# Start Kong Dashboard with basic auth
docker run --rm -p 8080:8080 pgbi/kong-dashboard start \
  --kong-url http://kong:8001
  --basic-auth user1=password1 user2=password2

# See full list of start options
docker run --rm -p 8080:8080 pgbi/kong-dashboard start --help

Kong 使用

本质上 Kong 是作用于请求和响应之间的一层代理，我们可以通过 RESTful 的形式管理 API。

添加一个 API

使用 curl 命令行：

1
2
3
4
5

$ curl -i -X POST \
  --url http://localhost:8001/apis/ \
  --data 'name=example-api' \
  --data 'hosts=example.com' \
  --data 'upstream_url=https://lz5z.com'

或者使用 kong-dashboard，在 http://localhost:8080/#!/apis 编辑查看：

这时，Kong 已经做好了对 HOST 是 example.com 的 api 的代理请求，并且将其代理到 https://lz5z.com 上。

1
2
3

$ curl -i -X GET \
  --url http://localhost:8000/ \
  --header 'Host: example.com'

总结

以上只是 Kong 简单的安装和工具的使用，由于之前对 docker、PostgresSQL 等周边工具并不熟悉，所以学习起来需要扩展的东西比较多，暂时先写到这里吧。关于 Kong 插件的使用已经编写，用户操作、授权、负载均衡、熔断等信息，这里先埋坑，后面有时间再补上吧。

在手机端网页开发过程中，我们经常会遇到滚动点停误触的问题，最开始想到的解决办法就是判断当前页面（DOM）是否在滚动，如果在滚动，就取消点击或者其他事件。但是在判断页面是否在滚动的时候出现了一些问题，最常见的就 uiwebview scroll 事件延迟，导致我们无法准确判断当前页面（DOM）是否还在滚动。于是想到了使用 requestAnimationFrame 判断某个元素的位置是否发生变化来标识当前页面（DOM）是否在滚动。

常见的滚动点停误触

这是移动端的前端开发中实际遇到的一个问题，当我们的页面出现滚动条的时候，用手滑动屏幕，屏幕上页面内容会快速滚动，不会因为手已经离开了屏幕而滚动停止。当我们想要停止滚动的时候，轻轻点击屏幕，让屏幕停止。但是这个时候有个问题，如果屏幕上点击的位置恰好可以点击，这个时候就会误触。还有一种常见的情况是，滚动已经停止了，点击屏幕发生在其之后，但是感觉像是发生了误触。

常用的解决办法

最先想到的解决办法当然是加锁，当页面在滚动的时候，就禁止元素的点击或者 touch 事件。但是这里存在一个问题，有些情况下，我们并不能正确的获得当前页面是否正在发生滚动。比如在 iOS UIWebViews 中, 在视图的滚动过程中，scroll 事件不会被触发；在滚动结束后，scroll 才会触发，参见 Bootstrap issue #16202 。不能正确获取 scroll 事件就无法正确判断当前页面是否正在滚动。看起来我们陷入了僵局。

新的解决方案

我们放弃 scroll 事件，使用别的方式判断页面是否滚动。最先想到的就是通过获取某个元素的相对位置，如果在两帧之内位置没有发生变化，那不就证明了当前页面已经不滚动了吗。

如何判断元素位置没有发生改变

我们首先给 window 上绑定 touch 事件：

1
2

window.addEventListener('touchmove', this.onWindowTouchMove.bind(this))
window.addEventListener('touchend', this.onWindowTouchEnd.bind(this))

如果发生 touchmove，就认为用户滑动了，在 touchend 的时候通过 getBoundingClientRect() 获取元素位置，再使用 requestAnimationFrame() 判断在两帧之间元素的位置是否发生变化，以此来标识页面滚动是否停止。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

let element = e.target
let rectObject0 = element.getBoundingClientRect()
let _this = this
window.cancelAnimationFrame(raf)

function step (timestamp) {
    _this.scrollTime = Date.now()
    let rectObject1 = element.getBoundingClientRect()
    if (rectObject0.top !== rectObject1.top) {
        rectObject0 = rectObject1
        raf = window.requestAnimationFrame(step)
    } else {
        _this.isScrolling = false
        window.cancelAnimationFrame(raf)
        return
    }
}

raf = window.requestAnimationFrame(step)

完整代码 scrolling-observer：

包已经发布在 npm 上了，可以 npm 或者 yarn 使用：

1
2

$ npm install scrolling-observer --save
$ yarn add scrolling-observer

使用方式：

1
2
3
4
5
6
7
8
9
10

import scroll from 'scrolling-observer'

// 初始化
scroll()
// 页面是否在滚动
let isScrolling = scroll().isScrolling
// 最后滚动时间
let scrollTime = scroll().scrollTime
// destroy
scroll().destroy()

需要使用 ssr 的同学请注意不要在 node 端初始化，因为构造函数中使用了 window 对象。

总结

简单通过判断两帧之间元素的相对位置是否发生变化来判断页面是否正在滚动。使用 requestAnimationFrame 并且只在 touchend 后触发检查机制，对页面性能也不会造成太大的影响。目前来看是不错的解决方案。

关于 webpack 入门的文章可以参考 webpack 从入门到放弃。
关于 webpack 性能优化的内容可以参考 webpack 打包优化。
关于 webpack4 全部新的特性可以查看官方的 releases。

学习参考

学习一项新知识最好能站在巨人的肩膀上，其中 angular-cli、create-react-app 和 vue-cli 中对 webpack4 中的使用都是我们学习和模仿的对象。

参考 create-react-app

使用 npx 创建 react-demo，创建之后 npm run eject 就可以看到它详细的 webpack 配置了。

1
2
3

$ npx create-react-app react-demo
$ cd react-demo
$ npm run eject / yarn eject

不过比较遗憾的是正式版本的 create-react-app 暂时还不支持 webpack4，我们可以使用 react-scripts@2.0.0-next.3e165448 来体验 webpack4 的特性。

1
2
3
4

$ # Create a new application
$ npx create-react-app@next --scripts-version=2.0.0-next.3e165448 react-demo
$ # Upgrade an existing application
$ yarn upgrade react-scripts@2.0.0-next.3e165448

其中 config 目录下的与 webpack 相关的三个文件是非常好的学习和借鉴的对象，可以说适应于绝大多数中小型项目。

参考 vue-cli

Vue CLI3 简直可以说是学习和使用 vue 中一个无敌的存在，其中 @vue/cli-service 中集成了 webpack 的默认配置，带来开箱即用的快感；不过 Vue CLI 没有像 angular-cli 和 create-react-app 那样提供 eject 命令，而是通过 vue.config.js 进行包括 webpack 在内的全局配置。其可视化工具 vue ui 中的 inspect 可以查看 webpack 参数，非常强大。

Vue CLI3 内部的 webpack 配置是通过 webpack-chain 维护的，这个库提供了一个 webpack 原始配置的上层抽象，使其可以定义具名的 loader 规则和具名插件，并有机会在后期进入这些规则并对它们的选项进行修改。

如果你的项目也有链式访问特定的 loader 的需求的话，不妨参考一下 Vue CLI3。

如果不希望使用 webpack-chain 的话，可以参考其它比较成熟的 vue 项目，比如 vue-element-admin 也非常具有借鉴意义。

webpack4 升级建议

• webpack4 依赖 node 版本 >= 6.11.5，node4 及其以下版本将不再支持。所以首先需要检查 node 是否需要升级。
• 还需要安装 webpack-cli 到 devDependencies 中。
• 如果是升级一个已有项目的话，可以使用 npm outdated 查看与 webpack 相关的 loader 和 plugin 是否需要升级。
• extract-text-webpack-plugin 让位于 mini-css-extract-plugin。
• html-webpack-plugin 在使用过程中如果遇到 thrownewError('Cyclic dependency'+nodeRep) 的错误的话，可以使用 Alpha 版本 npm i--save-dev html-webpack-plugin@next。

由于 webpack4 以后对 css 模块支持的逐步完善和 commonChunk 插件的移除，在处理 css 文件提取的计算方式上也做了些调整。所以之前一直使用的 extract-text-webpack-plugin 也完成了它的历史使命，将让位于 mini-css-extract-plugin。

extract-text-webpack-plugin 会将 css 内联在 js 中，这样带来的问题是：css 或者 js 的改动都会影响整个 bundle 的缓存。而 mini-css-extract-plugin 在 code Splitting 的时候会将原先内联写在每一个 js chunk bundle 的 css，单独拆成了一个个 css 文件。然后再通过 optimize-css-assets-webpack-plugin 这个插件对 css 进行压缩和优化。

备注：optimize-css-assets-webpack-plugin 默认使用 cssnano 进行 css 代码优化，但是也会导致一些问题，比如我之前遇到的 z-index 重新计算的问题和 keyframes 重命名的问题：解决 webpack 打包后 z-index 重新计算的问题。

webpack4 带来的变化

可能是受到 parcel（一款号称快速，零配置的 Web 应用程序打包器）的影响，webpack4 也引入了零配置的概念，遵从软件行业更先进的『规约大于配置』的理念。

模式（mode）

mode 有三个值：

（1）可以在启动命令后加入参数使用：

1
2
3
4

"scripts": {
  "dev": "webpack --mode development",
  "build": "webpack --mode production"
}

（2）也可以在配置文件中加入 mode 属性：

• mode: development

1
2
3
4
5
6
7
8
9

// webpack.development.config.js
module.exports = {
+ mode: 'development'
- plugins: [
-   new webpack.NamedModulesPlugin(), // 当开启 HMR 的时候使用该插件会显示模块的相对路径
-   new webpack.NamedChunksPlugin(),  // 根据文件名来生成稳定的 chunkid
-   new webpack.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("development") }) // 向代码注入了 NODE\_ENV 这个环境变量
- ]
}

development 模式默认开启了 NamedChunksPlugin 和 NamedModulesPlugin 方便调试，提供了更完整的错误信息，更快的重新编译的速度。

• mode: production

1
2
3
4
5
6
7
8
9
10

// webpack.production.config.js
module.exports = {
+  mode: 'production',
-  plugins: [
-    new UglifyJsPlugin(/* ... */), // JS 代码压缩
-    new webpack.optimize.ModuleConcatenationPlugin(), // 作用域提升(scope hoisting)，提升代码在浏览器中的执行速度
-    new webpack.NoEmitOnErrorsPlugin(), // 在编译出现错误时，跳过输出阶段
-    new webpack.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("production") })
-  ]
}

production 模式提供代码压缩和代码分割，同时 webpack 也会自动进行 Scopehoisting 和 Tree-shaking。

可以看出 mode 本质上是提供了一些默认的配置，以此来简化 webpack 的使用门槛。

optimization(优化)

optimization 是 webpack4 中最大的改进，其中包括代码压缩，分割，优化等功能。

使用 optimization.splitChunks 进行分包

webpack4 移除 CommonsChunkPlugin，取而代之的是两个新的配置项（optimization.splitChunks 和 optimization.runtimeChunk）来进行分包。

我们来看下 create-react-app 生成的关于分包的配置：

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

const UglifyJsPlugin = require('uglifyjs-webpack-plugin');
const OptimizeCSSAssetsPlugin = require('optimize-css-assets-webpack-plugin'); // 用来压缩以及优化 css
module.exports = {
  mode: 'production',
  optimization: {
    minimizer: [
      new UglifyJsPlugin({
        uglifyOptions: {/* ... */},
        // Use multi-process parallel running to improve the build speed
        // Default number of concurrent runs: os.cpus().length - 1
        parallel: true,
        // Enable file caching
        cache: true
      }),
      new OptimizeCSSAssetsPlugin({ cssProcessorOptions: { safe: true } }),
    ],
    // Automatically split vendor and commons
    splitChunks: {
      chunks: 'all',
      name: 'vendors'
    },
    // Keep the runtime chunk seperated to enable long term caching
    runtimeChunk: true
  }
}

在分包功能上主要使用 splitChunks 和 runtimeChunk 两个参数。

optimization.splitChunks

默认情况下 splitChunks 的配置就适用于大多数用户。webpack4 将会按照以下规则自动进行分包：

• 新的 chunk 是否被分享或者是否来自 node_modules。
• 新的 chunk 在压缩和 gzip 前是否大于 30kb。
• 按需加载 chunk 的并发请求数量小于等于 5 个。
• 页面初始化时需要加载的 chunk 并发数量小于等于 3 个。

为了满足后面两个条件，webpack 有可能受限于包的最大数量值，生成的代码体积往上增加。

默认配置对应的参数如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

optimization: {
  splitChunks: {
    chunks: 'async',
    minSize: 30000,
    minChunks: 1,
    maxAsyncRequests: 5,
    maxInitialRequests: 3,
    automaticNameDelimiter: '~', 
    name: true,
    cacheGroups: {
      vendors: {
        test: /[\\/]node_modules[\\/]/,
        priority: -10
      },
      default: {
        minChunks: 2,
        priority: -20,
        reuseExistingChunk: true
      }
    }
  }
}

(1) splitChunks.chunks

表示哪些 chunks 会被分割，可以提供字符串或者 function 作为参数。如果传字符串的话，值可以是 “all”、“async”、“initial”。“all” 表示无论 chunk 是 async 还是 non-async 都可以被共享。

(2) splitChunks.cacheGroups

默认模式会将所有来自 node_modules 的模块分配到 一个叫 vendors 的缓存组；所有重复引用至少两次的代码，会被分配到 default 的缓存组。

一个模块可以被分配到多个缓存组，优化策略会将模块分配至跟高优先级别（priority）的缓存组，或者会分配至可以形成更大体积代码块的组里。

默认来说，缓存组会继承 splitChunks 的配置。所有上面列出的选择都是可以用在缓存组里的：chunks, minSize, minChunks, maxAsyncRequests, maxInitialRequests, name。

可以通过 optimization.splitChunks.cacheGroups.default: false 禁用 default 缓存组。

可以使用如下的方式提取公共代码：

1
2
3
4
5
6
7

cacheGroups: {
  commons: {
    name: "commons",
    chunks: "initial",
    minChunks: 2
  }
}

(3) minSize: 形成一个新代码块最小的体积，默认是 30 kb。
(4) minChunks: 在分割之前，这个代码块最小应该被引用的次数（保证代码块复用性，默认值为 1 ，即不需要多次引用也可以被分割）。
(5) maxInitialRequests: 一个入口最大的并行请求数，默认是 3。
(6) maxAsyncRequests: 按需加载时候最大的并行请求数，默认是 5。
(7) name: 要控制代码块的命名，可以用 name 参数来配置，当不同分割代码块被赋予相同名称时候，他们会被合并在一起。如果赋予一个神奇的值 true，webpack 会基于代码块和缓存组的 key 自动选择一个名称。

optimization.runtimeChunk

webpack4 提供了 runtimeChunk 能让我们方便的提取 manifest，以前我们需要这样配置

1
2
3
4

new webpack.optimize.CommonsChunkPlugin({
  name: "manifest",
  minChunks: Infinity
});

webpack4 中则只需要

1
2
3
4
5

runtimeChunk: true,
// OR manifest
runtimeChunk: {
  name: "manifest"
}

通过 optimization.runtimeChunk: true 选项，webpack 会添加一个只包含运行时(runtime)额外代码块到每一个入口。
这个需要看场景使用，会导致每个入口都加载多一份运行时代码。其实打包生成的 runtime.js 非常的小，gzip 之后一般只有几 kb，但这个文件又经常会改变，导致我们每次都需要重新请求它，它的 http 耗时远大于它的执行时间了，所以建议不要将它单独拆包，而是将它内联到 index.html 之中。

1
2
3
4
5
6
7

const ScriptExtHtmlWebpackPlugin = require('script-ext-html-webpack-plugin') // 支持 prefetch preload
// 注意一定要在 HtmlWebpackPlugin 之后引用
// inline 的 name 和 runtimeChunk 的 name 保持一致

new ScriptExtHtmlWebpackPlugin({
  inline: /runtime..*.js$/
})

webpack 中的 runtime 和 manifest

在使用 webpack 构建的应用程序中，主要包含三种类型的代码：

• 我们自己编写的代码
• 源码依赖的第三方 library 或者 “vendor”
• webpack 的 runtime 和 manifest，管理所有模块的交互

runtime 以及伴随的 manifest 数据，主要是指：在浏览器运行时，webpack 用来连接模块化的应用程序的所有代码。

（1）runtime

在模块交互时，连接模块所需的加载和解析逻辑。包括浏览器中的已加载模块的连接，以及懒加载模块的执行逻辑。

（2）manifest

当编译器(compiler)开始执行、解析和映射应用程序时，它会保留所有模块的摘要信息。这个摘要的数据集合称为 “Manifest”，当完成打包并发送到浏览器时，在运行时通过 Manifest 来解析和加载模块。

无论选择哪种模块语法，那些 import 或 require 语句现在都已经转换为 __webpack_require__ 方法，此方法指向模块标识符(module identifier)。通过使用 manifest 中的数据，runtime 将能够查询模块标识符，检索出背后对应的模块。

可以理解为在应用程序运行时，编译器通过 manifest 中的数据来查找相应的模块，管理模块的加载和执行。

优化分包策略

根据业务的复杂程度，一般在我们的代码中存在以下几种类型的代码：

基础组件库：react/vue; redux/vuex/mobx; react-router/vue-router; axios;
UI 组件库：Ant Design/Element;
必要组件/公共组件：Nav; Footer; Header; 全局配置等
非必要组件/代码：自己封装的组件和函数
低频组件：富文本; Markdown-Editor; Echarts 等
业务代码：业务组件; 业务模块; 业务页面等

• 基础类库 chunk-libs

它是构成我们项目必不可少的一些基础类库，比如 vue 全家桶或者 reat 全家桶，它们的升级频率都不高，但每个页面都需要它们，还有一些全局被共用的，体积不大的第三方库也可以放在其中：比如 nprogress、js-cookie、clipboard 等。

也可以使用 webpack 的 dll 技术将这些代码抽取为动态链接库。

• UI 组件库

可以考虑将 UI 组件库也打包在 libs 中，不过相比于 chunk-libs，它的升级频率更高，并且体积更大，因此单独打包是更好的选择。

• 自定义组件/函数 chunk-commons

自定义组件可以选择单独打包成 bundle，也可以与业务代码打包在一起，还是要结合具体情况来看。

• 低频组件

低频组件和 chunk-commons 最大的区别是，它们只会在一些特定业务场景下使用，比如富文本编辑器、js-xlsx 等。webpack4 会根据这些库的大小（30kb）选择将其打包成独立的 bundle 或者 直接打包到具体的页面 bundle 中。

• 业务代码

一般按照页面来划分打包。

webpack4 plugins

webpack 插件是一个具有 apply 方法的 JavaScript 对象。apply 属性会被 webpack compiler 调用，并且 compiler 对象可在整个编译生命周期访问。

• 定义 apply 方法。
• 指定一个绑定到 webpack 自身的事件钩子。
• 使用 webpack 提供的 plugin API 操作构建结果。

1
2
3
4
5
6
7
8
9
10
11
12

const pluginName = 'BasicPlugin'

class BasicPlugin {
  constructor(options) {

  }
  apply(compiler) {
    compiler.hooks.run.tap(pluginName, compilation => {
      console.log('webpack 构建过程开始！')
    })
  }
}

使用这个插件

1
2
3
4
5
6

const BasicPlugin = require('./BasicPlugin.js')
module.export = {
  plugins:[
    new BasicPlugin(options),
  ]
}

插件运作原理

webpack 基于插件的运行模式非常强大，也是其能够迅速占领市场，社区活跃的主要原因。如果把 webpack 比作流水线，插件就是流水线上一个个工人。webpack 通过 Tapable 来组织这条复杂的流水线。

webpack 在运行过程中会广播事件，每个插件只需要监听它所关心的事件，就能加入到这条生产线中，从而改变生产线的运作。webpack 中基于观察者模式的事件流机制保证了其运行的有序性。

插件的核心是两个继承于 Tapable 的对象： Compiler 和 Compilation，它们是连接插件与 webpack 之间的桥梁。在插件代码的编写中，只要拿到了这两个对象，就可以实现广播和监听事件。

• Compiler 对象包含了 webpack 环境所有的的配置信息，包含 options，loaders，plugins 这些信息，这个对象在 webpack 启动时候被实例化，它是全局唯一的，可以简单地把它理解为 webpack 实例。
• Compilation 对象包含了当前的模块资源、编译生成资源、变化的文件等。当 webpack 以开发模式运行时，每当检测到一个文件变化，一次新的 Compilation 将被创建。Compilation 对象也提供了很多事件回调供插件做扩展。通过 Compilation 也能读取到 Compiler 对象。

Compiler 和 Compilation 的区别在于：Compiler 代表了整个 webpack 从启动到关闭的生命周期，而 Compilation 只是代表了一次新的编译。

插件事件流变化

webpack4 插件的编写方式与之前发生了变化，主要表现在 Compiler 和 Compilation 中事件监听和广播的表现形式。

webpack3:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/**
* 广播出事件
* event-name 为事件名称，注意不要和现有的事件重名
* params 为附带的参数
*/
compiler.apply('event-name', params);

/**
* 监听名称为 event-name 的事件，当 event-name 事件发生时，函数就会被执行。
* 同时函数中的 params 参数为广播事件时附带的参数。
*/
compiler.plugin('event-name', function(params) {

});

// compilation.apply 和 compilation.plugin 使用方法和上面一致。

webpack4:

html-webpack-plugin 中在 compilation.hooks 上添加了 htmlWebpackPluginBeforeHtmlGeneration 对象：

来看下 html-webpack-include-assets-plugin 的兼容写法。

参考资料

• webpack
• 手摸手，带你用合理的姿势使用 webpack 4
• 没有了CommonsChunkPlugin，咱拿什么来分包（译）
• Webpack原理-编写Plugin

在金山的最后一天了，从昨天早上就开始了划水摸鱼的工作模式，主要是把项目的代码结构给几位同事讲一下，还有一些比较容易让人困惑的点，才发现我对项目是如此熟悉，大部分代码如数家珍。

从 2017 年 2 月 14 号情人节入职到明天 2018 年 8 月 24 正式离职，差不多在这里呆了一年半的时间，自己的进步自己看得到，周围的同事也看得到。老大曾经对我说，感觉入职的时候对我的评级评低了。听到以后很开心，可能不是评低了，是我确实进步了不少。跟去年要离开 OOCL 的时候感觉不同，那个时候正好赶上过年并且自己做的项目没有东西可以做，所以非常轻松，走之前差不多很长一段时间都在摸鱼。而这次从金山离职，从提出离职申请到昨天，基本上每天都有事情要做，赶需求，改 Bug，招新人，讲代码，交接功能，一直忙个不停。可见自己的重要性提高了，所以非常谨慎地又将一些可能留下的问题改了又改，争取不给后面的同事埋坑。

为什么要走

当然是为了多赚钱啦。说什么个人提升，开阔视野，年轻就要多吃苦之类的，本质上还是为了当前或者以后多赚钱。以三分兴趣，七分为了钱去奋斗，我觉得 。当然跳槽也是有成本的，现在已经快要九月份了，跳槽相当于亏了几个月的年终奖，而且去深圳还要租房，每周往返深圳珠海还要不菲的路费，这些都是代价。粗略一算，可能未来几个月会过得更穷。再加上今年投资亏了一些，P2P 暴雷亏了一些，内推奖金没拿到，我感觉今年我就是跟钱过不去 😢。

虽然在别的厂能拿到更好的待遇，但是选择腾讯一个是离家近，一个是大厂光环。所以就算是去镀金了吧，希望以后能有更好的发展。

金山给了我很多的成长，因此内心对其还是非常感激的，唯一觉得公司有点亏待我的就是给的钱有点少，涨薪也没有谈判余地，等了很久给了我一个数字，内心当然是不满意的。因为那个时候已经有猎头联系并且开出接近 double 的待遇了，所以差不多知道涨薪后就有离开的意向了。但是当时我们组有新的产品即将上线，大家都处于加班加点的状态，个人觉得那个时候离开有些不厚道，就拖延了几个月。

面试

到五六月份开始准备，陆陆续续面了头条，阿里，腾讯。头条是一面挂，后面就没有消息了；阿里非常顺利，一到三面都过了，后来栽到 HR 面，各种原因不说了。腾讯也是一面挂，但是没过多久又有电话打来，换个部门接着面，那个时候差不多已经算是拿到阿里 offer 了，想着反正面面也不吃亏，没想到这个却成了最终的归宿。腾讯的部门是 SNG，前前后后总共面了 7 面，简直是体力劳动，每次半小时到一小时不等，聊完都是口干舌燥、面红耳赤。中间又穿插了一个阿里的部门继续面。。。终于到了 7 月 24 号，拿到了腾讯 SNG 的 offer，没怎么犹豫就接受了。收到腾讯 offer 一周多以后，又接到阿里的电话，总监面。。。（这个效率有点低啊）

今日头条是第一次面试，而且只面了一面，视频面试加在线笔试（别人看着你写代码），因为表现不好，差不多面完就知道没戏了。今日头条比较好的是，面试前有声音很好听的 hr 小妹妹打电话提前预约，预约后有邮件通知，面试挂了还有婉拒的邮件。这点比很多大厂都要友好一些。

腾讯的面试很细节，个人感觉是需要提前查漏补缺的，从 api 到设计到原理还有算法都有涉猎。面 alloyteam 的时候，面试官的问题种种都是 “你觉得 a 比 b 相比怎么样”，“使用 a 技术开发某某可能会遇到什么问题”，“某某某为什么选择这样的设计” 这样很开放性的问题，感觉自己回答的都不是很好。后面通过同事咨询面试官，得到的答复是他还在考虑，然后就没有然后了。毕竟是腾讯的明星组，想进入还是有难度的。

阿里的面试差异化比较大，没有明确的风格，每个面试官都不同，有一个面试官聊完技术以后又跟我一起聊了大半个小时中国互联网环境（估计有创业的想法），还有一个面试官从头到尾没问技术问题，一直问我目前做什么，平时怎么学习，项目中遇到了哪些问题，后面又要了我的博客。当然大部分面试官还是常规性地问一些技术问题，不过我能够明显的感受到阿里的面试氛围更加活泼一些。还有就是阿里的 HR 给了我较为不愉快的体验，这里不多说了。

具体的面试问题我觉得没有啥参考性，就不贴了。

遗憾

遗憾的事有几件，一个是之前想重构一下当前项目的打包，升级一下 webpack4 的，一直没有时间，希望后面的小伙伴能够再接再厉帮我完成心愿。一个是现在的前端负责人技术很好，感觉在他身上还有一些东西可以学习。还有一个是要离开珠海安逸的环境去深圳奋斗了，珠海真是太适合生活了，环境优雅，人人都很随和，交通也没有那么拥挤，而深圳会给人无形的压力。

腾讯

虽然最近腾讯股价大跌，但是对我们底层员工来说应该是没有影响的吧。早就知道腾讯会有比较苦逼的加班，所以内心也并不是很担心。目前在金山我也会经常性的留下来加班，有时候是做项目，有时候是留下来学习，所以对加班也没有那么排斥。对要进的部门其实也没有太多的了解，后面熟悉了以后再说吧。

最后

还是像以前一样，希望技术快快提升，money 快快来。

Symbol 简介

Symbol() 函数返回 symbol 类型的值，该类型具有静态属性和静态方法，并且不支持 new Symbol() 语法。每个从 Symbol() 函数中返回的 symbol 值都是唯一的。一个 symbol 值能作为对象属性的标识符，这是该数据类型最大的目的。

Symbol vs symbol

1. Symbol 是一个不支持 new 操作符的函数，用于创建 symbol 类型的值。
2. symbol 是一种基本数据类型。目前 JavaScript 支持的 7 种数据类型是：undefined、null、Boolean、String、Number、Object、symbol。

Symbol 使用

我们可以直接使用 Symbol() 函数创建 symbol 类型，并且用一个字符串作为其描述，每次都会创建一个新的 symbol 类型。

1
2
3
4
5
6
7
8

let a = Symbol()
typeof a // 'symbol'
Object.prototype.toString.call(a) // '[object Symbol]'
let a1 = Symbol('a')
let a2 = Symbol('a')
a1 == a2 // false
a1 === a2 // false
Symbol('foo') === Symbol('foo') // false

Symbol() 函数不能使用 new 操作符。因为 JavaScript 中 new 操作符用来创建对象，Symbol 生成的是一个原始类型的值，并不是对象。通过原始数据类型创建一个显式包装器对象的方式从 ECMAScript 6 开始不再被支持。 然而现有的原始包装器对象，如 new Boolean()、new String() 以及 new Number() 因为遗留原因仍可被创建。

1

new Symbol() // TypeError: Symbol is not a constructor at new Symbol

Symbol 可以接收字符串或者对象作为参数，如果参数是对象的话，Symbol 会调用该对象的 toString() 方法，将其转换为字符串，再生成 symbol 值。

1
2
3
4
5
6
7

let a = {
  toString () {
    return 'abc'
  }
}
let sa = Symbol(a)
sa // Symbol(abc)

Symbol 值不能与其它数据类型的值进行运算，但是 Symbol 值可以显式转换为字符串或者 Boolean，其它类型的转换都会报 TypeError 错误。

1
2
3
4
5
6
7

let a = Symbol('World')
'Hello ' + a // TypeError: Cannot convert a Symbol value to a string
`Hello ${a}` // TypeError: Cannot convert a Symbol value to a string  
a.toString() // 'Symbol(World)'
String(a) // 'Symbol(World)'
Boolean(a) // true
!a // false

每一个 Symbol 函数生成的值都不相等，因此 Symbol 可以作为标识符，当做对象属性名，这样就可以保证不会出现相同的属性名。这可以有效避免属性被覆盖。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

let a = Symbol()
// 第一种写法
let obj = {}
obj[a] = 'Hello'
// 第二种写法
let obj = {
  [a]: 'Hello'
}
// 第三种写法
let a = {}
Object.defineProperty(a, mySymbol, {value: 'Hello'})

// 以上写法都得到同样结果
a[mySymbol] // 'Hello'

注意，Symbol 值作为对象属性名时，不能用点运算符，因为点运算符后面是字符串，而 symbol 值并不是字符串。

1
2
3
4
5
6

let a = Symbol()
let obj = {}

obj.a = 'Hello!' // 此时 a 相当于一个字符串，并不是 a 值
obj[a] // undefined
obj['a'] // 'Hello!'

在对象内部使用 Symbol 的时候，必须放在方括号中。

1
2
3
4
5

let a = Symbol()
let obj = {
  [a]: function(arg){...}  
}
obj[a](123)

Symbol 属性

Symbol.length

1

Symbol.length // 0

Symbol.iterator

返回对象默认迭代器方法，使用 for...of 进行迭代。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

const iterable = {
  [Symbol.iterator]() {
    return {
      i: 0,
      next() {
        if (this.i < 3) {
          return { value: this.i++, done: false }
        }
        return { value: undefined, done: true }
      }
    }
  }
}

for (var value of iterable) {
  console.log(value)
}
// 0
// 1
// 2

Symbol.asyncIterator

返回对象默认的异步迭代器的方法，使用 for await of 进行迭代。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

const myAsyncIterator = {
  [Symbol.asyncIterator]: () => {
    const items = ['a', 'b', 'c', 'd']
    return {
      next: () => Promise.resolve({
        done: items.length === 0,
        value: items.shift()
      })
    }
  }
}
const foo = async function () {
  for await (const item of myAsyncIterator) {
    console.log(item)
  }
}
foo()

Symbol.match

指定了匹配的是正则表达式而不是字符串。String.prototype.match() 方法会调用此函数。此函数还用于标识对象是否具有正则表达式的行为。比如： String.prototype.startsWith()，String.prototype.endsWith() 和 String.prototype.includes() 这些方法会检查其第一个参数是否是正则表达式，是正则表达式就抛出一个 TypeError。现在，如果 match symbol 设置为 false（或者一个 假值），就表示该对象不打算用作正则表达式对象。

1
2
3
4
5
6

var re = /foo/
re[Symbol.match] = false
'/foo/'.startsWith(re) // true
'/baz/'.endsWith(re)   // false
// 下面代码会抛出一个 TypeError：
'/bar/'.startsWith(/bar/) // Throws TypeError, 因为 /bar/ 是一个正则表达式且 Symbol.match 没有修改。

Symbol.replace，Symbol.search、Symbol.split 使用方法都与 Symbol.match 比较类似，这里就不赘述了。

Symbol.hasInstance

用于判断某对象是否为某构造器的实例，因此你可以用它自定义 instanceof 操作符在某个类上的行为。

1
2
3
4
5
6

class MyArray {
  static [Symbol.hasInstance](instance) {
    return Array.isArray(instance)
  }
}
console.log([] instanceof MyArray) // true

Symbol.isConcatSpreadable

用于配置某对象作为 Array.prototype.concat() 方法的参数时是否展开其数组元素。

对于数组对象，默认情况下，用于 concat 时，会按数组元素展开然后进行连接（数组元素作为新数组的元素）。

1
2
3
4

var arr1 = ['a', 'b', 'c']
var arr2 = numeric = [1, 2, 3]
var arr3 = arr1.concat(arr2)
console.log(arr3) // 结果: ['a', 'b', 'c', 1, 2, 3]

重置 Symbol.isConcatSpreadable 可以改变默认行为。

1
2
3
4
5

var arr1 = ['a', 'b', 'c']
var arr2 = numeric = [1, 2, 3]
arr2[Symbol.isConcatSpreadable] = false 
var arr3 = arr1.concat(arr2)
console.log(arr3) // 结果: ['a', 'b', 'c', 1, 2, 3]

对于类似数组的对象，默认是不展开的，如果期望使用 concat 时，展开其元素用于连接，重置 Symbol.isConcatSpreadable 为 true。

1
2
3
4
5
6
7
8
9
10

var arr1 = [1, 2, 3]

var obj = {
  [Symbol.isConcatSpreadable]: true, 
  length: 2, 
  0: 'hello', 
  1: 'world' 
}

arr1.concat(obj) // [1, 2, 3, 'hello', 'world']

Symbol.unscopables

Symbol.species

Symbol.toPrimitive

Symbol.toStringTag

Symbol 方法

Symbol.for(key)

使用给定的 key 搜索现有的 symbol，如果找到则返回该 symbol。否则将使用给定的 key 在全局 symbol 注册表中创建一个新的 symbol。

1
2
3
4
5
6
7
8
9

Symbol.for('foo') // 创建一个 symbol 并放入 symbol 注册表中，键为 'foo'
Symbol.for('foo') // 从 symbol 注册表中读取键为'foo'的 symbol


Symbol.for('bar') === Symbol.for('bar') // true
Symbol('bar') === Symbol('bar') // false，Symbol() 函数每次都会返回新的一个 symbol

var sym = Symbol.for('mario')
sym.toString() // 'Symbol(mario)'，mario 既是该 symbol 在 symbol 注册表中的键名，又是该 symbol 自身的描述字符串

Symbol.keyFor(sym)

用来获取 symbol 注册表中与某个 symbol 关联的键。

1
2
3
4
5
6
7
8
9
10

// 创建一个 symbol 并放入 Symbol 注册表，key 为 'foo'
var globalSym = Symbol.for('foo') 
Symbol.keyFor(globalSym) // 'foo'

// 创建一个 symbol，但不放入 symbol 注册表中
var localSym = Symbol()
Symbol.keyFor(localSym) // undefined，所以是找不到 key 的

// Symbol 默认属性并不在 symbol 注册表中
Symbol.keyFor(Symbol.iterator) // undefined

参考资料

• MDN-Symbol
• Symbol

Transfer-Encoding (传输编码) 是常见的 HTTP 头 字段，表示将实体安全传递给用户所采用的编码形式。与另外一个更为常见的 Content-Encoding 不同，Content-Encoding 表示内容编码，通常用于对实体内容进行压缩编码，比如 gzip，deflate 等。而 Transfer-Encoding 不会减少实体内容传输大小，但是会改变实体传输的形式。Content-Encoding 和 Transfer-Encoding 二者是相辅相成的，对于一个 HTTP 报文，很可能同时进行了内容编码和传输编码。

在 HTTP 请求头中，Transfer-Encoding 被称为 TE，表示浏览器预期接受的传输编码方式，可使用 Response 头 Transfer-Encoding 字段中的值，比如 chunked；另外还可用 trailers 这个值来表明浏览器希望在最后一个大小为 0 的块之后还接收到一些额外的字段。

HTTP 长连接

HTTP/1.0 后期引入长连接的概念，通过 Connection: keep-alive 实现，服务端和客户端通过这个头部告诉对方发送完数据后不需要断开 TCP 连接，后面可以继续使用。HTTP/1.1 则将其变为默认规则，只要不发送 Connection: close，所有的连接均保持为长连接。

长连接存在的问题

持久链接需要服务器在开始发送消息体前发送 Content-Length 消息头字段，但是对于动态生成的内容来说，在内容创建完之前是不可知的。在 HTTP 协议中的 Transfer-Encoding 这篇文章中，作者举了两个例子来阐述长连接存在的问题。使用 node 创建 server。

1
2
3
4
5
6
7
8

require('net').createServer(function(sock) {
  sock.on('data', function(data) {
    sock.write('HTTP/1.1 200 OK\r\n')
    sock.write('\r\n')
    sock.write('hello world!')
    sock.destroy()
  })
}).listen(8080, '127.0.0.1')

使用 sock.destroy() ，则每次发送完请求后，就关闭 TCP 连接，假如去掉 sock.destroy()，服务变成长连接，但是请求的状态一直在 pending，因此浏览器无法确认数据是否传输完成，只能一直等待。通过设置 Content-Length 来解决这个问题。

1
2
3
4
5
6
7
8

require('net').createServer(function(sock) {
  sock.on('data', function(data) {
    sock.write('HTTP/1.1 200 OK\r\n')
    sock.write('Content-Length: 12\r\n')
    sock.write('\r\n')
    sock.write('hello world!')
  })
}).listen(8080, '127.0.0.1')

这样浏览器能正常接收响应数据，通过 Content-Length 判断实体已经结束，但是如果 Content-Length 计算错误会导致数据异常，并且对于动态生成的内容来说，在内容创建完之前其长度是不可知的。

Transfer-Encoding: chunked (分块传输编码)

Transfer-Encoding 的出现正是为了解决这个问题。如果一个 HTTP 消息（请求消息或应答消息）的 Transfer-Encoding 消息头的值为 chunked，那么，消息体由数量未定的块组成，并以最后一个大小为 0 的块为结束。分块传输编码只在 HTTP/1.1 中提供。

使用方式也很简单，在响应头部加上 Transfer-Encoding: chunked 后，就表示这个报文采用分块编码。每一个非空的块都以该块包含数据的字节数（字节数以十六进制表示）开始，跟随一个 CRLF （回车及换行），然后是数据本身，最后以一个大小为 0 的块 + CRLF 结束。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

require('net').createServer(function(sock) {
  sock.on('data', function(data) {
    sock.write('HTTP/1.1 200 OK\r\n')
    sock.write('Transfer-Encoding: chunked\r\n')
    sock.write('\r\n')

    sock.write('24\r\n') // (36 字符 => 十六进制: 0x24)
    sock.write('This is the data in the first chunk \r\n')

    sock.write('1b\r\n') // (27 字符 => 十六进制: 0x1b)
    sock.write('and this is the second one \r\n')

    sock.write('3\r\n') // (3 字符 => 十六进制: 0x03)
    sock.write('con\r\n')

    sock.write('8\r\n') // (8 字符 => 十六进制: 0x08)
    sock.write('sequence\r\n')

    sock.write('0\r\n') // 块大小为 0 表示数据传输结束
    sock.write('\r\n')  // 消息最后以 CRLF 结尾
  })
}).listen(8080, '127.0.0.1')

用浏览器访问 http://localhost:8080/ 可以看到 “This is the data in the first chunk and this is the second one consequence”。

Transfer-Encoding 其它定义方法

1. Transfer-Encoding: chunked：数据以一系列分块的形式进行发送。 Content-Length 首部在这种情况下不被发送。
2. Transfer-Encoding: compress：采用 Lempel-Ziv-Welch (LZW) 压缩算法，这种内容编码方式已经被大部分浏览器弃用。
3. Transfer-Encoding: deflate：采用 zlib 结构 (在 RFC 1950 中规定)，和 deflate 压缩算法(在 RFC 1951 中规定)。
4. Transfer-Encoding: gzip：表示采用 Lempel-Ziv coding (LZ77) 压缩算法，以及 32 位 CRC 校验的编码方式。这个编码方式最初由 UNIX 平台上的 gzip 程序采用。
5. Transfer-Encoding: identity：用于指代自身（例如：未经过压缩和修改）。除非特别指明，这个标记始终可以被接受。

参考资料

• 分块传输编码
• HTTP 协议中的 Transfer-Encoding
• Transfer-Encoding

301 Moved Permanently，永久重定向。被请求资源已永久移动到新位置，并且将来任何对该资源的引用都使用本响应返回的若干个 URI 之一。301 资源除非额外指定，否则都是可缓存的。

注意：对于某些使用 HTTP/1.0 协议的浏览器，当它们发送的 POST 请求得到了一个 301 响应的话，接下来的重定向请求将会变成 GET 方式。

302 Found 表示临时重定向 Moved Temporarily。由于这样的重定向是临时的，客户端应继续向原有地址发送以后的请求，只有在 Cache-Control 或 Expires 中进行了指定的情况下，这个响应才是可缓存的。

注意：虽然 RFC1945 和 RFC 2068 规范不允许客户端在重定向时改变请求的方法，但是很多现存的浏览器将 302 响应视作为 303 响应，并且使用 GET 方式访问在 Location 中规定的 URI，而无视原先请求的方法。因此状态码 303 和 307 被添加了进来，用以明确服务器期待客户端进行何种反应。

301 和 302 相同点

1. 都表示资源重定向。
2. 新的 URI 地址都是在响应的 Location 中返回。
3. 如果原始请求不是 GET 或者 HEAD 请求的话，浏览器会禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。

301 Moved Permanently

来看一个常见的 301 状态码的演示。访问本网页的时候，由于使用 https 协议，并且设置 http 自动重定向到 https，所以假如直接使用 http 协议http://lz5z.com进行访问，会有一次 301 重定向。

浏览器获得响应结果后，根据 Location 中的值进行重定向，打开页面 https://lz5z.com。

302 Found

我们常用的短链接就是 302 跳转，比如我使用 sina 的短链接服务生成本页面的地址: http://t.cn/RdC6GHq。对其进行访问的时候就首先发生了 302 重定向。

使用时机

由于 301 重定向是永久的重定向，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址。302 重定向是临时的重定向，搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回 302 代码，搜索引擎认为新的网址只是暂时的。

所以 301 是对搜索引擎更加友好的重定向，建议只要不是资源临时转移，都可以使用 301 的方式。

参考资源

• HTTP状态码#3xx重定向

关于 ES7/8/9 全部特性可以查看 tc39 官方的 proposals，这些都是最后进入 stage 4 的特性。

ES9 的新特性：

1. Lifting template literal restriction 模板语法修正
2. s (dotAll) flag for regular expressions (正则表达式 dotAll 模式)
3. RegExp named capture groups (正则表达式命名捕获组)
4. Rest/Spread Properties (Rest/Spread 属性)
5. RegExp Lookbehind Assertions (正则表达式反向(lookbehind)断言)
6. RegExp Unicode Property Escapes (正则表达式 Unicode 转义)
7. Promise.prototype.finally
8. Asynchronous Iteration (异步迭代器)

正则表达式 dotAll 模式

dotAll 是一个新的正则表达式修饰符，目前 JS 拥有的修饰符有：

• g -> global
• i -> ingoreCase
• m -> multiline
• y -> sticky
• u -> unicode
• s -> dotAll

正则表达式中的 . 用来匹配任何单个字符，但是有 2 个除外：多字节 emoji 字符和行终结符。

1
2

let regex = /^.$/
regex.test('😀')   // false

通过设置 u 表示 unicode

1
2

let regex = /^.$/u
regex.test('😀')   // true

行终止符包括

• U+000A LINE FEED (LF) (\n) - 换行
• U+000D CARRIAGE RETURN (CR) (\r) - 回车
• U+2028 LINE SEPARATOR - 行分隔符
• U+2029 PARAGRAPH SEPARATOR - 段分隔符

还有一些其它字符，也可以作为一行的开始：

• U+000B VERTICAL TAB (\v)
• U+000C FORM FEED (\f)
• U+0085 NEXT LINE

目前 . 只能匹配其中的一部分：

1
2
3
4
5
6
7
8
9
10

let regex = /./

regex.test('\n')       // false
regex.test('\r')       // false
regex.test('\u{2028}') // false
regex.test('\u{2029}') // false

regex.test('\v')       // true
regex.test('\f')       // true
regex.test('\u{0085}') // true

标记 s 表示 dotAll，用来改变 . 不能匹配行终止符的行为:

1
2

/hello.world/.test('hello\nworld')  // false
/hello.world/s.test('hello\nworld') // true

或者用 \s 来匹配空白符：

1
2

/hello.world/.test('hello\nworld')  // false
/hello[\s]world/s.test('hello\nworld') // true

dotAll 表示 . 可以匹配任意字符：

1
2
3
4
5

const re = /hello.world/s  // 等价于 const re = new RegExp('hello.world', 's')

re.test('hello\nworld') // true
re.dotAll // true
re.flags // 's'

正则表达式命名捕获组

捕获组就是把正则表达式中匹配到的内容，保存到内存中以数字编号或者显式命名的数组里，方便后面使用。这种引用既可以在正则表达式内部，也可以是在正则表达式外部。

捕获组有两种形式，一种是普通捕获组，另一种是命名捕获组。

1
2
3
4
5
6

const regex = /(\d{4})-(\d{2})-(\d{2})/
const matchers = regex.exec('2018-07-02')
matchers[0]    // 2018-07-02
matchers[1]    // 2018
matchers[2]    // 07
matchers[3]    // 02

使用数字捕获组的一个缺点是对于引用不太直观，以上面的例子，我们很难分清楚哪个组代表的是年，哪个组代表的是月。而命名捕获组就是为了解决这个问题。

命名捕获组

ES2018 允许命名捕获组可以使用 (?<name>...) 语法给每个组起一个名字。

1
2
3
4
5

const regex = /(?<year>[0-9]{4})-(?<month>[0-9]{2})-(?<day>[0-9]{2})/
const match = regex.exec('2018-07-02')
console.log(match.groups.day) // '02'
console.log(match.groups.month) // '07'
console.log(match.groups.year) // '2018'

名字唯一

每个捕获组的名字必须唯一，否则会抛出异常。

1
2

const regex = /(?<foo>\d)-(?<foo>\d)/
// Uncaught SyntaxError: Invalid regular expression: /(?<foo>\d)-(?<foo>\d)/: Duplicate capture group name

匹配失败

任何匹配失败的命名组都将返回 undefined。

1
2
3
4
5

let re = /^(?<optional>\d+)?$/
const matchers = re.exec('')

matchers[0] === ''
matchers.groups.optional === undefined

使用解构赋值

1
2
3

let re = /^(?<one>.*):(?<two>.*)$/
let {groups: {one, two}} = re.exec('foo:bar')
console.log(`one: ${one}, two: ${two}`)  // 输出 one: foo, two: bar

使用 replace

1
2
3

const reDate = /(?<year>[0-9]{4})-(?<month>[0-9]{2})-(?<day>[0-9]{2})/
const d = '2018-07-02'
console.log(d.replace(reDate, '$<month>-$<day>-$<year>')) // 07-02-2018

String.prototype.replace 第 2 个参数可以接受一个函数。这时 命名捕获组的引用会作为 groups 参数传递进去:

1
2
3
4
5
6
7
8

let re = /(?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2})/

let result = '2018-07-02'.replace(re, (...args) => {
  let {day, month, year} = args[args.length - 1]
  return `${day}-${month}-${year}`
})

result === '02/07/2018' // true

反向引用

当需要在正则表达式里面引用命名捕获组时，使用 \k<name> 语法。

1
2
3

let duplicate = /^(?<half>.*).\k<half>$/
duplicate.test('a*b') // false
duplicate.test('a*a') // true

向下兼容

/(?<name>)/ 和 /\k<foo>/ 只有在命名捕获组中才有意义。如果正则表达式没有命名捕获组，那么 /\k<foo>/ 仅仅是字符串字面量 “k” 而已。

1

/\k<foo>/.test('k<foo>')   // true

正则表达式反向(lookbehind)断言

断言 (Assertion) 是一个对当前匹配位置之前或之后的字符的测试，它不会实际消耗任何字符，所以断言也被称为“非消耗性匹配”或“非获取匹配”。

正则表达式的断言一共有 4 种形式：

• (?=pattern) 零宽正向肯定断言(zero-width positive lookahead assertion)
• (?!pattern) 零宽正向否定断言(zero-width negative lookahead assertion)
• (?<=pattern) 零宽反向肯定断言(zero-width positive lookbehind assertion)
• (?<!pattern) 零宽反向否定断言(zero-width negative lookbehind assertion)

正向断言(lookahead)

当前位置后面的字符串应该满足断言，但是并不捕获，在当前的 JavaScript 正则表达式只支持正向断言。

1
2
3
4
5
6

const regex = /li(?=zhen)/
const match1 = regex.exec('lizhen')
console.log(match1[0]) // li
// 如果字符串没有zhen，则无法匹配
const match2 = regex.exec('liming')
console.log(match2) // null

正向否定断言正好相反

1
2
3
4
5
6
7

const regex = /li(?!zhen)/

const match1 = regex.exec('lizhen')
console.log(match1)    // null

const match2 = regex.exec('liming')
console.log(match2[0]) // li

反向断言(lookbehind)

反向断言和正向断言的行为一样，只是方向相反。反向肯定断言使用语法 (?<=...)。

比如我们想获取所有的人民币金额，但是不获取其它货币（比如美元）：

1
2
3

const regex = /(?<=\D)\d+(\.\d*)?/
const match = regex.exec('$123.89')
console.log(match[0]) // 123.89

正则表达式 Unicode 转义

Unicode 标准为每个符号分配各种属性和属性值，比如希腊字母 π 在 Unicode 中有独特的属性和属性值。目前版本的 ECMAScript 中正则表达式是无法匹配这些 Unicode 的，通常开发人员有两种选择。

(1) 在运行时使用类似于 xregexp 这样的库创建增强的正则表达式：

1
2

const regexGreekSymbol = XRegExp('\\p{Greek}', 'A')
regexGreekSymbol.test('π') // true

缺点是 xregexp 是一个运行时依赖，对性能要求较高的 web 应用来说不是很理想。而且其压缩文件 xregexp-all-min.js.gz 也有 35k，并且每当 Unicode 标准更新时，必须要更新 xregexp 才能使用新数据。

(2) 在编译时的时候使用 regenerate 生成正则表达式。

1
2
3
4
5
6

const regenerate = require('regenerate')
const codePoints = require('unicode-9.0.0/Script/Greek/code-points.js')
const set = regenerate(codePoints)
set.toString()
// → '[\u0370-\u0373\u0375-\u0377\u037A-\u037D\u037F\u0384\u0386\u0388-\u038A\u038C\u038E-\u03A1\u03A3-\u03E1\u03F0-\u03FF\u1D26-\u1D2A\u1D5D-\u1D61\u1D66-\u1D6A\u1DBF\u1F00-\u1F15\u1F18-\u1F1D\u1F20-\u1F45\u1F48-\u1F4D\u1F50-\u1F57\u1F59\u1F5B\u1F5D\u1F5F-\u1F7D\u1F80-\u1FB4\u1FB6-\u1FC4\u1FC6-\u1FD3\u1FD6-\u1FDB\u1FDD-\u1FEF\u1FF2-\u1FF4\u1FF6-\u1FFE\u2126\uAB65]|\uD800[\uDD40-\uDD8E\uDDA0]|\uD834[\uDE00-\uDE45]'
// Imagine there’s more code here to save this pattern to a file.

虽然这种方法所生成的正则表达式相当大，但是能够得到最佳的运行时性能。最大的缺点是它需要一个构建脚本，每当 Unicode 标准更新时，必须更新生成脚本。

解决方案

ES2018 中使用 \p{…} 和 \P{…} 进行 Unicode 的属性转义，在正则表达式中使用 u 进行标记。在 \p{…} 内，可以以键值对的方式设置需要匹配的属性，而非具体内容。比如要匹配希腊字母 π：

1
2

const reGreekSymbol = /\p{Script=Greek}/u
reGreekSymbol.test('π') // true

解决了以下几个问题：

1. 不用为创建 Unicode-aware 正则表达式担心。
2. 不需要运行时依赖。
3. 正则表达式不需要使用 Unicode 区间来判断特点的内容。
4. 不需要生成正则表达式脚本。
5. Unicode 属性转义自动保持最新，每当 Unicode 标准更新时，ECMAScript 引擎更新其数据即可。

Rest/Spread 属性

ECMAScript 6 中增加了数组的 Rest 解构赋值和 Spread 语法，比如：

1
2
3
4
5

var a, b, rest
[a, b, ...rest] = [10, 20, 30, 40, 50]
console.log(a) // 10
console.log(b) // 20
console.log(rest) // [30, 40, 50]

1
2
3
4
5
6

function sum(x, y, z) {
  return x + y + z
}
const numbers = [1, 2, 3]
sum(...numbers) // 6
sum.apply(null, numbers) // 6

ES2018 中增加了对象的 Rest 属性和 Spread 语法。

Rest 属性

1
2
3
4

let {x, y, ...z} = {x:1, y:2, a:3, b:4}
x // 1
y // 2
z // {a:3, b: 4}

Spread 语法

1
2

let n = {x, y, ...z}
n // {x:1, y:2, a:3, b:4}

Promise.prototype.finally

Promise.prototype.finally 早就有很多实现，以至于我一直都认为它是原生对象的原型属性。常见的实现有：

1. Bluebird#finally
2. Q#finally
3. when#finally
4. jQuery jqXHR#always

1
2
3

Promise.resolve(2).finally(() => {}) // will be resolved with 2

Promise.reject(3).finally(() => {}) // will be rejected with 3

Asynchronous Iteration

关于 JavaScript 的异步循环，我在之前的文章JavaScript 循环与异步有过探索。如今 ECMAScript 中有了对异步迭代的原生支持。

迭代器 Iterator

ES6 中引入迭代器来遍历数组，JavaScript 中的迭代器是一个对象，提供 next() 方法，用来返回序列中的下一项，这个方法包含两个属性：done 和 value。

迭代器对象一旦被创建，就可以反复调用 next()。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

function makeIterator (array) {
  var nextIndex = 0
  return {
    next: function () {
      return nextIndex < array.length ?
        {value: array[nextIndex++], done: false} :
        {done: true}
    }
  }
}
// 初始化后 next() 方法可以用来依次访问对象中的键值
var it = makeIterator(['a', 'b'])
console.log(it.next().value) // 'a'
console.log(it.next().value) // 'b'
console.log(it.next().done)  // true

可迭代对象

常见的可迭代对象有：Array、String、TypedArray、Map、Set。这些对象都内置可迭代的对象，在其原型中有一个 Symbol.iterator 方法。

我们也可以定义可迭代对象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

var myIterable = {}
myIterable[Symbol.iterator] = function* () {
  yield 1
  yield 2
  yield 3
}

for (let value of myIterable) { 
  console.log(value)
}
// 1
// 2
// 3

var [a, b, c] = [...myIterable] // [1, 2, 3]
// a ===1; b === 2; c === 3
Array.from(myIterable) // [1, 2, 3]

当我们定义了可迭代对象后，就可以在 Array.from、for...of 中使用这个对象。

异步迭代器

一个异步迭代器就像一个迭代器，除了它的 next() 方法返回一个 { value, done } 的 promise。如上所述，我们必须返回迭代器结果的 promise，因为在迭代器方法返回时，迭代器的下一个值和 done 状态可能未知。

1
2
3
4
5
6
7
8
9
10
11

const myAsyncIterator = {
  [Symbol.asyncIterator]: () => {
  const items = ['a', 'b', 'c', 'd']
  return {
    next: () => Promise.resolve({
        done: items.length === 0,
        value: items.shift()
    })
  }
  }
}

对于异步迭代器，使用 for await of 进行迭代。

1
2
3
4
5

(async function () {
  for await (const item of myAsyncIterator) {
    console.log(item)
  }
})()

异步生成器函数

异步生成器函数与生成器函数类似，但有以下区别：

1. 当被调用时，异步生成器函数返回一个对象：async generator，该对象有 3 个方法（next，throw，和 return），每个方法都返回一个 Promise，Promise 返回 { value, done }。而普通生成器函数并不返回 Promise，而是直接返回 { value, done }。这会自动使返回的异步生成器对象具有异步迭代的功能。
2. 允许使用 await 表达式和 for-await-of 语句。
3. 修改了 yield* 的行为以支持异步迭代。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

async function* myAsyncGenerator() {
  let t = 0
  const test = function() {
    return new Promise((resolve, reject) => {
      setTimeout(() => {
        resolve(+new Date())
      }, 1000)
    })
  }
  try {
    while (t++ < 10) {
      yield await test()
    }
  } finally {
    console.log('finally')
  }
}

async function main() {
  for await (const item of myAsyncGenerator()) {
    console.log(item)
  }
}
main()