总览

一、借助构造函数

function Parent1() {
  this.name = 'parent1'
}
function Child1() {
  // 将父类的执行上下文指向子类，父类执行时的实例属性都会指向子类
  Parent1.call(this);// apply
  this.type = 'child1'
}

缺点

子类没有继承父类的原型方法
只继承了父类构造函数中的属性和方法

Parent1.prototype.method = (arg) => console.log(arg);
console.log(new Child1().method); // undefined

二、借助原型链

function Parent2() {
  this.name = 'parent2';
  this.arr = [1, 2, 3];
  this.method = (arg) => console.log(arg)
}
function Child2() {
  this.type = 'child2'
}
Child2.prototype = new Parent2();

原型图如下

缺点

引用类型的属性被所有实例共享，实例之间会互相影响

let c21 = new Child2();
let c22 = new Child2();

c21.arr.push(4);
console.log(c21.arr, c22.arr);
// 注意，下面是直接给实例添加method属性
// 只是修改了method指针，没有修改原型链上的method方法
// 只有修改引用对象才是真正的修改
c21.method = 'c21';
console.log(Parent2);
console.log(c21, c22);

三、组合（构造+原型链）

function Parent3() {
  this.name = 'parent3';
  this.arr = [1, 2, 3]
}
function Child3() {
  Parent3.call(this);
  this.type = 'child3'
}
Child3.prototype = new Parent3();

优点

每个实例不会再互相影响

缺点

实例化时，父类被构造了两次，这没有必要
call一次，new一次

四、组合优化一

function Parent4() {
  this.name = 'parent4';
  this.arr = [1, 2, 3]
}
function Child4() {
  Parent4.call(this);
  this.type = 'child4'
}
Child4.prototype = Parent4.prototype;

缺点

无法判断实例的构造函数是父类还是子类

let c41 = new Child4();
let c42 = new Child4();
console.log(c41 instanceof Child4, c41 instanceof Parent4);
// true true

但其实，构造函数就是父类本身

console.log(c41.constructor); // Parent4

很难得才通过Parent4.call(this)改变了构造函数的指向，现在又改回去了？天……不想看下去了行不行，兄dei，坚持一会就是胜利，别打瞌睡

Child4.prototype = Parent4.prototype只是把Child4的prototype属性指针指向了Parent4.prototype这个引用对象而已，实际上Parent4.prototype.constructor = Parent4，这里说的有点绕，可以结合图好好理解一下

五、组合优化二

Object.create请先移步
Object.create() - JavaScript | MDN

function Parent5() {
  this.name = 'parent5';
  this.arr = [1, 2, 3]
}
function Child5() {
  Parent5.call(this);
  this.type = 'child5'
}
// 组成原型链
Child5.prototype = Object.create(Parent5.prototype);

但是，这时候，实例对象的constructor依然是Parent5

所以需要重新指定实例对象的构造器

Child5.prototype.constructor = Child5;

Good !

等下，还是验证一下吧

let c51 = new Child5();
let c52 = new Parent5();
console.log(c51 instanceof Child5, c51 instanceof Parent5);
console.log(c52 instanceof Child5, c52 instanceof Parent5);
console.log(c51.constructor, c52.constructor);
// true true
// false true
// Child5 Parent5

So perfect !

后记

感谢您耐心看到这里，希望有所收获！

如果不是很忙的话，麻烦点个star⭐【Github博客传送门】，举手之劳，却是对作者莫大的鼓励。

我在学习过程中喜欢做记录，分享的是自己在前端之路上的一些积累和思考，希望能跟大家一起交流与进步，更多文章请看【amandakelake的Github博客】

参考
继承与原型链 - JavaScript | MDN
JavaScript inheritance by example by Dr.Axel
Vjeux » Javascript – How Prototypal Inheritance really works
How To Work with Prototypes and Inheritance in JavaScript | DigitalOcean

本次分析的源码采用的是16.2.0的版本
目前网上现有的react源码分析文章基于的都是版本16以前的源码，入口和核心构造器不一样了，如下图所示

本想借鉴前人的源码分析成果，奈何完全对不上号，只好自己慢慢摸索

水平有限，如果有错误和疏忽的地方，还请指正。

最快捷开始分析源码的办法

mkdir [email protected]
cd [email protected]
npm init -y
npm i react --save

然后打开项目，进入node_nodules => react
先看入口文件index.js

'use strict';

if (process.env.NODE_ENV === 'production') {
  module.exports = require('./cjs/react.production.min.js');
} else {
  module.exports = require('./cjs/react.development.js');
}

我们就看开发环境下的版本吧，压缩版本是打包到生产环境用的

打开图中文件即可

核心接口

分析源码先找对外的暴露接口，当然就是react了，直接拉到最下面

var React = {
  Children: {
    map: mapChildren,
    forEach: forEachChildren,
    count: countChildren,
    toArray: toArray,
    only: onlyChild
  },

  Component: Component,
  PureComponent: PureComponent,
  unstable_AsyncComponent: AsyncComponent,

  Fragment: REACT_FRAGMENT_TYPE,

  createElement: createElementWithValidation,
  cloneElement: cloneElementWithValidation,
  createFactory: createFactoryWithValidation,
  isValidElement: isValidElement,

  version: ReactVersion,

  __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED: {
    ReactCurrentOwner: ReactCurrentOwner,
    // Used by renderers to avoid bundling object-assign twice in UMD bundles:
    assign: _assign
  }
};

ReactChildren

ReactChildren提供了处理 this.props.children 的工具集，跟旧版本的一样

Children: {
    map: mapChildren,
    forEach: forEachChildren,
    count: countChildren,
    toArray: toArray,
    only: onlyChild
  },

组件

旧版本只有ReactComponent一种
新版本定义了三种不同类型的组件基类Component，PureComponent ，unstable_AsyncComponent

Component: Component,
PureComponent: PureComponent,
unstable_AsyncComponent: AsyncComponent,

等下再具体看都是什么

生成组件

createElement: createElementWithValidation,
cloneElement: cloneElementWithValidation,
createFactory: createFactoryWithValidation,

判断组件：isValidElement

校验是否是合法元素，只需要校验类型，重点是判断.$$typeof属性

function isValidElement(object) {
  return typeof object === 'object' && object !== null && object.$$typeof === REACT_ELEMENT_TYPE;
}

_assign

其实是object-assign，但文中有关键地方用到它，下文会讲
var _assign = require('object-assign');

React组件的本质

组件本质是对象

不急着看代码，先通过例子看看组件是什么样子的
用creact-react-app生成一个最简单的react项目
在App.js文件加点东西，然后打印组件A看一下是什么

npm start启动项目看看

其实就是个对象，有很多属性，注意到props里面， 没有内容
给组件A里面包含一点内容

componentDidMount() {
    console.log('组件A',<A><span>加点内容看看</span></A>)
  }

可以看到，props.children里面开始嵌套内容了
那以我们聪明的程序员的逻辑来推理一下，其实不断的页面嵌套，就是不断的给这个对象嵌套props而已
不信再看一下

componentDidMount() {
    console.log('组件A',<A><span>加点内容看看<a>不信再加多一点</a></span></A>)
  }

虚拟DOM概念

所以到目前为止，我们知道了react的组件只是对象，而我们都知道真正的页面是由一个一个的DOM节点组成的，在比较原生的jQuery年代，通过JS来操纵DOM元素，而且都是真实的DOM元素，而且我们都知道复杂或频繁的DOM操作通常是性能瓶颈产生的原因
所以React引入了虚拟DOM（Virtual DOM）的概念
React虚拟DOM浅析 | AlloyTeam
总的说起来，无论多复杂的操作，都只是先进行虚拟DOM的JS计算，把这个组件对象计算好了以后，再一次性的通过Diff算法进行渲染或者更新，而不是每次都要直接操作真实的DOM。
在即时编译的时代，调用DOM的开销是很大的。而Virtual DOM的执行完全都在Javascript 引擎中，完全不会有这个开销。

知道了什么是虚拟DOM以及组件的本质后，我们还是来看一下代码吧
先从生成组件开始切入，因为要生成组件就肯定会去找组件是什么
createElement: createElementWithValidation,

组件的本源

知道了组件是对象后，我们去看看它的本源

摘取一些核心概念出来看就好

function createElementWithValidation(type, props, children) {
  var element = createElement.apply(this, arguments);
  return element;
}

可以看到，返回了一个element ，这个元素又是由createElement方法生成的，顺着往下找

function createElement(type, config, children) {
  var props = {};
  var key = null;
  var ref = null;
  var self = null;
  var source = null;

  return ReactElement(type, key, ref, self, source, ReactCurrentOwner.current, props);
}

返回的是ReactElement方法，感觉已经很近了，马上要触及本源了

var ReactElement = function (type, key, ref, self, source, owner, props) {
  var element = {
    $$typeof: REACT_ELEMENT_TYPE,
    type: type,
    key: key,
    ref: ref,
    props: props,
    _owner: owner
  };
  return element;
};

bingo，返回了一个对象，再看这个对象，是不是跟上面打印出来的对象格式很像？再看一眼

这就是组件的本源

组件三种基类

前面说了，版本16以后，封装了三种组件基类：分别是组件、纯组件、异步组件

Component: Component,
PureComponent: PureComponent,
unstable_AsyncComponent: AsyncComponent,

一个个去看一下区别在哪里，先看** Component**

function Component(props, context, updater) {
  this.props = props;
  this.context = context;
  this.refs = emptyObject;
  this.updater = updater || ReactNoopUpdateQueue;
}

很简单，一个构造函数，通过它构造的实例对象有三个私有属性，refs 则是个emptyObject，看名字就知道是空对象
这个emptyObject也是引入的插件
var emptyObject = require('fbjs/lib/emptyObject');

再去看PureComponent，AsyncComponent，定义的时候居然跟Component 是一样的

都是这四句话

this.props = props;
  this.context = context;
  this.refs = emptyObject;
  this.updater = updater || ReactNoopUpdateQueue;

区别呢？这里就要比较理解原型链方面的知识了
虽然原型和继承在日常项目和工作中用的不多，那是因为我们在面向过程编程，但想要进阶，就要去读别人的源码，去自己封装组件，这事它们就派上用场了，这就是为什么它们很重要的原因。

核心的方法，和属性，以及这三种组件直接的关系都是通过原型的知识联系起来的，关键代码如下，我画了个简图，希望能对看文章的各位有所帮助，如果有画错的，希望能指正我

先上核心代码
setState和forceUpdate这两个方法挂载Component（组件构造器）的原型上

Component.prototype.setState = function (partialState, callback) {
  ...
};

Component.prototype.forceUpdate = function (callback) {
  ...
};

定义一个ComponentDummy，其实也是一个构造器，按照名字来理解就是“假组件”😂，它是当做辅助用的

让ComponentDummy的原型指向Component的原型，这样它也能访问原型上面的共有方法和属性了，比如setState和forceUpdate

function ComponentDummy() {}
ComponentDummy.prototype = Component.prototype;

这句话，假组件构造器ComponentDummy实例化出来一个对象pureComponentPrototype，然后把这个对象的constructor属性又指向了PureComponent，因此PureComponent也成为了一个构造器，也就是上面的第二种组件基类

var pureComponentPrototype = PureComponent.prototype = new ComponentDummy();
pureComponentPrototype.constructor = PureComponent;

AsyncComponent基类也是一样

var asyncComponentPrototype = AsyncComponent.prototype = new ComponentDummy();
asyncComponentPrototype.constructor = AsyncComponent;

但是AsyncComponent的原型多了一个方法render，看到了吗，妈妈呀，这就是render的出处

asyncComponentPrototype.render = function () {
  return this.props.children;
};

所以到目前为止，可以得出一个原型图

但是，有个问题来了，render方法挂载在AsyncComponent的原型上，那通过Component构造器构造出来的实例岂不是读不到render方法，那为什么日常组件是这样写的？

还有两句代码，上面做了个小剧透的_assign

// Avoid an extra prototype jump for these methods.
_assign(pureComponentPrototype, Component.prototype);

// Avoid an extra prototype jump for these methods.
_assign(asyncComponentPrototype, Component.prototype);

每句话上面还特意有个注释，Avoid an extra prototype jump for these methods.，避免这些方法额外的原型跳转，先不管它，先看_assign做了什么，
把Component的原型跟AsyncComponent的原型合并，
那么这里答案就呼之欲出了，如此一来，AsyncComponent上面的render方法，不就相当于挂载到Component上面了吗？

以此类推，三种基类构造器最后都是基于同一个原型，共享所以方法，包括render、setState、forceUpdate等等，最后的原型图应该就变成了这样

到这里，有个问题要思考的是？
既然最后三个基类共用同一个原型，那为什么要分开来写？
中间还通过一个假组件构造器ComponentDummy来辅助构建两个实例

源码还没读完，这个地方我目前还没弄明白，应该是后面三个基类又分别挂载了不一样的方法，希望有大佬能提前回答一下

看了很多关于cookie与session的理论文章，项目中日常也经常用，但自己是前端er，对后端一直抱有好奇心，这次就拿cookie开到，跑一个全流程吧，也顺便作为巩固cookie知识的一个实践

COOKIE和SESSION有什么区别？ - 知乎

搭建服务器，初始化

通过node，我们可以很轻易的搭建出一个本地服务器，也为我们做各种项目试验带来了方便，再次推崇一发node大法

mkdir cookie-dome
cd cookie-dome
npm init
npm i express --save
touch main.js

这里使用了express框架快速搭建服务器，在新建的main.js文件输入以下代码
express中文官网

const experss = require('express');
const app = experss();

app.get('/',(req, res) => {
  res.send('Hello cookie-demo')
});

app.listen(3000,() => {
  console.log('Example app listening on port 3000!');
})

终端输入node main.js把服务器跑起来
浏览器输入http://localhost:3000即可看到如下界面

还可以看到，页面已经有了一个请求，但没有cookie相关的信息

cookie工作方式

忘了哪位伟人说过：大胆假设，小心验证，那我们就听一次话吧
先猜测大概流程如

假设如下

• 1、当前没有cookie
• 2、浏览器干啥都不会跟cookie有关系，服务器也不会跟cookie有关系
• 3、某天，服务器发现：”哎，每次都不知道这小子是谁，给它加个身份吧“，然后发送了一个cookie给浏览器，”兄弟，你记一下这个暗号，以后每次向我请求就带上这个东西，以后我就记得住你是谁了“，这称之为setcookie
• 4、浏览器收到后，就把这个cookie记下来了
• 5、以后每次浏览器请求都会带上这个cookie

开始验证

main.js文件中加上res.cookie('cookie1', 'cookie1')

const experss = require('express');
const app = experss();

app.get('/',(req, res) => {
  res.cookie('cookie1', 'cookie1')//这里加上
  res.send('Hello cookie-demo')
});

app.listen(3000,() => {
  console.log('Example app listening on port 3000!');
})

关闭服务器重启后，会发现第一次的请求响应中，带上了Set-Cookie:cookie1=cookie1; Path=/，但是请求头中并没有出现cookie

这时候刷新一下页面，再看看有什么不同？
请求也带上了cookie，也就是说，浏览器已经把cookie记下来了

多加个cookie试试

app.get('/',(req, res) => {
  res.cookie('cookie1', 'cookie1')
  res.cookie('cookie2', 'cookie2')
  res.cookie('cookie3', 'cookie3')
  res.send('Hello cookie-demo')
});

重启刷新两次页面，再看看？

属性

**expires** ： Cookie 失效日期
**max-age**：在 cookie 失效之前需要经过的秒数
**Domain**：指定 cookie 可以送达的主机名。
**Path**：指定一个 URL 路径，这个路径必须出现在要请求的资源的路径中才可以发送 Cookie 首部
**Secure**：一个带有安全属性的 cookie 只有在请求使用SSL和HTTPS协议的时候才会被发送到服务器。
**httpOnly**:设置了 HttpOnly 属性的 cookie 不能使用 JavaScript 经由  Document.cookie 属性、XMLHttpRequest 和  Request APIs 进行访问，以防范跨站脚本攻击（XSS）。

设置属性：expires，max-age, httpOnly

const experss = require('express');
const app = experss();

app.get('/', (req, res) => {
  // 失效时间点
  res.cookie('cookie1', 'cookie1', {
    expires: new Date(Date.now() + 10000)
  });
  // 失效时长
  res.cookie('cookie2', 'cookie2', {
    maxAge: 10000
  });
  // httpOnly
  res.cookie('cookie3', 'cookie3',{
    httpOnly: true
  });
  res.send('Hello cookie-demo');
});

app.listen(3000, () => {
  console.log('Example app listening on port 3000!');
});

由于设置了httpOnly，所以cookie3读不出来

过了十秒钟再刷新，cookie1和cookie2没有了

作用域domain

child1.parent.com 和child2.parent.com 是子域，parent.com 是父域。
当 Cookie 的 domain 为child1.parent.com时 ，那么只有访问child1.parent.com的时候就会带上 Cookie，访问child2.parent.com 的时候是不会带上的
当 Cookie 的 domain 为parent.com时，那么访问child1.parent.com和child2.parent.com 都会带上 Cookie

作用路径

app.get('/parent', (req, res) => {
  res.cookie('parent-name', 'parent-value', {
    path: '/parent'
  })
  res.send('<h1>父路径!</h1>')
})

app.get('/parent/childA', (req, res) => {
  res.cookie('child-name-A', 'child-value-A', {
    path: '/parent/childA'
  })
  res.send('<h1>子路径A!</h1>')
})

app.get('/parent/childB', (req, res) => {
  res.cookie('child-name-B', 'child-value-B', {
    path: '/parent/childB'
  })
  res.send('<h1>子路径B!</h1>')
})

在子路径内可以访问访问到父路径的 Cookie，反过来就不行
父路径就访问不到子路径的cookie

客户端操作cookie

读取

document.cookie

添加

document.cookie='name=value; expires=Thu, 26 Feb 2119 11:50:25 GMT; domain=sankuai.com; path=/';
domain根据需要设置

修改

跟添加是一样的操作，如果name跟现有cookie一样，则改写，否则是添加

删除

把max-age改为0即可

let removeCookie = (name, path, domain) => {
  document.cookie = `${name}=; path=${path}; domain=${domain}; max-age=0`
}

请先看官方文档

上来先看官方文档中对setState()的定义
英文文档最佳
英文-React.Component - React
中文-React.Component - React

一、setState()的实践与问题

先看个最简单的问题，点击按钮后，count是加2吗？

class NextPage extends Component<Props> {
  static navigatorStyle = {
    tabBarHidden: true
  };

  constructor(props) {
    super(props);
    this.state = {
      count: 0
    };
  }

  add() {
    this.setState({
      count: this.state.count + 1
    });
    this.setState({
      count: this.state.count + 1
    });
  }

  render() {
    return (
      <View style={styles.container}>
        <TouchableOpacity
          style={styles.addBtn}
          onPress={() => {
            this.add();
          }}
        >
          <Text style={styles.btnText}>点击+2</Text>
        </TouchableOpacity>

        <Text style={styles.commonText}>当前count {this.state.count}</Text>
      </View>
    );
  }
}

为什么会只加1？

看官网这句话

setState() does not always immediately update the component. It may batch or defer the update until later. This makes reading this.state right after calling setState() a potential pitfall. Instead, use componentDidUpdate or a setState callback (setState(updater, callback)), either of which are guaranteed to fire after the update has been applied. If you need to set the state based on the previous state, read about the updater argument below.

重点是前两句，翻译过来就是
setState()并不总是立即更新组件，它可能会进行批处理或者推迟更新。这使得在调用setState（）之后立即读取this.state成为一个潜在的隐患。

先直接抛出点击按钮加2的正确答案吧，下面两种方法都OK

this.setState(preState => {
  return {
    count: preState.count + 1
  };
});
this.setState(preState => {
  return {
    count: preState.count + 1
  };
});

setTimeout(() => {
  this.setState({
    count: this.state.count + 1
  });
  this.setState({
    count: this.state.count + 1
  });
}, 0);

二、setState源码世界

相信能到这里的同学都知道了setState()是个既能同步又能异步的方法了，那具体什么时候是同步的，什么时候是异步的？只有去源码里面看实现是最靠谱的方式。

注：这里说的同步和异步只是“实现上看起来像同步还是异步，比如上面答案二setTimeout里面，看起来就是同步的”，实质上setState()是异步的

不管这里看不看得懂都没关系了，马上进入源码的世界。

1、如何快速查看react源码

上react的github仓库，直接clone下来
GitHub - facebook/react: A declarative, efficient, and flexible JavaScript library for building user interfaces.

git clone https://github.com/facebook/react.git

到目前我看为止，最新的版本是16.2.0，我选了15.6.0的代码
一是为了参考前辈们的分析成果
二来，我水平有限，如果写的实在不清晰，同学们还可以参考着其他人的分析文章一起读，而不至于完全理解不了

如何切换版本？
1、找到对应版本号

2、复制15.6.0的历史记录号

3、回滚

git reset --hard 911603b

如图，成功回滚到15.6.0版本

2、setState入口 => enqueueSetState

核心原则：既然是看源码，那当然就不是一行一行的读代码，而是看核心的**，所以接下来的代码都只会放核心代码，旁枝末节只提一下或者忽略

setState()的入口文件在src/isomorphic/modern/class/ReactBaseClasses.js

React组件继承自React.Component，而setState是React.Component的方法，因此对于组件来讲setState属于其原型方法

ReactComponent.prototype.setState = function(partialState, callback) {
  this.updater.enqueueSetState(this, partialState);
  if (callback) {
    this.updater.enqueueCallback(this, callback, 'setState');
  }
};

partialState顾名思义-“部分state”，这取名，意思大概就是不影响原来的state的意思吧

当调用setState()时实际上是调用了enqueueSetState方法，我们顺藤摸瓜（我用的是vscode的全局搜索），找到了这个文件src/renderers/shared/stack/reconciler/ReactUpdateQueue.js

这个文件导出了一个ReactUpdateQueue对象，“react更新队列”，代码名字起的好可以自带注释，说的就是这种大作吧，在这里注册了enqueueSetState方法

3、enqueueSetState => enqueueUpdate

先看enqueueSetState的定义

  enqueueSetState: function(publicInstance, partialState) {
    var internalInstance = getInternalInstanceReadyForUpdate(
      publicInstance,
      'setState',
    );
	
    var queue =
      internalInstance._pendingStateQueue ||
      (internalInstance._pendingStateQueue = []);
    queue.push(partialState);

    enqueueUpdate(internalInstance);
  },

这里只需要关注internalInstance的两个属性
_pendingStateQueue：待更新队列
_pendingCallbacks： 更新回调队列

如果_pendingStateQueue的值为null，将其赋值为空数组[]，并将partialState放入待更新state队列_pendingStateQueue。最后执行enqueueUpdate(internalInstance);

接下来看enqueueUpdate

function enqueueUpdate(internalInstance) {
  ReactUpdates.enqueueUpdate(internalInstance);
}

它执行的是ReactUpdates的enqueueUpdate方法

var ReactUpdates = require('ReactUpdates');

这个文件刚好就在旁边，不用找了src/renderers/shared/stack/reconciler/ReactUpdates.js

找到enqueueUpdate方法

enqueueUpdate方法定义

function enqueueUpdate(component) {
  ensureInjected();

  if (!batchingStrategy.isBatchingUpdates) {
    batchingStrategy.batchedUpdates(enqueueUpdate, component);
    return;
  }

  dirtyComponents.push(component);
  if (component._updateBatchNumber == null) {
    component._updateBatchNumber = updateBatchNumber + 1;
  }
}

这段话对于理解setState非常重要

if (!batchingStrategy.isBatchingUpdates) {
    batchingStrategy.batchedUpdates(enqueueUpdate, component);
    return;
  }
dirtyComponents.push(component);

判断batchingStrategy.isBatchingUpdates
batchingStrategy是批量更新策略，isBatchingUpdates表示是否处于批量更新过程，开始默认值为false

上面这句话的意思是：
如果处于批量更新模式，也就是isBatchingUpdates为true时，不进行state的更新操作，而是将需要更新的component添加到dirtyComponents数组中

如果不处于批量更新模式，对所有队列中的更新执行batchedUpdates方法，往下看下去就知道是用事务的方式批量的进行component的更新，事务在下面。

借用《深入React技术栈》Page167中一图

4、核心：batchedUpdates => 调用transaction

那batchingStrategy.isBatchingUpdates又是怎么回事呢？看来它才是关键

但是，batchingStrategy 对象并不好找，它是通过 injection 方法注入的，一番寻找，发现了 batchingStrategy 就是 ReactDefaultBatchingStrategy。
src/renderers/shared/stack/reconciler/ReactDefaultBatchingStrategy.js
具体怎么找文件，又属于另一个范畴了，我们今天只专注 setState，其他的容后再说吧

相信部分同学在这里已经有些迷糊了，没关系，再坚持一下，旁枝末节先不管，只知道我们找到了核心方法batchedUpdates，马上要胜利了，别放弃（我第一次看也是这样熬过来的，一遍不行就两遍，大不了看多几遍）

先看批量更新策略-batchingStrategy，它到底是什么

var ReactDefaultBatchingStrategy = {
  isBatchingUpdates: false,

  batchedUpdates: function(callback, a, b, c, d, e) {
    var alreadyBatchingUpdates = ReactDefaultBatchingStrategy.isBatchingUpdates;

    ReactDefaultBatchingStrategy.isBatchingUpdates = true;

    if (alreadyBatchingUpdates) {
      return callback(a, b, c, d, e);
    } else {
      return transaction.perform(callback, null, a, b, c, d, e);
    }
  },
};

module.exports = ReactDefaultBatchingStrategy;

终于找到了，isBatchingUpdates属性和batchedUpdates方法

如果isBatchingUpdates为true，当前正处于更新事务状态中，则将Component存入dirtyComponent中，
否则调用batchedUpdates处理，发起一个transaction.perform()

所有的 batchUpdate 功能都是通过执行各种 transaction 实现的

这是事务的概念，先了解一下事务吧

5、事务

这一段就直接引用书本里面的概念吧，《深入React技术栈》Page169

简单地说，一个所谓的 Transaction 就是将需要执行的 method 使用 wrapper 封装起来，再通过 Transaction 提供的 perform 方法执行。而在 perform 之前，先执行所有 wrapper 中的 initialize 方法；perform 完成之后（即 method 执行后）再执行所有的 close 方法。一组 initialize 及 close 方法称为一个 wrapper，从上面的示例图中可以看出 Transaction 支持多个 wrapper 叠加。

具体到实现上，React 中的 Transaction 提供了一个 Mixin 方便其它模块实现自己需要的事务。而要使用 Transaction 的模块，除了需要把 Transaction 的 Mixin 混入自己的事务实现中外，还需要额外实现一个抽象的 getTransactionWrappers 接口。这个接口是 Transaction 用来获取所有需要封装的前置方法（initialize）和收尾方法（close）的，因此它需要返回一个数组的对象，每个对象分别有 key 为 initialize 和 close 的方法。

下面这段代码应该能帮助理解

var Transaction = require('./Transaction');

// 我们自己定义的 Transaction
var MyTransaction = function() {
  // do sth.
};

Object.assign(MyTransaction.prototype, Transaction.Mixin, {
  getTransactionWrappers: function() {
    return [{
      initialize: function() {
        console.log('before method perform');
      },
      close: function() {
        console.log('after method perform');
      }
    }];
  };
});

var transaction = new MyTransaction();
var testMethod = function() {
  console.log('test');
}
transaction.perform(testMethod);

// before method perform
// test
// after method perform

6、核心分析：batchingStrategy 批量更新策略

回到batchingStrategy：批量更新策略，再看看它的代码实现

var ReactDefaultBatchingStrategy = {
  isBatchingUpdates: false,

  batchedUpdates: function(callback, a, b, c, d, e) {
    var alreadyBatchingUpdates = ReactDefaultBatchingStrategy.isBatchingUpdates;

    ReactDefaultBatchingStrategy.isBatchingUpdates = true;

    if (alreadyBatchingUpdates) {
      return callback(a, b, c, d, e);
    } else {
      return transaction.perform(callback, null, a, b, c, d, e);
    }
  },
};

可以看到isBatchingUpdates的初始值是false的，在调用batchedUpdates方法的时候会将isBatchingUpdates变量设置为true。然后根据设置之前的isBatchingUpdates的值来执行不同的流程

还记得上面说的很重要的那段代码吗

if (!batchingStrategy.isBatchingUpdates) {
    batchingStrategy.batchedUpdates(enqueueUpdate, component);
    return;
  }
dirtyComponents.push(component);

首先，点击事件的处理本身就是在一个大的事务中（这个记着就好），isBatchingUpdates已经是true了

调用setState()时，调用了ReactUpdates.batchedUpdates用事务的方式进行事件的处理

在setState执行的时候isBatchingUpdates已经是true了，setState做的就是将更新都统一push到dirtyComponents数组中；

在事务结束的时候才通过 ReactUpdates.flushBatchedUpdates 方法将所有的临时 state merge 并计算出最新的 props 及 state，然后将批量执行关闭结束事务。

到这里我并没有顺着ReactUpdates.flushBatchedUpdates方法讲下去，这部分涉及到渲染和Virtual Dom的内容，反正你知道它是拿来执行渲染的就行了。
到这里为止，setState的核心概念已经比较清楚了，再往下的内容，暂时先知道就行了，不然展开来讲一环扣一环太杂了，我们做事情要把握核心。

到这里不知道有没有同学想起一个问题
isBatchingUpdates 标志位在 batchedUpdates 发起的时候被置为 true ，那什么时候被复位为false的呢？
还记得上面的事务的close方法吗，同一个文件
src/renderers/shared/stack/reconciler/ReactDefaultBatchingStrategy.js

// 定义复位 wrapper
var RESET_BATCHED_UPDATES = {
  initialize: emptyFunction,
  close: function () {
    ReactDefaultBatchingStrategy.isBatchingUpdates = false;
  }
};

// 定义批更新 wrapper
var FLUSH_BATCHED_UPDATES = {
  initialize: emptyFunction,
  close: ReactUpdates.flushBatchedUpdates.bind(ReactUpdates)
};

var TRANSACTION_WRAPPERS = [FLUSH_BATCHED_UPDATES, RESET_BATCHED_UPDATES];

function ReactDefaultBatchingStrategyTransaction() {
  this.reinitializeTransaction();
}

_assign(ReactDefaultBatchingStrategyTransaction.prototype, Transaction, {
  getTransactionWrappers: function () {
    return TRANSACTION_WRAPPERS;
  }
});

相信眼尖的同学已经看到了，close的时候复位，把isBatchingUpdates设置为false。

Object.assign(ReactDefaultBatchingStrategyTransaction.prototype, Transaction, {
  getTransactionWrappers: function() {
    return TRANSACTION_WRAPPERS;
  },
});

var transaction = new ReactDefaultBatchingStrategyTransaction();

通过原型合并，事务的close 方法，将在 enqueueUpdate 执行结束后，先把 isBatchingUpdates 复位，再发起一个 DOM 的批更新

到这里，我们会发现，前面所有的队列、batchUpdate等等都是为了来到事务的这一步，前面都只是批收集的工作，到这里才真正的完成了批更新的操作。

7、再回到题目

add() {
    this.setState({
      count: this.state.count + 1
    });
    this.setState({
      count: this.state.count + 1
    });
  }

setTimeout(() => {
  this.setState({
    count: this.state.count + 1
  });
  this.setState({
    count: this.state.count + 1
  });
}, 0);

这两段代码

第一种情况，在执行第一个setState时，本身已经处于一个点击事件触发的这个大事务中，已经触发了一个batchedUpdates，isBatchingUpdates为true，所以两个setState都会被批量更新，这时候属于异步过程，this.state并没有立即改变，执行setState只是相当于把partialState（前面说的部分state）传入dirtyComponents，最后在事务的close阶段执行flushBatchedUpdates去重新渲染。

第二种情况，有了setTimeout，两次setState都会在点击事件触发的大事务中的批量更新batchedUpdates结束之后再执行，所以他们会触发两次批量更新batchedUpdates，也就会执行两个事务和函数flushBatchedUpdates，就相当于同步更新的过程了。

参考
React技术内幕 setState的秘密 - 掘金
React源码分析 - 组件更新与事务 - 掘金
源码看React setState漫谈（一） - 前端成长之路 - SegmentFault 思否
源码看React setState漫谈（二） - 前端成长之路 - SegmentFault 思否

前言

最近在进行RN项目重构，通过查阅各种资料，从RN底层出发，思考总结了一些从react到react-native的性能优化相关问题

Performance · React Native
请先认真查看官方文档（英文文档）这一章节
前方高能请注意：Unbundling + inline requires这一节，中文文档木有！！！

先看看可能会导致产生性能问题的常见原因

这里先给出我自己的结论，然后会从底层原理开始理解为何要这样做，最后是每项方法的具体展开（未完待续）

这部分都不是死知识，可能哪天我又会有更广阔的思路与解决办法，或许会推翻现在的结论，所以本文会持续保持更新。。。

RN性能优化概述

谈性能之前，我们先了解一下RN的工作原理

通过RN我们可以用JS实现跨平台App，也就是FB说的write once, run everywhere

RN为我们提供了JS的运行环境，所以前端开发者们只需要关心如何编写JS代码，画UI只需要画到virtual DOM 中，不需要特别关心具体的平台

至于如何把JS代码转成native代码的脏活累活，RN底层全干了

RN的本质是把中间的这个桥Bridge给搭好，让JS和native可以互相调用

RN的加载流程主要为几个阶段

• 初始化RN环境
  • 创建Bridge
  • Bridge中的JS环境
  • RN模块、UI组件
• 下载JS Bundle
• 运行JS Bundle
• 渲染页面

Dive into React Native performance | Engineering Blog | Facebook Code | Facebook

通过对FaceBook的ios版进行性能测试，得到上面的耗时图
可以看到，绿色的JS Init + Require占据了一大半的时间，这部分主要的操作是初始化JS环境：下载JS Bundle、运行JS Bundle

JS Bundle 是由 RN 开发工具打包出来的 JS 文件，其中不仅仅包含了RN 页面组件的 JS 代码，还有 react、react-native 的JS代码，还有我们经常会用上的redux、react-navigation等的代码，RN 非常简单的 demo 页面minify 之后的 JS Bundle 文件有接近 700KB，所以 JS Bundle文件大小是性能优化的瓶颈

假设我们有一个大型App，它囊括了非常多的页面，但是在常规使用中，很多页面甚至都不会被打开，还有一些复杂的配置文件以及很少使用的功能，这些相关的代码，在App启动的时候都是不需要的，那么，我们就可以考虑通过Unbundling拆包来优化性能

关于如何减少Bundle包的大小，目前主流的方法是拆分Bundle包，把框架代码和业务代码单独出来，框架代码非常大，因此要分离出来单独前置加载，而业务代码则变成很小的JS代码单独发布，下面提供一些前人的经验链接

但在拆包之前，FB官方还提了几条在此之前更应该做好的优化点

Doing less

• Cleanup Require/Babel helpers
• Avoid copying and decoding strings when loading the bundle
• Stripping DEV-only modules

Scheduling

• Lazy requires
• Relay incremental cache read
• De-batching bridge calls, batch Relay calls
• Early UI flushing
• Lazy native modules loading
• Lazy touch bindings on text components

React-Native通用化建设与性能优化 - Web前端 腾讯IVWeb 团队社区
不愧是腾讯，主要讲了通用化建设、bundle本地分包、项目线上性能分析几项
RN分包之Bundle改造
RN 打包那些事儿 | YMFE
React Native拆包及热更新方案 · Solartisan

说到unbundling，官方文档还把 inline requires 一并合起来分析了

Inline requires delay the requiring of a module or file until that file is actually needed.
inline requires延迟加载模块或者文件，直到真的需要它们

看个小例子就很容易明白了

import React, { Component } from 'react';
import { Text } from 'react-native';
// ... import some very expensive modules

// You may want to log at the file level to verify when this is happening
console.log('VeryExpensive component loaded');

export default class VeryExpensive extends Component {
  // lots and lots of code
  render() {
    return <Text>Very Expensive Component</Text>;
  }
}

import React, { Component } from 'react';
import { TouchableOpacity, View, Text } from 'react-native';

// 先把这个组件赋值为null
let VeryExpensive = null;

export default class Optimized extends Component {
  state = { needsExpensive: false };

  didPress = () => {
    if (VeryExpensive == null) {
		// 真正需要这个组件的时候才加载
      VeryExpensive = require('./VeryExpensive').default;
    }

    this.setState(() => ({
      needsExpensive: true,
    }));
  };

  render() {
    return (
      <View style={{ marginTop: 20 }}>
        <TouchableOpacity onPress={this.didPress}>
          <Text>Load</Text>
        </TouchableOpacity>
		  // 根据需要判断是否渲染该组件
        {this.state.needsExpensive ? <VeryExpensive /> : null}
      </View>
    );
  }
}

Even without unbundling inline requires can lead to startup time improvements, because the code within VeryExpensive.js will only execute once it is required for the first time

上面的内容主要是关于首屏渲染速度的性能优化

那么进入App后的性能点又在哪里呢？还是回到Bridge

首先，在苹果和谷歌两位大佬的光环下，native代码在设备上的运行速度毋容置疑，而JS作为脚本语言，本来就是以快著称，也就是说两边的独立运行都很快，如此看来，性能瓶颈只会出现在两端的通信上，但两边其实不是直接通信的，而是通过Bridge做中间人，查找、调用模块、接口等操作逻辑，会产生到能让UI层明显可感知的卡顿，那么性能控制就变成了如何尽量减少Bridge所需要的逻辑。

• UI事件响应
  这块内容都发生在Native端，以事件形式传递到JS端，只是一个触发器，不会有过度性能问题
• UI更新
  JS是决定显示什么界面，如何样式化页面的，一般都是由JS端发起UI更新，同时向native端同步大量的数据和UI结构，这类更新会经常出现性能问题，特别是界面复杂、数据变动量大、动画复杂、变动频率高的情况
• UI事件响应+UI更新
  如果UI更新改动不大，那么问题不大
  如果UI事件触发了UI更新，同时逻辑复杂、耗时比较长，JS端和Native端的数据同步可能会出现时间差，由此会引发性能问题

总结起来，核心的RN性能优化点就比较清晰明朗了

• 首屏渲染优化：处理JS Bundle包大小、文件压缩、缓存
• UI更新优化
  • 减少更新或者合并多个更新
  • 提高组件响应速度：
    • setNativeProps直接在底层更新Native组件属性（其实没有解决JS端与Native端的数据同步问题）
    • 立即执行更新回调
  • 动画优化
    • 通过使用Annimated类库，一次性把更新发送到Native端，由Native端自己负责更新
    • 把一些耗时操作放到动画与UI更新之后执行
• 其他优化（代码层面）

每个小点主要会按照容易实施执行的顺序来写

一、是否重新渲染——shouldComponentUpdate

生命周期请看官方文档React.Component - React

react应用中的state和props的改变都会引起re-render

考虑下面这种情况

class Home extends Component<Props> {
  constructor(props) {
    super(props);
    this.state = {
      a: '点我看看会不会re-render',
    }
  }

  render() {
    console.log('重新渲染   re-render------------------');
    return (
      <View style={styles.container}>
        <TouchableOpacity style={styles.addBtn} onPress={() => this.setState({ a: this.state.a })}>
          <Text>{this.state.a}</Text>
        </TouchableOpacity>
      </View>
    );
  }
}

核心代码是this.setState({ a: this.state.a })

明明没有改变a，只是setState了一下而已，就直接触发了重新渲染，试想一下，如果页面有大型数据，这会造成多大的性能浪费

加上shouldComponentUpdate钩子看看如何

  shouldComponentUpdate(nextProps, nextState) {
    return nextState.a !== this.state.a
  }

嗯，这下好了点，不会无脑渲染了

那么假如是个引用对象呢？

const obj = { num: 1 };
class Home extends Component<Props> {
  constructor(props) {
    super(props);
    this.state = {
      b: null
    }
  }

  componentWillMount() {
    this.setState({
      b: obj
    })
  }

  render() {
    console.log('重新渲染   re-render------------------');
    return (
      <View style={styles.container}>
        <TouchableOpacity style={styles.addBtn} onPress={() => {
          obj.num++;
          this.setState({
            b: obj
          })
        }}>
          <Text>{this.state.b.num}</Text>
        </TouchableOpacity>
      </View>
    );
  }
}

给b永远指向同一个引用对象obj，虽然每次点击的时候，obj.num都会被改变
但是，页面会不会重新渲染呢？
继续看图

很好，对象的内容变了，页面也重新渲染

那么加上shouldComponentUpdate比较一下呢？

shouldComponentUpdate(nextProps, nextState) {
    return nextState.b !== this.state.b
  }

页面毫无变化
原因：b每次都指向了同一个引用对象obj，引用地址没变，shouldComponentUpdate只会做浅比较，自然会返回false，页面不会重新渲染

到这里应该能很好的解释了shouldComponentUpdate的特点

那么如何处理引用对象的情况呢？目前最推崇的做法是使用不可变对象immutablejs，facebook自家出的
GitHub - facebook/immutable-js
好了，研究去吧

另外，还有个pureComponent，看下官方介绍就好了
React Top-Level API - React

React.PureComponent
React.PureComponent is similar to React.Component. The difference between them is that React.Component doesn’t implement shouldComponentUpdate(), but React.PureComponent implements it with a shallow prop and state comparison.

If your React component’s render() function renders the same result given the same props and state, you can use React.PureComponent for a performance boost in some cases.

Note

React.PureComponent’s shouldComponentUpdate() only shallowly compares the objects. If these contain complex data structures, it may produce false-negatives for deeper differences. Only extend PureComponent when you expect to have simple props and state, or use forceUpdate() when you know deep data structures have changed. Or, consider using immutable objects to facilitate fast comparisons of nested data.

Furthermore, React.PureComponent’s shouldComponentUpdate() skips prop updates for the whole component subtree. Make sure all the children components are also “pure”.

说到底，也只是会自动使用shouldComponentUpdate钩子的普通Component而已，没什么特殊的

二、组件响应速度（InteractionManager、requestAnimationFrame、setNativeProps）

1）InteractionManager

InteractionManager和requestAnimationFrame(fn)的作用类似，都是为了避免动画卡顿，具体的原因是边渲染边执行动画，或者有大量的code计算阻塞页面进程。
InteractionManager.runAfterInteractions是在动画或者操作结束后执行

InteractionManager.runAfterInteractions(() => {
  // ...long-running synchronous task...
});

2）requestAnimationFrame

window.requestAnimationFrame - Web API 接口 | MDN
使用requestAnimationFrame(fn)在下一帧就立即执行回调，这样就可以异步来提高组件的响应速度；

OnPress() {
  this.requestAnimationFrame(() => {
    // ...setState操作
  });
}

还有setImmediate/setTimeout(): 这个是比较原始的奔方法，很有可能影响动画的流畅度

3） setNativeProps

Direct Manipulation · React Native
通过Direct Manipulation的方式直接在底层更新了Native组件的属性，从而避免渲染组件结构和同步太多视图变化所带来的大量开销。

这样的确会带来一定的性能提升，同时也会使代码逻辑难以理清，而且并没有解决从JS侧到Native侧的数据同步开销问题。

因此这个方式官方都不再推荐，更推荐的做法是合理使用setState()和shouldComponentUpdate()方法解决这类问题。

Use setNativeProps when frequent re-rendering creates a performance bottleneck
Direct manipulation will not be a tool that you reach for frequently; you will typically only be using it for creating continuous animations to avoid the overhead of rendering the component hierarchy and reconciling many views. setNativeProps is imperative and stores state in the native layer (DOM, UIView, etc.) and not within your React components, which makes your code more difficult to reason about. Before you use it, try to solve your problem with setState and shouldComponentUpdate.

三、动画

Animated的前提是尽量减少不必要的动画，具体的使用方式请看官方文档Animated · React Native

如果觉得Animated的计算很麻烦，比如一些折叠、增加减少view、改变大小等简单的操作，可以使用LayoutAnimation来流畅的完成一次性动画
看下直接setState和使用LayoutAnimation后的效果对比

直接setState

LayoutAnimation效果1

LayoutAnimation效果2

使用很简单，分为两种情况

• 使用默认的效果
  在componentWillUpdate钩子里面，让整个组件所有动画都应该该效果，或者在单独需要动画的setState方法前面使用LayoutAnimation.spring();

componentWillUpdate() {
    // spring, easeInEaseOut, linear
    LayoutAnimation.linear();
  }

• 使用自定义的效果

componentWillUpdate() {
    LayoutAnimation.configureNext(config)
  }

const config = {
  duration: 500, // 动画时间
  create: {
  // spring,linear,easeInEaseOut,easeIn,easeOut,keyboard
    type: LayoutAnimation.Types.linear,
  // opacity,scaleXY 透明度，位移
    property: LayoutAnimation.Properties.opacity,
  },
  update: {
  // 更新时显示的动画
    type: LayoutAnimation.Types.easeInEaseOut,
  }
};

（未完待续。。。）

后记

感谢您耐心看到这里，希望有所收获！

如果不是很忙的话，麻烦点个star⭐【Github博客传送门】，举手之劳，却是对作者莫大的鼓励。

我在学习过程中喜欢做记录，分享的是自己在前端之路上的一些积累和思考，希望能跟大家一起交流与进步。

#Front-End/JS/基础

参考资料
从一道题说JavaScript的事件循环
这一次，彻底弄懂 JavaScript 执行机制 - 掘金 这篇真的讲的特别通俗易懂
【朴灵评注】JavaScript 运行机制详解：再谈Event Loop - CSDN博客
event loop英文版 有动画
Node 定时器详解-阮一峰 - 后端 - 掘金
从event loop规范探究javaScript异步及浏览器更新渲染时机 · Issue #5 · aooy/blog · GitHub 本篇文章用了实验测试

JS是单线程的，这个线程中拥有唯一的一个事件循环，一切javascript版的"多线程"都是用单线程模拟出来的

事件循环是js实现异步的一种方法，也是js的执行机制

事件循环的顺序

事件循环的顺序，决定js代码的执行顺序。进入整体代码(宏任务)后，开始第一次循环。接着执行所有的微任务。然后再次从宏任务开始，找到其中一个任务队列执行完毕，再执行所有的微任务。

微任务与宏任务

宏任务

1. script(整体代码)
2. setTimeout、setInterval，这二者同源，旗下微任务会进入相同的任务队列
3. I/O
4. UI rendering
5. setImmediate(Node.js 环境)

微任务

1. Promise
2. MutaionObserver(HTML5 新特性)
3. process.nextTick(Node.js 环境)

题外补充知识

JavaScript执行环境（Runtime）和执行引擎（Engine）的关系

JavaScript引擎的内部运行机制跟Event loop没有半毛钱的关系

引擎指的是虚拟机，对于Node来说是V8、对Chrome来说是V8、对Safari来说JavaScript Core，对Firefox来说是SpiderMonkey

JavaScript的执行环境就是上面所说的浏览器、node、Ringo

为什么JS是单线程的

与用途有关，JavaScript的主要用途是与用户互动，以及操作DOM
假定JavaScript同时有两个线程，一个线程在某个DOM节点上添加内容，另一个线程删除了这个节点，这时浏览器应该以哪个线程为准？

为了利用多核CPU的计算能力，HTML5提出Web Worker标准，允许JavaScript脚本创建多个线程，但是子线程完全受主线程控制，且不得操作DOM。所以，这个新标准并没有改变JavaScript单线程的本质。

任务队列

只要主线程空了，就会去读取"任务队列"，这就是JavaScript的运行机制。这个过程会不断重复。

【JavaScript运行环境的运行机制，不是JavaScript的运行机制。】

朴灵大佬怼阮老师的原文

【上面这段初步地在说event loop。但是异步跟event loop其实没有关系。准确的讲，event loop是实现异步的一种机制】
【一般而言，操作分为：发出调用和得到结果两步。发出调用，立即得到结果是为同步。发出调用，但无法立即得到结果，需要额外的操作才能得到预期的结果是为异步。同步就是调用之后一直等待，直到返回结果。异步则是调用之后，不能直接拿到结果，通过一系列的手段才最终拿到结果（调用之后，拿到结果中间的时间可以介入其他任务）。】
【上面提到的一系列的手段其实就是实现异步的方法，其中就包括event loop。以及轮询、事件等。】
【所谓轮询：就是你在收银台付钱之后，坐到位置上不停的问服务员你的菜做好了没。】
【所谓（事件）：就是你在收银台付钱之后，你不用不停的问，饭菜做好了服务员会自己告诉你。】

nodejs的event loop分为6个阶段

不要混淆nodejs和浏览器中的event loop
每一轮的事件循环，分成六个阶段。这些阶段会依次执行。

timers

setTimeout、setInterval

I/O callbacks

除了以下操作的回调函数，其他的回调函数都在这个阶段执行。

• setTimeout()和setInterval()的回调函数
• setImmediate()的回调函数
• 用于关闭请求的回调函数，比如socket.on('close', ...)

idle, prepare

该阶段只供 libuv 内部调用，这里可以忽略

poll

这个阶段是轮询时间，用于等待还未返回的 I/O 事件，比如服务器的回应、用户移动鼠标等等。

这个阶段的时间会比较长。如果没有其他异步任务要处理（比如到期的定时器），会一直停留在这个阶段，等待 I/O 请求返回结果。

check

setImmediate

close callbacks

该阶段执行关闭请求的回调函数，比如socket.on('close', ...)。

setTimeout和setImmediate的先后顺序

由于setTimeout在 timers 阶段执行，而setImmediate在 check 阶段执行。所以，setTimeout会早于setImmediate完成。

实际执行的时候，结果却是不确定

setTimeout(() => console.log(1));
setImmediate(() => console.log(2));

实际执行的时候，进入事件循环以后，有可能到了1毫秒，也可能还没到1毫秒，取决于系统当时的状况。如果没到1毫秒，那么 timers 阶段就会跳过，进入 check 阶段，先执行setImmediate的回调函数

但是，这个代码却setImmediate优先于setTimeout执行

const fs = require('fs');

fs.readFile('test.js', () => {
  setTimeout(() => console.log(1));
  setImmediate(() => console.log(2));
});

上面代码会先进入 I/O callbacks 阶段，然后是 check 阶段，最后才是 timers 阶段。因此，setImmediate才会早于setTimeout执行。

浏览器层面的event loop

有两种event loops，一种在浏览器上下文，一种在workers中。

浏览器上下文是一个将 Document 对象呈现给用户的环境。在一个 Web 浏览器内，一个标签页或窗口常包含一个浏览上下文，如一个 iframe 或一个 frameset 内的若干 frame。

每个线程都有自己的event loop。
浏览器可以有多个event loop，browsing contexts和web workers就是相互独立的。
所有同源的browsing contexts可以共用event loop，这样它们之间就可以相互通信。

event loop中的Update the rendering（更新渲染）

从event loop规范探究javaScript异步及浏览器更新渲染时机 · Issue #5 · aooy/blog · GitHub 这里用了实验测试

渲染的基本流程

1. 处理 HTML 标记并构建 DOM 树。
2. 处理 CSS 标记并构建 CSSOM 树， 将 DOM 与 CSSOM 合并成一个渲染树。
3. 根据渲染树来布局，以计算每个节点的几何信息。
4. 将各个节点绘制到屏幕上。

Note: 可以看到渲染树的一个重要组成部分是CSSOM树，绘制会等待css样式全部加载完成才进行，所以css样式加载的快慢是首屏呈现快慢的关键点。

结论

在一轮event loop中多次修改同一dom，只有最后一次会进行绘制。

渲染更新（Update the rendering）会在event loop中的tasks和microtasks完成后进行，但并不是每轮event loop都会更新渲染，这取决于是否修改了dom和浏览器觉得是否有必要在此时立即将新状态呈现给用户。如果在一帧的时间内（时间并不确定，因为浏览器每秒的帧数总在波动，16.7ms只是估算并不准确）修改了多处dom，浏览器可能将变动积攒起来，只进行一次绘制，这是合理的。

如果希望在每轮event loop都即时呈现变动，可以使用requestAnimationFrame。

具体浏览器的工作原理参考这里新式网络浏览器幕后揭秘

当用户输入URL后

第一步就是DNS预解析

一、原理

域名系统 - 维基百科，自由的百科全书
Domain Name System 将域名和IP地址相互映射的一个分布式数据库

DNS 预读取是一项使浏览器主动去执行域名解析的功能，其范围包括文档的所有链接，无论是图片的，CSS 的，还是 JavaScript 等其他用户能够点击的 URL，减少用户点击链接时的延迟。

当浏览器访问一个域名的时候，需要解析一次DNS，获得对应域名的ip地址。
浏览器缓存 => 系统缓存 => 路由器缓存 =>ISP(运营商)DNS缓存 => 根域名服务器 => 顶级域名服务器 => 主域名服务器的顺序
逐步读取缓存，直到拿到IP地址

作用：根据浏览器定义的规则，提前解析之后可能会用到的域名，使解析结果缓存到系统缓存中，缩短DNS解析时间，来提高网站的访问速度

二、如何使用

1、打开和关闭DNS预解析

希望在HTTPS页面开启自动解析功能时，添加如下标记

<meta http-equiv="x-dns-prefetch-control" content="on">
// off 则是关闭

也可以通过在服务器端发送 X-DNS-Prefetch-Control 报头

2、自动解析

Chromium会自动解析href属性（a标签），该行为与用户浏览网页是并行的。但为了确保安全，HTTPS页面不会自动解析
DNS Prefetching - Chromium官方文档

Chromium不使用浏览器的网络堆栈，直接使用操作系统的缓存。通过8个异步线程执行预解析，每个线程处理一个队列，来等待域名的响应，最终操作系统会响应一个DNS结果给线程，然后线程丢弃它，等待下一个预解析请求。

3、手动添加解析

<link rel="dns-prefetch" href="http://www.google.com">

4、在浏览器中设置

一般来说并不需要去管理预读取，但是可能会有用户希望关闭预读取功能。这时只需要设置 network.dns.disablePrefetch preference 值为 true 就可以了

默认情况下，通过 HTTPS 加载的页面上内嵌链接的域名并不会执行预加载。在 Firefox 浏览器中，可以通过设置 network.dns.disablePrefetchFromHTTPS 值为 false 来改变这一默认行为。

三、看看淘宝的DNS预解析

DNS Prefetch 的原理就是在 HTTP 建立之前，将 DNS 查询的结果缓存到系统/浏览器中，提升网页的加载效率

让我们来实际看一下淘宝的DNS预解析是怎么做的

进WebPagetest输入https://www.taobao.com
找到结果中的下面内容，看DNS Lookup一项
那些结果比较大的，就是没有预解析的

打开淘宝，看它的link标签，带rel='dns-prefetch'的那些
然后应该可以发现，上面那些解析时间比较长的域名没有在这个列表中

四、使用场景

1、新用户访问，后端可以通过 Cookie 判断是否为首次进入站点，对于这类用户，DNS Prefetch 可以比较明显地提升访问速度
2、登录页，提前在页面上进行下一跳页用到资源的 DNS Prefetch
2、上面说到chrome使用了8个异步线程来处理DNS预解析，所以过多的prefetch并不一定能提高网页加载效率

五、如何更好的使用？

1、对哪些资源做手动prefetch

1、静态资源域名
2、JS里会发起跳转的域名
3、会重定向的域名

2、不用对超链接做手动prefetch，浏览器会自动做

3、手动DNS预解析还可以优化吗？

实际上还是会增加html的代码量的，特别是域名多的情况下
可以通过js初始化一个iframe异步加载一个页面，而这个页面里包含本站所有的需要手动dns prefetching的域名

4、页面Head里面有个css链接, 在当前页的Head里加上对应的手动dns prefetching的link标签，实际上并没有好处

六、域名发散和域名收敛

1、域名发散

在PC上，为了突破浏览器的单域名多线程并发限制，大家会采用域名发散：http 静态资源采用多个子域名，以提供最大并行度，让客户端加载静态资源更为迅速

为什么浏览器要做并发限制？
1、以前的服务器负载能力差，流量大容易奔溃，所以为了保护服务器，浏览器做了单域名最大并发限制
2、防止DDOS攻击，最基本的 DoS 攻击就是利用合理的服务请求来占用过多的服务资源，从而使合法用户无法得到服务的响应。如果不限制并发请求数量…

2、域名收敛

顾名思义：尽量将静态资源只放在一个域名下面

既然域名发散优点这么明显，那么域名收敛怎么来的？

上面说了是PC下使用域名发散，那么现在是移动互联网时代，无线设备占多（写这个文章的时候是2018年末，5G都快来了，地域和网速限制马上不会再成为瓶颈，但还是要究其根本）

首先，HTTP请求需要经历这么个过程
DNS域名解析 -> TCP 3次握手 -> 发起HTTP请求 -> 服务器响应HTTP请求 -> …… -> 浏览器解析渲染页面

第一个DNS解析是一个很复杂的过程，此处略过…

PC上DNS解析消耗相对较小
但移动端（假设信号不够强）的DNS消耗是比较可观的（相对而言）
所以，在增加域名的同时，会带来一定的DNS解析消耗，所以域名收敛能降低这个成本。

但是，单纯的靠域名收敛降低这个成本，貌似对性能提升是个鸡肋

那么单域名的并发问题还是存在，怎么处理，核心是解除最大连接数的限制，那么SPDY/HTTP2的多路复用功能就派上用场了

这两新协议对HTTP1.1做了不少的优化，核心是减少连接数，还有头部压缩、服务器推送，强制SSL安全协议等等

总的来说，尽快拥抱新技术吧

一、读取文件

前端无法向原生App那样直接操作本地文件，不然一个网页就能偷光用户电脑上的文件，用户想要触发文件操作，主要有三种

1、<input type='file' />选择本地文件
2、通过拖拽，利用drop事件
3、在编辑框里面复制粘贴（这里不讲，有兴趣的同学可当做延伸题目自己去了解）

1、<input type='file' />

<input id="file1" type="file">

// 监听input的change事件，通过e拿到文件
$('#file1').change(e => {
  const files = e.target.files || e.dataTransfer.files;
});

可以打印files看一下是什么，可以看到是一个对象，以files[0]表示具体的文件，还有一个长度属性是1
（如果同时导入多个文件，估计就是files[1]、files[2]的读法了，长度就是对应的文件数量，这里纯靠猜，本人没实践过，有兴趣的同学可以自己研究）

这里要注意的是，这个files在很多时候都是不可用的，还需要转换成base64格式或者其他格式才能使用，怎么转换等下就讲，总之就是目前拿到的files没*用

2、拖拽

// 一个空的div就可以了，样式自己写吧
<div id="dropbox" />

const dropbox = $('#dropbox');
// jQuery的监听事件用on，不用addEventListener
dropbox.on({
  // 阻止dragenter和dragover事件的默认行为
  dragenter: dragenter,
  dragover: dragover,
  drop: drop
})

function dragenter(e) {
  e.stopPropagation();
  e.preventDefault();
}
function dragover(e) {
  e.stopPropagation();
  e.preventDefault();
}

function drop(e) {
  e.stopPropagation();
  e.preventDefault();
  // 在jQuery里面,得来originalEvent才拿得到
  const files = e.originalEvent.dataTransfer.files;
}

在jQuery里面，需要去originalEvent的dataTransfer里面才拿得到文件;
拖拽事件，还需要处理掉默认行为

到目前为主，我们只是拿到了两类没*用的files，还需要转换为能在页面上预览的格式以及可以上传到服务器的格式才行，传说中的base64。

二、处理文件（bsae64）与预览

图片的 base64 编码就是可以将一副图片数据编码成一串字符串，使用该字符串代替图像地址。（省去了一次HTTP请求，但只针对于小图片，大图片转码后可能占用的内存更大）

转换文件，目前有两种常用的方式：FileReader、ObjectURL

FileReader

老惯例，先上MDN
FileReader - Web API 接口 | MDN

FileReader 对象允许Web应用程序异步读取存储在用户计算机上的文件（或原始数据缓冲区）的内容，使用 File 或 Blob 对象指定要读取的文件或数据。

其中File对象可以是来自用户在一个元素上选择文件后返回的FileList对象,也可以来自拖放操作生成的 DataTransfer对象,还可以是来自在一个HTMLCanvasElement上执行mozGetAsFile()方法后返回结果。

FileReader 包括四个异步读取文件的选项（具体请查阅）
FileReader.readAsArrayBuffer()、FileReader.readAsBinaryString()、FileReader.readAsDataURL()、FileReader.readAsText()
对FileReader 对象调用其中某一种读取方法后，可使用 onloadstart、onprogress、onload、onabort、onerror 和 onloadend 跟踪其进度

具体步骤：
1、实例化FileReader对象
2、FileReader.readAsDataURL() 开始读取内容
2、事件处理，通过onload事件读取文件（注意，是个异步过程，如果想要拿到数据，需要注册回调事件callback）

我这里封装好了一个转换函数

function transferImgToBase64(files, cb) {
	// 先判断浏览器是否支持，一般都支持的啦，求个心安而已
  if (typeof FileReader === 'undefined') {
    alert('您的浏览器不支持图片上传，请升级您的浏览器');
    return false;
  }
	// 实例化实例化`FileReader`对象
  let reader = new FileReader();
	// 读取内容
  reader.readAsDataURL(files[0]);
	// 通过onload事件拿到文件，并注册一个回调事件cb，这个回调事件就是拿来上传文件、预览文件等等的操作，回调的参数就是处理好的base64格式文件
  reader.onload = e => {
    cb ? cb(e.target.result) : null;
  };
}

预览就比较简单了

$('#file1').change(e => {
  const files = e.target.files || e.dataTransfer.files;
  $('#img').attr('src', objectURL)
	// 这里的res就是传入的base64数据，上面的e.target.result
  transferImgToBase64(files, res => {
    console.log('转码后', res);
    $('#img').attr('src', res);
  });
});

在input上面放个空的img标签，通过DOM操作，用attr对src属性进行操作即可看到页面上的预览效果（样式就不写了）

<img id="img" src="">
<input id="file1" type="file">

最后一起看看效果

ObjectURL（一个实验中的功能，只能实现预览）

ObjectURL相当于文件的一个临时路径，此临时路径可随时生成、随时释放，在本地浏览器使用起来时，与普通的url无异

URL.createObjectURL() - Web API 接口 | MDN

// blog是用来创建 URL 的 File 对象或者 Blob 对象​
objectURL = URL.createObjectURL(blob);

在每次调用 createObjectURL() 方法时，都会创建一个新的 URL 对象，即使你已经用相同的对象作为参数创建过。当不再需要这些 URL 对象时，每个对象必须通过调用 URL.revokeObjectURL() 方法来释放。浏览器会在文档退出的时候自动释放它们，但是为了获得最佳性能和内存使用状况，你应该在安全的时机主动释放掉它们。

通过window.URL.createObjectURL(files[0])拿到URL对象，方式比FileReader更简单一点

$('#file1').change(e => {
  const files = e.target.files || e.dataTransfer.files;
  console.log('file1',files)
  const objectURL = window.URL.createObjectURL(files[0]);
  $('#img').attr('src', objectURL)
});

可以打印看下是什么格式的东西

console.log('objectURL',objectURL);

控制台可以看到如下输出

objectURL blob:null/bfefecc5-6c63-4465-84a2-8dc6c2ac48fd

直接赋值给图片的src属性，即可实现预览，但是，它没有事件处理钩子，实现不了上传进度等业务功能，也没有完成转换base64格式，但如果只是单纯的想要实现预览，倒也足够了。

另外，要记得在合适的时候释放浏览器记忆

window.URL.revokeObjectURL($('#img').src);

三、FormData上传文件

<span href="" class="uploadBtn">
	{{uploadText}}
	<input type="file" name='file' @change="onFileChange" class="file-input">
</span>

通过一个span把input隐藏起来，加以美化

.uploadBtn {
	position: relative;
	display: inline-block;
	width: 80px;
	text-align: center;
	line-height: 30px;
	border: 1px solid #e7e7eb;
	border-radius: 5px;
	padding: 2px 20px;
	color: #fff;
	background: #08cc6a;
	margin-right: 10px;
	&:hover {
		background: #07b35d;
	}
	input {
		position: absolute;
		left: 0;
		top: 0;
		width: 130px;
		height: 45px;
		opacity: 0;
		cursor: pointer;
	}
}

通过opacity: 0;把真正的input控件隐藏起来
然后让整个span的大小覆盖到input的范围大小

从丑丑的

变成了

上面的@change="onFileChange"是vue的写法，用jQuery的同学直接加个监听事件就好了

vm.sendRequest是我自己封装的网络请求方法，$.ajax()的方法也写在下面的注释中了

onFileChange(e) {
	const vm = this;
	const files = e.target.files || e.dataTransfer.files;
	let formData = new FormData();
	console.log('文件', files, files[0].name);
	formData.append(files[0].name, files[0]);
	// const settings = {
	// 	"async": true,
	// 	"crossDomain": true,
	// 	"url": "/shop/reseller/order/upload",
	// 	"method": "POST",
	// 	"headers": {
	// 		"Content-Type": "application/x-www-form-urlencoded",
	// 		"Cache-Control": "no-cache",
	// 		// "Postman-Token": "cd09edb9-13ea-e249-9efb-aa7d9027b441"
	// 	},
	// 	"processData": false,
	// 	"contentType": false,
	// 	"mimeType": "multipart/form-data",
	// 	"data": formData,
	// }
	// $.ajax(settings).done(function (response) {
	// 	console.log('看看回调',response);
	// });
	vm.uploadText = '上传中...';
	vm.sendRequest({
		url: `/shop/reseller/order/upload`,
		data: formData,
		success(d) {
		toast('文件上传成功', true);
			vm.uploadText = '上传订单';
			vm.wrap = true;
			vm.showResultBtn = true;
			vm.orderCheckResult = d.data;
			console.log('看看回调',d);
		},
		failed(err) {
				toast('文件上传失败', false);
				vm.uploadText = '上传订单';
		toast(err.cnmsg, false);
	}        
}); 
},

有几点要注意的

• processData: false设置为false，data值是FormData对象，不需要对数据做处理。
• mimeType: "multipart/form-data"，文件类型
• cache：false，上传文件不需要缓存
• contentType: false,上面已经注明了文件类型，而是是formdata对象

四、上传到七牛（网络请求，非表单）

直接上文档（相信很多同学都不会点开看，但我任性，就是要贴官方文档，原因不想说）
如何上传base64编码图片到七牛云 - 七牛开发者中心
FAQ 常见问题 - 七牛开发者中心

1、封装七牛上传方法

// key和token是向后端请求，后端向七牛请求回来的验证,七牛说：兄dei,拿好key和token，我帮你留了个坑，等会你上传文件的时候带上它们，我帮你把文件填坑里去
// 前端向七牛上传文件，带上key和token,说：牛哥，刚刚后端那兄弟帮我申请了个坑，就是这文件，你帮我存好哈
// 最后两个参数是成功与失败的回调
function uploadToQiniu(key, token, files, sucCB = () => {}, errCB = () => {}) {
	// 判断https还是http，encode64方法是把key进行Base64编码，自己可以查一下
	// 这个请求链接，上面两个链接中有，不然就找你们后端同学要
  const url =
  document.location.protocol === 'https:'
    ? `https://upload.qbox.me/putb64/-1/key/${encode64(key)}`
    : `http://upload.qbox.me/putb64/-1/key/${encode64(key)}`
  const header = {
    'Content-Type': 'application/x-www-form-urlencoded',
    Authorization: 'UpToken ' + token,
    Host: 'upload.qbox.me'
  };
	// 转换files到base64格式，跟上面的大同小异，区别看下面
  transferImgToBase64WithoutHead(files, (r) => {
    const body = r;
	  // fetch ，网络请求API，不会？同学，就此别过了😀
    fetch(url, {
      method: 'POST',
      headers: header,
      body: body
    })
      .then(res => {
		  // 上传成功后拿到回调，你自己定义的处理办法
        ...yourOwnMethod(res)
      })
  });
}

2、图片数据处理

注意，这个方法多了WithoutHead几个字母

export function transferImgToBase64WithoutHead(files, cb) {
  if (typeof FileReader === 'undefined') {
    alert('您的浏览器不支持图片上传，请升级您的浏览器');
    return false;
  }
  let reader = new FileReader();
  reader.readAsDataURL(files[0]);
  reader.onload = e => {
	  // 这里是唯一的区别，把转换后的base64编码的前面那一部分字符串去掉，参见下图，七牛只接受这样的格式作为body
    let result = e.target.result.replace(/^data:image\/\w+;base64,/, '');
    cb ? cb(result) : null;
  };
}

3、基本用法

function onFileChange(e) {
  // 如何生成预览图，相信不用再说了吧
	// 如何生成`files`，也不用我说了吧
  // `sendRequest`是我们自己封的请求API，向后端请求key和token
  this.sendRequest({
    url: '********',
    success(d) {
      vm.token = d.data.data.token;
      vm.key = d.data.data.key;
      vm.productAdd.preview = d.data.data.token;
      // 上传图片到七牛
      uploadToQiniu(
        d.data.data.key,
        d.data.data.token,
        files,
        res => {
          console.log('成功回调', res);
          toast('图片上传成功', true)
        },
        err => {
          console.log('失败回调', err);
          toast('图片上传失败',false)
        }
      );
    }
  });
}

五、文件分割

利用Blob的slice方法进行分割，大概思路如下：

1. 读入文件
2. 按固定size分片
3. 给每个片段加入id，blob的内容提取成base64，数据封装
4. 发送网络请求到后台（使用队列防止浏览器卡住）,
5. 后台收到后拼装（注意文件锁和顺序）

代码？
不存在的……延伸思考题
哈哈哈，我是不是很坑……
*年，自己动手，丰衣足食……

六、后记

感谢您耐心看到这里，希望有所收获！

如果不是很忙的话，麻烦右上角点个star⭐，举手之劳，却是对作者莫大的鼓励。

我在学习过程中喜欢做记录，分享的是自己在前端之路上的一些积累和思考，希望能跟大家一起交流与进步，更多文章请看【amandakelake的Github博客】

参考
前端本地文件操作与上传 – 人人网FED博客
阅读以 JavaScript 编写的本地文件 - HTML5 Rocks
【前端攻略】：玩转图片Base64编码 - ChokCoco - 博客园
基于JS的大文件分片 - CSDN博客

一、七种内置类型和常见引用类型

插个图，来自于《JavaScript语言精髓与编程实践》第三章P184页，后来想想有点多而杂，所以就自己画了些重点内容如上图，有需要的同学可以直接看下面这图

二、特殊的null

用typeof来检查上述七种类型时，返回的是对应的类型字符串值

但，有一个例外

typeof null === 'object' // true

null是唯一一个用typeof检测会返回object的基本类型值（注意‘基本’两字）

具体的原因，当面试官问到，可以这样吹一波

不同的对象在底层都表示为二进制
在JavaScript中二进制前三位为0的话都会被判断为object类型
null的二进制表示全是0，自然前三位也是0
所以 typeof null === “object”

三、引用类型的子类型：typeof [引用类型] === what ?

上面的图中虽然列出了七种引用类型，但是
typeof ‘引用类型’ === ‘object’ 一定成立吗？

不，还有一种情况：typeof ‘某些引用类型’ === ‘function’

还是先直接看一些测试吧，看下答案跟你预想的是不是一回事？
如果全都胸有成竹，那下面这一小节你可以跳过了

typeof Function; // 'function'
typeof new Function(); // 'function'
typeof function() {}; // 'function'

typeof Array; // 'function'
typeof Array(); // 'object'
typeof new Array(); // 'object'
typeof []; // 'object'

typeof Boolean; // "function"
typeof Boolean(); // "boolean"
typeof new Boolean(); // "object"

typeof Math; // 'object'
typeof Math(); // Math is not a function
typeof new Math(); // Math is not a constructor

1、引用类型中的函数

先看前三句，原来typeof除了能判断基本类型和object之外，还能判断function类型，函数也属于对象

2、引用类型的子类型

拿Array举例子

typeof Array; // 'function'
typeof Array(); // 'object'
typeof new Array(); // 'object'
typeof []; // 'object'

Array是个构造函数，所以直接打印出function
但构造出来的Array()却又是另一回事了，构造出来的结果是个数组，自然属于引用类型，所以也就打印出了‘object’

构造函数 Array(..) 不要求必须带 new 关键字。不带时，它会被自动补上。 因此 Array(1,2,3) 和 new Array(1,2,3) 的效果是一样的

3、引用类型中的基本包装类型

typeof Boolean; // "function"
typeof Boolean(); // "boolean"
typeof new Boolean(); // "object"

Boolean是个构造函数，第一句没问题
Boolean()直接执行，得出了布尔值，所以得到了‘boolean’

而new出来的是个Boolean对象，具体来说就是：通过构造函数创建出来的是封装了基本类型值的封装对象，好好理解一下这句话

这里用String来举个例子吧，看到了吗，一个封装对象

但是，这里不推荐使用这种封装对象，看个例子

var a = new Boolean(false);
if (!a) {
  console.log('Oops'); // 执行不到这里
}

a是个对象，对象永远是真，所以……你懂了

个人建议不要轻易去碰包装类型，日常开发直接用字面量就好了（大牛自动忽略这段话）

4、Math到底是什么？

Math和Global（浏览器中替代为window）都是内置的对象，并不是引用类型的一种

typeof Math; // 'object'
typeof Math(); // Math is not a function
typeof new Math(); // Math is not a constructor

不是函数，不是构造器，这个应该能理解了吧。

四、typeof的安全防范机制

首先，我们需要知道underfined和undeclared的区别
未定义与未声明

但是，对于typeof来说，这两者都一样，返回的都是underfined

var a;
typeof a; // 'underfined'
typeof b; // 'underfined'

很明显，我们知道b就是undeclared（未声明的），但在typeof看来都是一样

这个特性，可以拿来做些什么呢？

举个简单的例子，在程序中使用全局变量 DEBUG 作为“调试模式”的开关。在输出调试信 息到控制台之前，我们会检查 DEBUG 变量是否已被声明。顶层的全局变量声明 var DEBUG = true 只在 debug.js 文件中才有，而该文件只在开发和测试时才被加载到浏览器，在生产环 境中不予加载。

问题是如何在程序中检查全局变量 DEBUG 才不会出现 ReferenceError 错误。这时 typeof 的 安全防范机制就成了我们的好帮手:

// 这样会抛出错误
if (DEBUG) {
  console.log('Debugging is starting');
}
// 这样是安全的
if (typeof DEBUG !== 'undefined') {
  console.log('Debugging is starting');
}

这不仅对用户定义的变量(比如 DEBUG)有用，对内建的 API 也有帮助:

if (typeof atob === "undefined") {
         atob = function() { /*..*/ };
}

这样的安全防范机制在各式源码中非常常见，可见，大作们早已经把一些基础的东西弄得非常透彻并运用到实践中，所以说，看源码是我们快速提高的一个方式，应该错不了。

五、值

这一part引用自一、内存空间详解 · Sample GitBook

JS的执行上下文生成之后，会创建一个叫做变量对象的特殊对象（关于变量对象在我的其他文章中有讲到），JS的基础类型都保存在变量对象中

严格意义上来说，变量对象也是存放于堆内存中，但是由于变量对象的特殊职能，我们在理解时仍然需要将其于堆内存区分开来。

但引用数据类型的值是保存在堆内存中的对象。JavaScript不允许直接访问堆内存中的位置，因此我们不能直接操作对象的堆内存空间。
在操作对象时，实际上是在操作对象的引用而不是实际的对象。因此，引用类型的值都是按引用访问的。
这里的引用，我们可以理解为保存在变量对象中的一个地址，该地址与堆内存的实际值相关联。

看到这里，应该就能比较好的理解引用传参的相关问题了，这属于延伸思考，google去吧，学会自我思考和搜索也是一种技能。

六、强制类型转换

《you don’t know JS》中 第一部分第4章

类型转换发生在静态类型语言的编译阶段，而强制类型转换则发生在动态类型语言的运行时(runtime)。

然而在 JavaScript 中通常将它们统称为强制类型转换，我个人则倾向于用“隐式强制类型转换”(implicit coercion)和“显式强制类型转换”(explicit coercion)来区分。

1、抽象值操作

介绍显式和隐式强制类型转换之前，我们需要先掌握字符串、数字和布尔值之间类型转换的基本规则

1️⃣ToString
toString() 可以被显式调用，或者在需要字符串化时自动调用

null 转换为 "null"，undefined 转换为 "undefined"，true 转换为 "true"。
数字的字符串化则遵循通用规则
极小和极大的 数字使用指数形式:

// 1.07 连续乘以七个 1000
var a = 1.07 * 1000 * 1000 * 1000 * 1000 * 1000 * 1000 * 1000;
// 七个1000一共21位数字 
a.toString(); // "1.07e21"

数组的默认 toString() 方法经过了重新定义，将所有单元字符串化以后再用 "," 连接起 来

var a = [1,2,3];
 a.toString(); // "1,2,3"

2️⃣ ToNumber
其中 true 转换为 1，false 转换为 0。undefined 转换为 NaN，null 转换为 0。
处理失败 时返回 NaN(处理数字常量失败时会产生语法错误)

3️⃣ ToBoolean
先看什么是假值

• undefined
• null
• false
• +0、-0 和 NaN
• ""

假值的布尔强制类型转换结果为 false。
从逻辑上说，假值列表以外的都应该是真值(truthy)

再看下假值对象（这东西太有意思了😂）
不是说规定所有的对象都是真值，怎么还会有假值对象呢？

var a = new Boolean(false);
var b = new Number(0);
var c = new String('');

var d1 = Boolean( a && b && c );
var d2 = a && b && c;

看看d1和d2有什么不同？是不是特有意思？

如果假值对象并非封装了假值的对象，那它究竟是什么?
值得注意的是，虽然 JavaScript 代码中会出现假值对象，但它实际上并不属于 JavaScript 语 言的范畴。
浏览器在某些特定情况下，在常规 JavaScript 语法基础上自己创建了一些外来(exotic) 值，这些就是“假值对象”。
假值对象看起来和普通对象并无二致(都有属性，等等)，但将它们强制类型转换为布尔 值时结果为 false。

最后再看真值是什么
真值就是假值列表之外的值
再来看一段有意思的代码

var a = 'false';
var b = '0';
var c = "''";
var d1 = Boolean(a && b && c);
var d2 = a && b && c

到目前为止，我们得出的一个结论是：[]、{} 和 function(){} 都不在假值列表中，因此它们都 是真值

看几个常用的吧

var a = "0";
var b = [];
var c = {};
var d = "";
var e = 0;
var f = null;
var g;
Boolean( a ); // true  特别注意这个，字符串0和空字符串不一样
Boolean( b ); // true
Boolean( c ); // true
Boolean( d ); // false  和第一个比，空字符串是false
Boolean( e ); // false
Boolean( f ); // false
Boolean( g ); // false

那是不是记住假值，就知道哪些是真值了？
理论上是的……
那实际上是什么？
真正掌握类型转换！

2、显式类型转换

这个其实很好理解

// 字符串转换
var a = 42;
var b = String(a);
// 数字转换
var c = '3.14';
var d = Number(c);
// 布尔值转换
var e = [];
var f = Boolean(e)

3、隐式强制类型转换

1️⃣字符串和数字之间的隐式转换
多的不谈了，简单来说就是，如果 + 的其中一个操作数是字符串(或者通过以上步骤可以得到字符串)， 则执行字符串拼接;否则执行数字加法。

var a = '42';
var b = '0';
var c = 42;
var d = 0;
a + b; // "420" 这个地方，注意一下
c + d; // 42

有个小坑，可以当做程序员饭后趣谈

console.log([] + {}); // [object object]
console.log({} + []); // ?这会是多少呢？

《you don’t know JS 》中5.1.3章节是这样说的

还有一个坑常被提到(涉及强制类型转换，参见第 4 章)
[] + {}; // "[object Object]"
{} + []; // 0
表面上看 + 运算符根据第一个操作数([] 或 {})的不同会产生不同的结果，实则不然。 第一行代码中，{} 出现在 + 运算符表达式中，因此它被当作一个值(空对象)来处理。第
4 章讲过 [] 会被强制类型转换为 ""，而 {} 会被强制类型转换为 "[object Object]"。
但在第二行代码中，{} 被当作一个独立的空代码块(不执行任何操作)。代码块结尾不需 要分号，所以这里不存在语法上的问题。最后 + [] 将 [] 显式强制类型转换(参见第 4 章) 为 0。

但目前的chrome浏览器控制台是这样的

对此，你怎么看？😏

{} 其实应该当成一个代码块，而不是一个 Object，当你在console.log使用的时候，{} 被当成了一个 Object

这下是不是印象更深刻了？

2️⃣ 隐式强制类型转换为布尔值
下面的情况会发生 布尔值隐式强制类型转换。

• (1)if (..)语句中的条件判断表达式。
• (2)for ( .. ; .. ; .. )语句中的条件判断表达式(第二个)。
• (3) while (..) 和 do..while(..) 循环中的条件判断表达式。
• (4)? :中的条件判断表达式。
• (5) 逻辑运算符 ||(逻辑或)和 &&(逻辑与)左边的操作数(作为条件判断表达式)。

3️⃣ || 与 &&
就一句话，理解了就**，称之为“操作数选择器”

a || b;
// 大致相当于(roughly equivalent to): a ? a : b;
a && b;
// 大致相当于(roughly equivalent to): a ? b : a;

只选择其中一个

4、== 与 ===

常见的误区是“== 检查值是否相等，=== 检查值和类型是否相等”
正确的解释是:“== 允许在相等比较中进行强制类型转换，而 === 不允许。”

两个完全截然不同的理解方向，果然，看书还是要看权威的书好

这一段，看完后我只想总结一句，放弃 == ，拥抱 ===，其他的不谈了

高度100px，左右各宽100px，中间部分可自适应宽度

浮动布局

<div class="float">
	<div class="left">left</div>
	<div class="right">right</div>
	<div class="main">浮动</div>
</div>

.float {
    .left {
        height: 100px;
        background-color: #e65;
        width: 100px;
        float: left;
    }
    .right {
        height: 100px;
        background-color: #ccc;
        width: 100px;
        float: right;
    }
    .main {
        // 不能给宽度
        height: 100px;
        background-color: bisque;
        margin: 0 100px;
    }
}

绝对定位

<div class="position">
  <div class="left">left</div>
  <div class="right">right</div>
  <div class="main">绝对定位</div>
</div>

.position {
    margin: 10px 0;
    position: relative;
    .left {
        height: 100px;
        background-color: #e65;
        width: 100px;
        position: absolute;
        left: 0;
    }
    .right {
        height: 100px;
        background-color: #ccc;
        width: 100px;
        position: absolute;
        right: 0;
    }
    .main {
        // padding或者margin都可以
        margin: 0 100px;
        height: 100px;
        background-color: bisque;
    }
}

BFC

<div class="BFC">
  <div class="left">left</div>
  <div class="right">right</div>
  <div class="main">BFC</div>
</div>

.BFC {
    margin: 10px 0;
    .left {
        height: 100px;
        background-color: #e65;
        width: 100px;
        float: left;
    }
    .right {
        height: 100px;
        background-color: #ccc;
        width: 100px;
        float: right
    }
    .main {
        height: 100px;
        background-color: bisque; // 触发BFC
        overflow: hidden;
    }
}

flex

<div class="flexBox">
  <div class="left">left</div>
  <div class="main">flexBox</div>
  <div class="right">right</div>
</div>

.flexBox {
    margin: 10px 0;
    display: flex;
    .left {
        height: 100px;
        background-color: #e65;
        width: 100px;
    }
    .main {
        flex: 1;
        height: 100px;
        background-color: bisque;
    }
    .right {
        height: 100px;
        background-color: #ccc;
        width: 100px;
    }
}

table

<div class="tableCell">
  <div class="left">left</div>
  <div class="main">tableCell</div>
  <div class="right">right</div>
</div>

.tableCell {
    margin: 10px 0; // 要设置父元素宽度
    width: 100%;
    display: table; // 每一个子元素都要设置display:table-cell
    .left {
        height: 100px;
        background-color: #e65;
        width: 100px;
        display: table-cell;
    }
    .main {
        height: 100px;
        background-color: bisque;
        display: table-cell;
        width: auto
    }
    .right {
        height: 100px;
        background-color: #ccc;
        width: 100px;
        display: table-cell;
    }
}

网格grid

<div class="grid">
  <div class="left">left</div>
  <div class="main">grid</div>
  <div class="right">right</div>
</div>

.grid {
    margin: 10px 0; // 只需要父元素设置即可
    display: grid;
    grid-template-rows: 100px;
    grid-template-columns: 100px auto 100px;
    .left {
        height: 100px;
        background-color: #e65;
        width: 100px;
    }
    .main {
        height: 100px;
        background-color: bisque;
        width: auto
    }
    .right {
        height: 100px;
        background-color: #ccc;
        width: 100px;
    }
}

双飞翼

<div class="doubleFly">
  <div class="container">
    <div class="main">doubleFly</div>
  </div>
  <div class="left">left</div>
  <div class="right">right</div>
</div>

.doubleFly {
    margin: 10px 0; // 此处 ，缩进了100px的高度
    margin-bottom: 120px;
    .container {
        width: 100%; // 全都是浮动
        float: left;
        .main {
            // 空出两边间隔
            margin: 0 100px;
            height: 100px;
            background-color: bisque;
        }
    }
    .left {
        float: left; // 关键地方，这个100是整个父元素的宽度
        margin-left: -100%;
        height: 100px;
        background-color: #e65;
        width: 100px;
    }
    .right {
        float: right; // 关键地方
        margin-left: -100px;
        height: 100px;
        background-color: #ccc;
        width: 100px;
    }
}

圣杯

<div class="hollyCup">
  <div class="main">hollyCup</div>
  <div class="left">left</div>
  <div class="right">right</div>
</div>

.hollyCup {
    // 父元素也需要两边空出100px
    margin: 10px 100px;
    .main {
        float: left;
        width: 100%;
        height: 100px;
        background-color: bisque;
    }
    .left {
        float: left;
        margin-left: -100%;
        position: relative;
        left: -100px;
        height: 100px;
        background-color: #e65;
        width: 100px;
    }
    .right {
        float: left;
        margin-left: -100px;
        position: relative;
        right: -100px;
        height: 100px;
        background-color: #ccc;
        width: 100px;
    }
}

提升思考

• 这五种方案各自的优缺点？
  浮动：脱离文档流，需要清除浮动；但兼容性比较好
  绝对定位：快；但是需要处理下面元素的位置
  Flex：目前比较完美的方案，特别是移动端
  表格布局：有历史上的问题（不深究），会同时增高
  网格布局：新技术，比较潮一点（这能展示学习能力）

• 如果高度也要考虑呢，或者去掉高度呢？
  目前只有flex、table布局是自适应的

• 这五种方案的兼容性，目前业务中的最优解？

function Foo() {
    getName = function () { alert (1); };
    return this;
}
Foo.getName = function () { alert (2);};
Foo.prototype.getName = function () { alert (3);};
var getName = function () { alert (4);};
function getName() { alert (5);}

//请写出以下输出结果：
Foo.getName();
getName();
Foo().getName();
getName();
new Foo.getName();
new Foo().getName();
new new Foo().getName();

function Foo() {
  getName = function () { alert (1); };
  return this;
} 
// 为Foo创建了一个叫getName的静态属性存储了一个匿名函数
Foo.getName = function () { alert (2);};
// 为Foo的原型对象新创建了一个叫getName的匿名函数
Foo.prototype.getName = function () { alert (3);};
// 通过函数变量表达式创建了一个getName的函数
var getName = function () { alert (4);};
// 通过函数声明一个getName函数，注意提升，所以getName最后应该是上一行的4
function getName() { alert (5);}//提升

//请写出以下输出结果：
Foo.getName(); //2    Foo上面的静态属性
getName(); // 4  当前上文作用域内的叫getName的函数，所以跟1 2 3都没什么关系，但函数声明被提升了  所以函数表达式在后
Foo().getName(); // 1
// Foo函数的第一句  getName = function () { alert (1); };  是一句函数赋值语句，注意它没有var声明
// 所以先向当前Foo函数作用域内寻找getName变量，没有。再向当前函数作用域上层，找到了，这时候是4，然后赋值为1
// 此处实际上是将外层作用域内的getName函数修改了
// 此处若依然没有找到会一直向上查找到window对象，若window对象中也没有getName属性，就在window对象中创建一个getName变量
// 此时，Foo返回了this，如果函数独立调用，那么严格模式下该函数内部的this，则指向undefined，现在是非严格模式，所以指向window
// Foo函数返回的是window对象，相当于执行 window.getName() ，而window中的getName已经被修改为alert(1)，
getName(); // 与上一问相同，已经被改为1了
new Foo.getName(); //2
// 这里考察运算符优先级
// 圆括号 > (成员访问.号 > new) > 函数调用 > 其他（具体再看）
// 这里成员访问.号优先级高于new   相当于  new (Foo.getName)()  相当于将getName()函数当做构造函数，这个构造函数现在是foo的静态属性2
new Foo().getName(); //3
// 相当于  (new Foo()).getName()
// 这里构造函数Foo返回了实例化的对象，然后去原型对象中找到的getName， （Foo.prototype.getName = function () { alert (3);};）
new new Foo().getName(); // 3
// new ((new Foo()).getName)();
// 先初始化Foo的实例化对象，然后将其原型上的getName函数作为构造函数再次new。

构造函数的返回值

构造函数可以有返回值也可以没有

• 没有返回值则按照其他语言一样返回实例化对象。
• 若有返回值则检查其返回值是否为引用类型。如果是非引用类型，如基本类型（string,number,boolean,null,undefined）则与无返回值相同，实际返回其实例化对象。
• 若返回值是引用类型，则实际返回值为这个引用类型。

如果返回this，而this在构造函数中本来就代表当前实例化对象，遂最终Foo函数返回实例化对象

一、Generator基础认知

最基础的原则就是见到yield就暂停，next()就继续到下一个yield……以此知道函数执行完毕。

先不上理论，直接看一段代码，这里的step()是一个辅助函数，用来控制迭代器，替代手动next()

var a = 1;
var b = 2;
function* foo() {
  a++;
  yield;
  b = b * a;
  a = (yield b) + 3;
}
function* bar() {
  b--;
  yield;
  a = (yield 8) + b;
  b = a * (yield 2);
}
function step(gen) {
  var it = gen();
  var last;
  return function() {
    // 不管yield出来的是什么，下一次都把它原样传回去!
    last = it.next(last).value;
  };
}

a = 1;
b = 2;

var s1 = step(foo);
var s2 = step(bar);

yield和next()调用有一个不匹配，就是说，想要完整跑完一个生成器函数，next()调用总是比yield的数量多一次

为什么会有这个不匹配?
因为第一个 next(..) 总是启动一个生成器，并运行到第一个 yield 处。不过，是第二个 next(..) 调用完成第一个被暂停的 yield 表达式，第三个 next(..) 调用完成第二个 yield， 以此类推。

所以上面的代码中，foo有两个yield，bar有三个yield
所以接下来要跑三次s1()，四次s2()
我们在控制台看每一步的输出，一步一步来分析

分析到这里，对generator的基础工作原理应该就有了大概的认知了。

如果想加深一点理解（皮一下），可以随意调换一下s1和s2的执行顺序，总之就是三个s1和四个s2，对于理解多个生成器如何在共享的作用域上并 发运行也有指导意义。

二、异步迭代生成器

这一段，我们来理解一下生成器与异步编程之间的问题，最直接的就是网络请求了

let data = ajax(url);
console.log(data)

这段代码，大家都知道不能正常工作吧，data是underfined
ajax是一个异步操作，它并没有停下来等到拿到数据之后再赋值给data
而是在发出请求之后，直接就执行了下一句console

既然知道了问题核心在于“没有停下来”
那刚好生成器又有“yield”停下来这个操作，那么二者是不是刚好合拍了呢

看一段代码

function foo() {
  ajax(url, (err, data) => {
    if (err) {
      // 向*main()抛出一个错误 it.throw( err );
    } else {
      // 用收到的data恢复*main()
      it.next(data);
    }
  });
}

function* main() {
  try {
    let data = yield foo();
    console.log(data);
  } catch (err) {
    console.error(err);
  }
}

这段代码使用了生成器，其实跟上一段代码干的是一样的事情，虽然更长更复杂，但实际上更好用，具体原因慢慢分析

两段代码的核心区别在于生成器中使用了yield

在yield foo()的时候，调用了foo()，没有返回值（underfined），所以发出了一个ajax请求，虽然依然是yield underfined，但是没关系，因为这段代码不依赖yield的值来做什么事情，大不了就打印underfined嘛对不对

这里并不是在消息传递的意义上使用 yield，而只是将其用于流程控制实现暂停 / 阻塞。实 际上，它还是会有消息传递，但只是生成器恢复运行之后的单向消息传递。

所以，生成器在 yield 处暂停，本质上是在提出一个问题:“我应该返回什么值来赋给变量 data ?”谁来回答这个问题呢?

看foo，如果ajax请求成功，调用

it.next( data )

会用响应数据恢复生成器，意味着我们暂停的 yield 表达式直接接收到了这个值。然后 随着生成器代码继续运行，这个值被赋给局部变量 data

在生成器内部有了看似完全同步的代码
(除了 yield 关键字本身)，但隐藏在背后的是，在 foo(..) 内的运行可以完全异步

这一部分对于理解生成器与异步编程之间扎下了最核心的内容，万望深刻理解为什么

三、Generator+Promise处理并发流程与优化

接下来来点高级货吧，总不能一直停留在理论上

request是假设封装好的基于Promise的实现方法
run也是假设封装好的能实现重复迭代的驱动Promise链的方法

function *foo() {
  let r1 = yield request(url1);
  let r2 = yield request(url2);

  let r3 = yield request(`${url3}/${r1}/${r2}`);

  console.log(r3)
}
run(foo)

这段代码里，r3是依赖于r1和r2的，同时r1和r2是串行的，但这两个请求是相对独立的，那是不是应该考虑并发执行呢？
但yield 只是代码中一个单独 的暂停点，并不可能同时在两个点上暂停

这样试一下

function *foo() {
  let p1 = request(url1);
  let p2 = request(url2);

  let r1 = yield p1;
  let r2 = yield p2;

  let r3 = yield request(`${url3}/${r1}/${r2}`);

  console.log(r3)
}
run(foo)

看一下yield的位置，p1和p2是并发同时执行的用于 Ajax 请求的 promise，哪一个先完成都无所谓，因为 promise 会按照需要 在决议状态保持任意长时间

然后使用接下来的两个 yield 语句等待并取得 promise 的决议(分别写入 r1 和 r2)。
如果p1先决议，那么yield p1就会先恢复执行，然后等待yield p2恢复。
如果p2先决 议，它就会耐心保持其决议值等待请求，但是 yield p1 将会先等待，直到 p1 决议。
不管哪种情况，p1 和 p2 都会并发执行，无论完成顺序如何，两者都要全部完成，然后才 会发出 r3 = yield request..Ajax 请求。

这种流程控制模型和Promise.all([ .. ]) 工具实现的 gate 模式相同

function *foo() {
  let rs = yield Promise.all([
    request(url1),
    request(url2)
  ]);

  let r1 = rs[0];
  let r2 = rs[1];

  let r3 = yield request(`${url3}/${r1}/${r2}`);
  console.log(r3)
}
run(foo)

四、抽象异步Promise流，简化生成器

到目前位置，Promise都是直接暴露在生成器内部的，但生成器实现异步的要点在于：创建简单、顺序、看似同步的代码，将异步的 细节尽可能隐藏起来。

能不能考虑一下把多余的信息都藏起来，特别是看起来比较复杂的Promise代码呢？

function bar(url1, url2) {
  return Promise.all([request(url1), request(url2)]);
}

function* foo() {
  // 隐藏bar(..)内部基于Promise的并发细节
  let rs = yield bar(url1, url2);
  let r1 = rs[0];
  let r2 = rs[1];

  let r3 = yield request(`${url3}/${r1}/${r2}`);
  console.log(r3);
}
run(foo);

把Promise的实现细节都封装在bar里面，对bar的要求就是给我们一下rs结果而已，我们也不需要关系底层是用什么来实现的

异步，实际上是把Promise，作为一个实现细节看待。

具体到实际生产中，一系列的异步流程控制有可能就是下面的实现方式

function bar() {
  Promise.all([
    bax(...).then(...),
    Promise.race([...])
  ])
  .then(...)
}

这些代码可能非常复杂，如果把实现直接放到生成器内部的话，那几乎就失去了使用生成器的理由了
好好记一下这句话：创建简单、顺序、看似同步的代码，将异步的 细节尽可能隐藏起来。

网上关于缓存的文章非常多，但大都比较片面，或者只对某块进行了深入，没有把它们联系起来，本着系统学习的态度，笔者进行了整理，写成一个小系列，方便自己也方便他人共同学习，有写的不对的地方欢迎指正。
缓存（一）——缓存总览：从性能优化的角度看缓存
缓存（二）——浏览器缓存机制：强缓存、协商缓存
缓存（三）——数据存储：cookie、Storage、indexedDB
缓存（四）——离线应用缓存：App Cache => Manifest
缓存（五）——离线应用缓存：Service Worker(还没写，先占坑)

请注意：该特性已经从 Web 标准中删除，本文只是作为了解所用

Manifest 是 H5提供的一种应用缓存机制, 基于它web应用可以实现离线访问(offline cache)
浏览器还提供了应用缓存的API：applicationCache

一、基础与流程

manifest是一个后缀名为minifest的文件，在文件中定义那些需要缓存的文件，支持manifest的浏览器将会按照manifest文件的规则，像文件保存在本地，从而在没有网络链接的情况下，也能访问页面。

当第一次正确配置app cache后，再次访问该应用时，浏览器会首先检查manifest文件是否有变动，如果有变动就会把相应的变得更新下来，同时改变浏览器里面的app cache，如果没有变动，就会直接把app cache的资源返回，基本流程如下：

二、使用

1、html文件指定manifest配置

在html标签中指定manifest文件, 便表示该网页使用manifest进行离线缓存.
该网页内需要缓存的文件列表需要在 demo.appcache 文本文件中指定.

<!DOCTYPE HTML>
<html manifest="demo.appcache">
...
</html>

2、manifest缓存清单

首行必须以CACHE MANIFEST开头，标准的三段式

// 需要缓存的文件，无论是否有网络连接，都从缓存读取
CACHE MANIFEST
/theme.css
/logo.gif
/main.js

// 文件 "login.asp" 永远不会被缓存，且离线时是不可用的
NETWORK:
login.asp

// 如果无法建立因特网连接，则用 "offline.html" 替代 /html5/ 目录中的所有文件
FALLBACK:
/html5/ /404.html

三、更新缓存

1、更新manifest文件
2、通过javascript操作

window.applicationCache.update();

3、清除浏览器缓存

四、关于它被废除的一些评论

• 即使在线，文件总是从 AppCache 中来
• 只有 Manifest 变化时文件才会更新，一旦变化总会更新所有文件
• 不支持 conditional download，破坏响应式设计
• 失败的 fallback 页面，无法区分网络错误和状态码
• 重定向被处理为访问失败

后记

感谢您耐心看到这里，希望有所收获！

如果不是很忙的话，麻烦点个star⭐【Github博客传送门】，举手之劳，却是对作者莫大的鼓励。

我在学习过程中喜欢做记录，分享的是自己在前端之路上的一些积累和思考，希望能跟大家一起交流与进步，更多文章请看【amandakelake的Github博客】

变量对象（理解提升很有作用）

#前端/Javascript/个人理解总结

执行上下文

当前栈顶的执行上下文包括了：变量对象、作用域链、this

执行上下文的生命周期

当一个函数被激活时，一个新的执行上下文就会被创建（这个执行上下文在栈顶），一个执行上下文的生命周期分为两个阶段
1、创建阶段：在这个阶段中，执行上下文会分别创建变量对象，建立作用域链，以及确定this的指向
2、代码执行阶段： 变量赋值，函数引用、以及执行其他代码

创建变量对象VO：Variable Object

• 1、建立arguments对象
  当前上下文中的参数，建立该对象下的属性与属性值
• 2、检查当前上下文的函数声明（这就是为什么函数是一等公民）
  使用function关键字声明的函数。在变量对象中以函数名建立一个属性，属性值为指向该函数所在内存地址的引用。如果函数名的属性已经存在，那么该属性将会被新的引用所覆盖。
  这里要清楚理解，函数声明才会被提升，函数表达式不会被提升，函数表达式就相当于变量声明
• 3、检查当前上下文中的变量声明
  每找到一个变量声明，就在变量对象中以变量名建立一个属性，属性值为undefined。如果该变量名的属性已经存在，为了防止同名的函数被修改为undefined，则会直接跳过，原属性值不会被修改。
  也就是同一个执行上下文中，变量对象是唯一的，但有可能在下个阶段（代码执行阶段）被修改赋值

创建阶段（注意函数的引用覆盖、变量的跳过）

VO = {
  arguments: {...},
  foo: <foo reference>, //这个地方，优先函数声明，碰到变量foo不会被覆盖，因为var声明的变量当遇到同名的属性时，会跳过而不会覆盖
  bar: underfined //虽然bar是函数表达式，但也只当做变量来处理
}

执行阶段（变量对象 => 活动对象，赋值和引用，碰到相同的属性名会无条件覆盖）

VO => AO 
VO = {
  arguments: {...},
  foo: 'Hello', //要理解这里为什么是变量，而不再是函数了，因为在执行阶段会按顺序进行赋值或者引用
  bar: <bar reference>,
  this: Window
}

预编辑

function test() {
	//创建变量对象阶段
  var foo; 
  //一等公民函数，优先声明，并指向函数的引用地址
  // foo => function foo() {
  //   return 'hello';
  // }
  var bar : underfined

	// 代码执行阶段:变量赋值，函数引用, 全部按照顺序来
	console.log(foo); //函数引用
	console.log(bar); // underfined
	// 这里按顺序执行到这里，重新给变量foo赋值
	foo = 'Hello';
	console.log(foo); // 'Hello'
	bar = function () {
    return 'world';
  }
}

再看一个例子

function testOrder(arg) {
    console.log(arg); // arg是形参，不会被重新定义
    console.log(a); // 因为函数声明比变量声明优先级高，所以这里a是函数
    var arg = 'hello'; // var arg;变量声明被忽略， arg = 'hello'被执行
    var a = 10; // var a;被忽视; a = 10被执行，a变成number
    function a() {
        console.log('fun');
    } // 被提升到作用域顶部
    console.log(a); // 输出10
    console.log(arg); // 输出hello
}; 
testOrder('hi');