关于javascript:重学-JavaScript-作用域和闭包

一、了解 JavaScript 的作用域、作用域链和外部原理

1.1 作用域

javascript 领有一套设计良好的规定来存储变量，并且之后能够不便地找到这些变量，这套规定被称为 作用域。

作用域就是代码的执行环境，全局执行环境就是全局作用域，函数的执行环境就是公有作用域，它们都是栈内存。

1.2 作用域链

当代码在一个环境中执行时，会创立变量对象的一个作用域链（作用域造成的链条）, 因为变量的查找是沿着作用域链来实现的，所以也称 作用域链 为变量查找的机制。

• 作用域链的前端，始终都是以后执行的代码所在环境的变量对象
• 作用域链中的下一个对象来自于外部环境，而在下一个变量对象则来自下一个外部环境，始终到全局执行环境
• 全局执行环境的变量对象始终都是作用域链上的最初一个对象

外部环境能够通过作用域链拜访所有外部环境，但外部环境不能拜访外部环境的任何变量和函数。

1.3 外部原理

• 编译

  以 var a = 2; 为例，阐明 javascript 的外部编译过程，次要包含以下三步：

  • 分词(tokenizing)

    把由字符组成的字符串分解成有意义的代码块，这些代码块被称为词法单元(token)

    var a = 2; 被合成成为上面这些词法单元：var、a、=、2、;。这些词法单元组成了一个词法单元流数组

    [
      "var": "keyword",
      "a": "identifier",
      "=": "assignment",
      "2": "integer",
      ";": "eos" (end of statement)
    ]

  • 解析(parsing)

    把词法单元流数组转换成一个由元素逐级嵌套所组成的代表程序语法结构的树，这个树被称为“形象语法树”(Abstract Syntax Tree, AST)

    var a = 2; 的形象语法树中有一个叫 VariableDeclaration 的顶级节点，接下来是一个叫 Identifier(它的值是 a)的子节点，以及一个叫 AssignmentExpression 的子节点，且该节点有一个叫 Numericliteral(它的值是 2)的子节点

    {
      operation: "=",
      left: {
        keyword: "var",
        right: "a"
      }
      right: "2"
    }

  • 代码生成

    将 AST 转换为可执行代码的过程被称为代码生成

    var a=2; 的形象语法树转为一组机器指令，用来创立一个叫作 a 的变量(包含分配内存等)，并将值 2 贮存在 a 中

    实际上，javascript 引擎的编译过程要简单得多，包含大量优化操作，下面的三个步骤是编译过程的根本概述

    任何代码片段在执行前都要进行编译，大部分状况下编译产生在代码执行前的几微秒。javascript 编译器首先会对 var a=2; 这段程序进行编译，而后做好执行它的筹备，并且通常马上就会执行它

• 执行

  简而言之，编译过程就是编译器把程序分解成词法单元(token)，而后把词法单元解析成语法树(AST)，再把语法树变成机器指令期待执行的过程

  实际上，代码进行编译，还要执行。上面依然以 var a = 2; 为例，深刻阐明编译和执行过程

  • 编译

    • 编译器查找作用域是否曾经有一个名称为 a 的变量存在于同一个作用域的汇合中。如果是，编译器会疏忽该申明，持续进行编译；否则它会要求作用域在以后作用域的汇合中申明一个新的变量，并命名为 a
    • 编译器将 var a = 2; 这个代码片段编译成用于执行的机器指令

    根据编译器的编译原理，javascript 中的反复申明是非法的

    // test 在作用域中首次呈现，所以申明新变量，并将 20 赋值给 test
    var test = 20
    // test 在作用域中曾经存在，间接应用，将 20 的赋值替换成 30
    var test = 30

  • 执行

    • 引擎运行时会首先查问作用域，在以后的作用域汇合中是否存在一个叫作 a 的变量。如果是，引擎就会应用这个变量；如果否，引擎会持续查找该变量
    • 如果引擎最终找到了变量 a，就会将 2 赋值给它。否则引擎会抛出一个异样

• 查问

  在引擎执行的第一步操作中，对变量 a 进行了查问，这种查问叫做 LHS 查问。实际上，引擎查问共分为两种：LHS 查问和 RHS 查问

  从字面意思去了解，当变量呈现在赋值操作的左侧时进行 LHS 查问，呈现在右侧时进行 RHS 查问

  更精确地讲，RHS 查问与简略地查找某个变量的值没什么区别，而 LHS 查问则是试图找到变量的容器自身，从而能够对其赋值

  function foo(a) {console.log(a) // 2
  }
  foo(2)

  这段代码中，总共包含 4 个查问，别离是：

  1、foo(…)对 foo 进行了 RHS 援用

  2、函数传参 a = 2 对 a 进行了 LHS 援用

  3、console.log(…)对 console 对象进行了 RHS 援用，并查看其是否有一个 log 的办法

  4、console.log(a)对 a 进行了 RHS 援用，并把失去的值传给了 console.log(…)

• 嵌套

  在以后作用域中无奈找到某个变量时，引擎就会在外层嵌套的作用域中持续查找，直到找到该变量，或到达最外层的作用域（也就是全局作用域）为止

  function foo(a) {console.log(a + b)
  }
  var b = 2
  foo(2) // 4

  行 RHS 援用，没有找到；接着，引擎在全局作用域中查找 b，胜利找到后，对其进行 RHS 援用，将 2 赋值给 b

• 异样

  为什么辨别 LHS 和 RHS 是一件重要的事件？因为在变量还没有申明（在任何作用域中都无奈找到变量）的状况下，这两种查问的行为不一样

  • RHS

    • 如果 RHS 查问失败，引擎会抛出 ReferenceError(援用谬误)异样

    // 对 b 进行 RHS 查问时，无奈找到该变量。也就是说，这是一个“未声明”的变量
    function foo(a) {a = b}
    foo() // ReferenceError: b is not defined

    • 如果 RHS 查问找到了一个变量，但尝试对变量的值进行不合理操作，比方对一个非函数类型值进行函数调用，或者援用 null 或 undefined 中的属性，引擎会抛出另外一种类型异样：TypeError(类型谬误)异样

    function foo() {
      var b = 0
      b()}
    foo() // TypeError: b is not a function

  • LHS

    • 当引擎执行 LHS 查问时，如果无奈找到变量，全局作用域会创立一个具备该名称的变量，并将其返还给引擎

    function foo() {a = 1}
    foo()
    console.log(a) // 1

    • 如果在严格模式中 LHS 查问失败时，并不会创立并返回一个全局变量，引擎会抛出同 RHS 查问失败时相似的 ReferenceError 异样

    function foo() {
      'use strict'
      a = 1
    }
    foo()
    console.log(a) // ReferenceError: a is not defined

• 原理

  function foo(a) {console.log(a)
  }
  foo(2)

  以下面这个代码片段来阐明作用域的外部原理，分为以下几步：

  【1】引擎须要为 foo(…)函数进行 RHS 援用，在全局作用域中查找 foo。胜利找到并执行

  【2】引擎须要进行 foo 函数的传参 a=2，为 a 进行 LHS 援用，在 foo 函数作用域中查找 a。胜利找到，并把 2 赋值给 a

  【3】引擎须要执行 console.log(…)，为 console 对象进行 RHS 援用，在 foo 函数作用域中查找 console 对象。因为 console 是个内置对象，被胜利找到

  【4】引擎在 console 对象中查找 log(…)办法，胜利找到

  【5】引擎须要执行 console.log(a)，对 a 进行 RHS 援用，在 foo 函数作用域中查找 a，胜利找到并执行

  【6】于是，引擎把 a 的值，也就是 2 传到 console.log(…)中

  【7】最终，控制台输入 2

二、了解词法作用域和动静作用域

2.1 词法作用域

编译器的第一个工作阶段叫作分词，就是把由字符组成的字符串分解成词法单元。这个概念是了解词法作用域的根底

简略地说，词法作用域就是定义在词法阶段的作用域，是由写代码时将变量和块作用域写在哪里来决定的，因而当词法分析器解决代码时会放弃作用域不变

• 关系

无论函数在哪里被调用，也无论它如何被调用，它的词法作用域都只由函数被申明时所处的地位决定

function foo(a) {
  var b = a * 2
  function bar(c) {console.log(a, b, c)
  }
  bar(b * 3)
}
foo(2) // 2 4 12

在这个例子中有三个逐级嵌套的作用域。为了帮忙了解，能够将它们设想成几个逐级蕴含的气泡

作用域气泡由其对应的作用域块代码写在哪里决定，它们是逐级蕴含的

气泡 1 蕴含着整个全局作用域，其中只有一个标识符：foo

气泡 2 蕴含着 foo 所创立的作用域，其中有三个标识符：a、bar 和 b

气泡 3 蕴含着 bar 所创立的作用域，其中只有一个标识符：c

• 查找

作用域气泡的构造和相互之间的地位关系给引擎提供了足够的地位信息，引擎用这些信息来查找标识符的地位

在代码片段中，引擎执行 console.log(…)申明，并查找 a、b 和 c 三个变量的援用。它首先从最外部的作用域，也就是 bar(…)函数的作用域开始查找。引擎无奈在这里找到 a，因而会去上一级到所嵌套的 foo(…)的作用域中持续查找。在这里找到了 a，因而引擎应用了这个援用。对 b 来讲也一样。而对 c 来说，引擎在 bar(…)中找到了它

[留神]词法作用域查找只会查找一级标识符，如果代码援用了 foo.bar.baz，词法作用域查找只会试图查找 foo 标识符，找到这个变量后，对象属性拜访规定别离接管对 bar 和 baz 属性的拜访

foo = {
  bar: {baz: 1}
}
console.log(foo.bar.baz) // 1

• 遮蔽

作用域查找从运行时所处的最外部作用域开始，逐级向外或者说向上进行，直到遇见第一个匹配的标识符为止

在多层的嵌套作用域中能够定义同名的标识符，这叫作“遮蔽效应”，外部的标识符“遮蔽”了内部的标识符

var a = 0
function test() {
  var a = 1
  console.log(a) // 1
}
test()

全局变量会主动为全局对象的属性，因而能够不间接通过全局对象的词法名称，而是间接地通过对全局对象属性的援用来对其进行拜访

var a = 0
function test() {
  var a = 1
  console.log(window.a) //0
}
test()

通过这种技术能够拜访那些被同名变量所遮蔽的全局变量。但非全局的变量如果被遮蔽了，无论如何都无奈被拜访到

2.2 动静作用域

javascript 应用的是词法作用域，它最重要的特色是它的定义过程产生在代码的书写阶段

那为什么要介绍动静作用域呢？实际上动静作用域是 javascript 另一个重要机制 this 的表亲。作用域凌乱少数是因为词法作用域和 this 机制相混同，傻傻分不清楚

动静作用域并不关怀函数和作用域是如何申明以及在任何处申明的，只关怀它们从何处调用。换句话说，作用域链是基于调用栈的，而不是代码中的作用域嵌套

var a = 2
function foo() {console.log(a)
}
function bar() {
  var a = 3
  foo()}
bar()

【1】如果处于词法作用域，也就是当初的 javascript 环境。变量 a 首先在 foo()函数中查找，没有找到。于是顺着作用域链到全局作用域中查找，找到并赋值为 2。所以控制台输入 2

【2】如果处于动静作用域，同样地，变量 a 首先在 foo()中查找，没有找到。这里会顺着调用栈在调用 foo()函数的中央，也就是 bar()函数中查找，找到并赋值为 3。所以控制台输入 3

两种作用域的区别，简而言之，词法作用域是在定义时确定的，而动静作用域是在运行时确定的

三、了解 JavaScript 的执行上下文栈，能够利用堆栈信息疾速定位问题

3.1 执行上下文

• 全局执行上下文：这是默认的、最根底的执行上下文。不在任何函数中的代码都位于全局执行上下文中。它做了两件事：1. 创立一个全局对象，在浏览器中这个全局对象就是 window 对象。2. 将 this 指针指向这个全局对象。一个程序中只能存在一个全局执行上下文。
• 函数执行上下文：每次调用函数时，都会为该函数创立一个新的执行上下文。每个函数都领有本人的执行上下文，然而只有在函数被调用的时候才会被创立。一个程序中能够存在任意数量的函数执行上下文。每当一个新的执行上下文被创立，它都会依照特定的程序执行一系列步骤，具体过程将在本文前面探讨。
• Eval 函数执行上下文：运行在 eval 函数中的代码也取得了本人的执行上下文，但因为 Javascript 开发人员不罕用 eval 函数，所以在这里不再探讨。

3.2 执行栈

执行栈，在其余编程语言中也被叫做调用栈，具备 LIFO（后进先出）构造，用于存储在代码执行期间创立的所有执行上下文。

当 JavaScript 引擎首次读取你的脚本时，它会创立一个全局执行上下文并将其推入以后的执行栈。每当产生一个函数调用，引擎都会为该函数创立一个新的执行上下文并将其推到以后执行栈的顶端。

引擎会运行执行上下文在执行栈顶端的函数，当此函数运行实现后，其对应的执行上下文将会从执行栈中弹出，上下文控制权将移到以后执行栈的下一个执行上下文。

让咱们通过上面的代码示例来了解这一点：

let a = 'Hello World!';

function first() {console.log('Inside first function');
second();
console.log('Again inside first function');
}

function second() {console.log('Inside second function');
}

first();
console.log('Inside Global Execution Context');

当上述代码在浏览器中加载时，JavaScript 引擎会创立一个全局执行上下文并且将它推入以后的执行栈。当调用 first() 函数时，JavaScript 引擎为该函数创立了一个新的执行上下文并将其推到以后执行栈的顶端。

当在 first() 函数中调用 second() 函数时，Javascript 引擎为该函数创立了一个新的执行上下文并将其推到以后执行栈的顶端。当 second() 函数执行实现后，它的执行上下文从以后执行栈中弹出，上下文控制权将移到以后执行栈的下一个执行上下文，即 first() 函数的执行上下文。

当 first() 函数执行实现后，它的执行上下文从以后执行栈中弹出，上下文控制权将移到全局执行上下文。一旦所有代码执行结束，Javascript 引擎把全局执行上下文从执行栈中移除。

3.3 执行上下文是如何被创立的

到目前为止，咱们曾经看到了 JavaScript 引擎如何治理执行上下文，当初就让咱们来了解 JavaScript 引擎是如何创立执行上下文的。

执行上下文分两个阶段创立：1）创立阶段； 2）执行阶段

3.4 创立阶段

在任意的 JavaScript 代码被执行前，执行上下文处于创立阶段。在创立阶段中总共产生了三件事件：

• 确定 this 的值，也被称为 This Binding。
• LexicalEnvironment（词法环境） 组件被创立。
• VariableEnvironment（变量环境） 组件被创立。

因而，执行上下文能够在概念上示意如下：

ExecutionContext = {
  ThisBinding = <this value>,
  LexicalEnvironment = {...},
  VariableEnvironment = {...},
}

This Binding:

在全局执行上下文中，this 的值指向全局对象，在浏览器中，this 的值指向 window 对象。

在函数执行上下文中，this 的值取决于函数的调用形式。如果它被一个对象援用调用，那么 this 的值被设置为该对象，否则 this 的值被设置为全局对象或 undefined（严格模式下）。例如：

let person = {
  name: 'peter',
  birthYear: 1994,
  calcAge: function() {console.log(2018 - this.birthYear);  
  }
}

person.calcAge();
// 'this' 指向 'person', 因为 'calcAge' 是被 'person' 对象援用调用的。let calculateAge = person.calcAge;
calculateAge();
// 'this' 指向全局 window 对象, 因为没有给出任何对象援用

3.4.1 词法环境（Lexical Environment）

官网 ES6 文档将词法环境定义为：

词法环境是一种标准类型，基于 ECMAScript 代码的词法嵌套构造来定义标识符与特定变量和函数的关联关系。词法环境由环境记录（environment record）和可能为空援用（null）的内部词法环境组成。

简而言之，词法环境是一个蕴含 标识符变量映射  的构造。（这里的  标识符  示意变量 / 函数的名称， 变量 是对理论对象【包含函数类型对象】或原始值的援用）

在词法环境中，有两个组成部分：（1）环境记录（environment record）（2）对外部环境的援用

1. 环境记录 是存储变量和函数申明的理论地位。
2. 对外部环境的援用 意味着它能够拜访其内部词法环境。

词法环境有两种类型：

• 全局环境（在全局执行上下文中）是一个没有外部环境的词法环境。全局环境的外部环境援用为 null。它领有一个全局对象（window 对象）及其关联的办法和属性（例如数组办法）以及任何用户自定义的全局变量，this 的值指向这个全局对象。
• 函数环境，用户在函数中定义的变量被存储在 环境记录 中。对外部环境的援用能够是全局环境，也能够是蕴含外部函数的内部函数环境。

留神：对于 函数环境  而言， 环境记录  还蕴含了一个 arguments 对象，该对象蕴含了索引和传递给函数的参数之间的映射以及传递给函数的参数的  长度（数量）。例如，上面函数的 arguments 对象如下所示：

function foo(a, b) {var c = a + b;}
foo(2, 3);

// arguments 对象
Arguments: {0: 2, 1: 3, length: 2},

环境记录同样有两种类型（如下所示）：

• 申明性环境记录 存储变量、函数和参数。一个函数环境蕴含申明性环境记录。
• 对象环境记录 用于定义在全局执行上下文中呈现的变量和函数的关联。全局环境蕴含对象环境记录。

抽象地说，词法环境在伪代码中看起来像这样：

GlobalExectionContext = {
  LexicalEnvironment: {
    EnvironmentRecord: {
      Type: "Object",
      // 标识符绑定在这里 
      outer: <null>
    }
  }
}

FunctionExectionContext = {
  LexicalEnvironment: {
    EnvironmentRecord: {
      Type: "Declarative",
      // 标识符绑定在这里 
      outer: <Global or outer function environment reference>
    }
  }
}

3.4.2 变量环境:

它也是一个词法环境，其 EnvironmentRecord 蕴含了由 VariableStatements 在此执行上下文创立的绑定。

如上所述，变量环境也是一个词法环境，因而它具备下面定义的词法环境的所有属性。

在 ES6 中，LexicalEnvironment 组件和 VariableEnvironment 组件的区别在于前者用于存储函数申明和变量（let 和 const）绑定，而后者仅用于存储变量（var）绑定。

让咱们联合一些代码示例来了解上述概念：

let a = 20;
const b = 30;
var c;

function multiply(e, f) {
  var g = 20;
  return e *f *g;
}

c = multiply(20, 30);

执行上下文如下所示：

GlobalExectionContext = {
  ThisBinding: <Global Object>,
  LexicalEnvironment: {
    EnvironmentRecord: {
      Type: "Object",
      // 标识符绑定在这里  
      a: < uninitialized >,
      b: < uninitialized >,
      multiply: < func >
    }  
    outer: <null>
  },
  VariableEnvironment: {
    EnvironmentRecord: {
      Type: "Object",
      // 标识符绑定在这里  
      c: undefined,
    }  
    outer: <null>
  }
}

FunctionExectionContext = {
  ThisBinding: <Global Object>,
  LexicalEnvironment: {
    EnvironmentRecord: {
      Type: "Declarative",
      // 标识符绑定在这里  
      Arguments: {0: 20, 1: 30, length: 2},
    },  
    outer: <GlobalLexicalEnvironment>
  },
  VariableEnvironment: {
    EnvironmentRecord: {
      Type: "Declarative",
      // 标识符绑定在这里  
      g: undefined
    },  
    outer: <GlobalLexicalEnvironment>
  }
}

留神：只有在遇到函数 multiply 的调用时才会创立函数执行上下文。

你可能曾经留神到了 let 和 const 定义的变量没有任何与之关联的值，但 var 定义的变量设置为 undefined。

这是因为在创立阶段，代码会被扫描并解析变量和函数申明，其中函数申明存储在环境中，而变量会被设置为 undefined（在 var 的状况下）或放弃未初始化（在 let 和 const 的状况下）。

这就是为什么你能够在申明之前拜访 var 定义的变量（只管是 undefined），但如果在申明之前拜访 let 和 const 定义的变量就会提醒援用谬误的起因。

这就是咱们所谓的变量晋升。

3.5 执行阶段

这是整篇文章中最简略的局部。在此阶段，实现对所有变量的调配，最初执行代码。

注：在执行阶段，如果 Javascript 引擎在源代码中申明的理论地位找不到 let 变量的值，那么将为其调配 undefined 值。

3.6 谬误堆栈的裁剪

Node.js 才反对这个个性，通过 Error.captureStackTrace 来实现，Error.captureStackTrace 接管一个 object 作为第 1 个参数，以及可选的 function 作为第 2 个参数。其作用是捕捉以后的调用栈并对其进行裁剪，捕捉到的调用栈会记录在第 1 个参数的 stack 属性上，裁剪的参照点是第 2 个参数，也就是说，此函数之前的调用会被记录到调用栈下面，而之后的不会。

让咱们用代码来阐明，首先，把以后的调用栈捕捉并放到 myObj 上：

const myObj = {};
function c() {}
function b() {
  // 把以后调用栈写到 myObj 上
  Error.captureStackTrace(myObj);
  c();}
function a() {b();
}

// 调用函数 a
a();

// 打印 myObj.stack
console.log(myObj.stack);

// 输入会是这样
//    at b (repl:3:7) <-- Since it was called inside B, the B call is the last entry in the stack
//    at a (repl:2:1)
//    at repl:1:1 <-- Node internals below this line
//    at realRunInThisContextScript (vm.js:22:35)
//    at sigintHandlersWrap (vm.js:98:12)
//    at ContextifyScript.Script.runInThisContext (vm.js:24:12)
//    at REPLServer.defaultEval (repl.js:313:29)
//    at bound (domain.js:280:14)
//    at REPLServer.runBound [as eval] (domain.js:293:12)
//    at REPLServer.onLine (repl.js:513:10)

下面的调用栈中只有 a -> b，因为咱们在 b 调用 c 之前就捕捉了调用栈。当初对下面的代码稍作批改，而后看看会产生什么：

const myObj = {};
function d() {
  // 咱们把以后调用栈存储到 myObj 上，然而会去掉 b 和 b 之后的局部
  Error.captureStackTrace(myObj, b);
}
function c() {d();
}
function b() {c();
}
function a() {b();
}

// 执行代码
a();

// 打印 myObj.stack
console.log(myObj.stack);

// 输入如下
//    at a (repl:2:1) <-- As you can see here we only get frames before b was called
//    at repl:1:1 <-- Node internals below this line
//    at realRunInThisContextScript (vm.js:22:35)
//    at sigintHandlersWrap (vm.js:98:12)
//    at ContextifyScript.Script.runInThisContext (vm.js:24:12)
//    at REPLServer.defaultEval (repl.js:313:29)
//    at bound (domain.js:280:14)
//    at REPLServer.runBound [as eval] (domain.js:293:12)
//    at REPLServer.onLine (repl.js:513:10)
//    at emitOne (events.js:101:20)

在这段代码外面，因为咱们在调用 Error.captureStackTrace 的时候传入了 b，这样 b 之后的调用栈都会被暗藏。

当初你可能会问，晓得这些到底有啥用？如果你想对用户暗藏跟他业务无关的谬误堆栈（比方某个库的外部实现）就能够试用这个技巧。

3.7 谬误调试

3.7.1 Error 对象和错误处理

当程序运行呈现谬误时, 通常会抛出一个 Error 对象. Error 对象能够作为用户自定义谬误对象继承的原型.

Error.prototype 对象蕴含如下属性：
 
constructor–指向实例的构造函数

message–错误信息

name–谬误的名字(类型)

上述是 Error.prototype 的规范属性, 此外, 不同的运行环境都有其特定的属性. 在例如 Node, Firefox, Chrome, Edge, IE 10+, Opera 以及 Safari 6+

这样的环境中, Error 对象具备 stack 属性, 该属性蕴含了谬误的堆栈轨迹. 一个谬误实例的堆栈轨迹蕴含了自构造函数之后的所有堆栈构造.

3.7.2 如何查看调用栈

只查看调用栈：console.trace

a()
function a() {b()
}
function b() {c()
}
function c() {let aa = 1}
console.trace()

3.7.3 debugger 打断点模式

四、this 的原理以及几种不同应用场景的取值

4.1 作为对象办法调用

在 JavaScript 中，函数也是对象，因而函数能够作为一个对象的属性，此时该函数被称为该对象的办法，在应用这种调用形式时，this 被天然绑定到该对象

var test = {
  a:0,
  b:0,
  get:function(){return this.a;}
}

4.2 作为函数调用

函数也能够间接被调用，此时 this 绑定到全局对象。在浏览器中，window 就是该全局对象。比方上面的例子：函数被调用时，this 被绑定到全局对象，

接下来执行赋值语句，相当于隐式的申明了一个全局变量，这显然不是调用者心愿的。

function makeNoSense(x) {this.x = x;}

4.3 作为结构函数调用

javaScript 反对面向对象式编程，与支流的面向对象式编程语言不同，JavaScript 并没有类（class）的概念，而是应用基于原型（prototype）的继承形式。

相应的，JavaScript 中的构造函数也很非凡，如果不应用 new 调用，则和一般函数一样。作为又一项约定俗成的准则，构造函数以大写字母结尾，

揭示调用者应用正确的形式调用。如果调用正确，this 绑定到新创建的对象上。

function Point(x, y){
  this.x = x;
  this.y = y;
}

4.4 在 call 或者 apply，bind 中调用

让咱们再一次重申，在 JavaScript 中函数也是对象，对象则有办法，apply 和 call 就是函数对象的办法。

这两个办法异样弱小，他们容许切换函数执行的上下文环境（context），即 this 绑定的对象。

很多 JavaScript 中的技巧以及类库都用到了该办法。让咱们看一个具体的例子：

function Point(x, y){
  this.x = x;
  this.y = y;
  this.moveTo = function(x, y){
    this.x = x;
    this.y = y;
  }
}

var p1 = new Point(0, 0);
var p2 = {x: 0, y: 0};
p1.moveTo(1, 1);
p1.moveTo.apply(p2, [10, 10])

五、闭包的实现原理和作用，能够列举几个开发中闭包的理论利用

5.1 闭包的概念

• 指有权拜访另一个函数作用域中的变量的函数，个别状况就是在一个函数中蕴含另一个函数。

5.2 闭包的作用

• 拜访函数外部变量、放弃函数在环境中始终存在，不会被垃圾回收机制解决

因为函数外部申明 的变量是部分的，只能在函数外部拜访到，然而函数内部的变量是对函数外部可见的，这就是作用域链的特点了。

子级能够向父级查找变量，逐级查找，找到为止

因而咱们能够在函数外部再创立一个函数，这样对外部的函数来说，外层函数的变量都是可见的，而后咱们就能够拜访到他的变量了。

function  bar(){
    // 外层函数申明的变量
    var value=1;

    function foo(){console.log(value);
    }
    return foo();};
var bar2=bar;
// 实际上 bar()函数并没有因为执行完就被垃圾回收机制解决掉
// 这就是闭包的作用，调用 bar()函数，就会执行外面的 foo 函数，foo 这时就会拜访到外层的变量
bar2();

foo（）蕴含 bar（）外部作用域的闭包，使得该作用域可能始终存活，不会被垃圾回收机制解决掉，这就是闭包的作用，以供 foo（）在任何工夫进行援用。

5.3 闭包的长处

• 不便调用上下文中申明的局部变量
• 逻辑严密，能够在一个函数中再创立个函数，防止了传参的问题

5.4 闭包的毛病

• 因为应用闭包，能够使函数在执行完后不被销毁，保留在内存中，如果大量应用闭包就会造成内存泄露，内存耗费很大

5.5 闭包在理论中的利用

function addFn(a,b){return(function(){console.log(a+"+"+b);
    })
}
var test =addFn(a,b);
setTimeout(test,3000);

个别 setTimeout 的第一个参数是个函数，然而不能传值。如果想传值进去，能够调用一个函数返回一个外部函数的调用，将外部函数的调用传给 setTimeout。外部函数执行所需的参数，内部函数传给他，在 setTimeout 函数中也能够拜访到内部函数。

六、了解堆栈溢出和内存透露的原理，如何避免

6.1 内存泄露

• 申请的内存执行完后没有及时的清理或者销毁，占用闲暇内存，内存泄露过多的话，就会导致前面的程序申请不到内存。因而内存泄露会导致外部内存溢出

6.2 堆栈溢出

• 内存空间曾经被申请完，没有足够的内存提供了

6.3 标记革除法

在一些编程软件中，比方 c 语言中，须要应用 malloc 来申请内存空间，再应用 free 开释掉，须要手动革除。而 js 中是有本人的垃圾回收机制的，个别罕用的垃圾收集办法就是标记革除。

标记革除法：在一个变量进入执行环境后就给它增加一个标记：进入环境，进入环境的变量不会被开释，因为只有执行流进入响应的环境，就可能用到他们。当变量来到环境后，则将其标记为“来到环境”。

6.4 常见的内存泄露的起因

• 全局变量引起的内存泄露
• 闭包
• 没有被革除的计时器

6.5 解决办法

• 缩小不必要的全局变量
• 缩小闭包的应用（因为闭包会导致内存泄露）
• 防止死循环的产生

七、如何解决循环的异步操作

7.1 应用自执行函数

1、当自执行函数在循环当中应用时，自执行函数会在循环完结之后才会运行。比方你在自执行函数里面定义一个数组，在自执行函数当中给这个数组追加内容，你在自执行函数之外输入时，会发现这个数组当中什么都没有，这就是因为自执行函数会在循环运行完后才会执行。

2、当自执行函数在循环当中应用时，要是自执行函数当中嵌套 ajax，那么循环当中的下标 i 就不会传进 ajax 当中，须要在 ajax 里面把下标 i 赋值给一个变量，在 ajax 中间接调用这个变量就能够了。

例子：

$.ajax({
    type: "GET",
    dataType: "json",
    url: "***",
    success: function(data) {//console.log(data);               
        for (var i = 0; i < data.length; i++) {(function(i, abbreviation) {
                $.ajax({
                    type: "GET",
                    url: "/api/faults?abbreviation=" + encodeURI(abbreviation),
                    dataType: "json",
                    success: function(result) {// 获取数据后做的事件}
                })
            })(i, data[i].abbreviation);
        }
    }
});

7.2 应用递归函数

所谓的递归函数就是在函数体内调用本函数。应用递归函数肯定要留神，处理不当就会进入死循环。

const asyncDeal = (i) = > {if (i < 3) {$.get('/api/changeParts/change_part_standard?part=' + data[i].change_part_name, function(res) {
            // 获取数据后做的事件
            i++;
            asyncDeal(i);
        })
    } else {// 异步实现后做的事件}
};
asyncDeal(0);

7.3 应用 async/await

• async/await 特点

async/await 更加语义化，async 是“异步”的简写，async function 用于申明一个 function 是异步的；await，能够认为是 async wait 的简写，用于期待一个异步办法执行实现；

async/await 是一个用同步思维解决异步问题的计划（等后果进去之后，代码才会持续往下执行）

能够通过多层 async function 的同步写法代替传统的 callback 嵌套

• async function 语法

主动将惯例函数转换成 Promise，返回值也是一个 Promise 对象

只有 async 函数外部的异步操作执行完，才会执行 then 办法指定的回调函数

异步函数外部能够应用 await

• await 语法

await 搁置在 Promise 调用之前，await 强制前面点代码期待，直到 Promise 对象 resolve，失去 resolve 的值作为 await 表达式的运算后果

await 只能在 async 函数外部应用, 用在一般函数里就会报错

const asyncFunc = function(i) {return new Promise(function(resolve) {$.get(url, function(res) {resolve(res);
        })
    });
}
const asyncDeal = async function() {for (let i = 0; i < data.length; i++) {let res = await asyncFunc(i);
        // 获取数据后做的事件
    }
}
asyncDeal();

八、了解模块化解决的理论问题，可列举几个模块化计划并了解其中原理

8.1 CommonJS 标准（同步加载模块）

容许模块通过 require 办法来同步加载所要依赖的其余模块，而后通过 exports 或 module.exports 来导出须要裸露的接口。

应用形式：

// 导入
require("module");
require("../app.js");
// 导出
exports.getStoreInfo = function() {};
module.exports = someValue;

长处：

• 简略容易应用
• 服务器端模块便于复用

毛病:

• 同步加载形式不适宜在浏览器环境中应用，同步意味着阻塞加载，浏览器资源是异步加载的
• 不能非阻塞的并行加载多个模块

为什么浏览器不能应用同步加载，服务端能够？

• 因为模块都放在服务器端，对于服务端来说模块加载时
• 而对于浏览器端，因为模块都放在服务器端，加载的工夫还取决于网速的快慢等因素，如果须要等很长时间，整个利用就会被阻塞。
• 因而，浏览器端的模块，不能采纳 ” 同步加载 ”（CommonJs），只能采纳 ” 异步加载 ”（AMD）。

参照 CommonJs 模块代表 node.js 的模块零碎

8.2 AMD（异步加载模块）

采纳异步形式加载模块，模块的加载不影响前面语句的运行。所有依赖模块的语句，都定义在一个回调函数中，等到加载实现之后，回调函数才执行。

应用实例：

// 定义
define("module", ["dep1", "dep2"], function(d1, d2) {...});
// 加载模块
require(["module", "../app"], function(module, app) {...});

加载模块 require([module], callback); 第一个参数[module]，是一个数组，外面的成员就是要加载的模块；第二个参数 callback 是加载胜利之后的回调函数。

长处：

• 适宜在浏览器环境中异步加载模块
• 能够并行加载多个模块

毛病：

• 进步了开发成本，代码的浏览和书写比拟艰难，模块定义形式的语义不顺畅
• 不合乎通用的模块化思维形式，是一种斗争的实现

实现 AMD 标准代表 require.js

RequireJS 对模块的态度是预执行。因为 RequireJS 是执行的 AMD 标准, 因而所有的依赖模块都是先执行; 即 RequireJS 是事后把依赖的模块执行，相当于把 require 提前了

RequireJS 执行流程：

• require 函数查看依赖的模块，依据配置文件，获取 js 文件的理论门路
• 依据 js 文件理论门路，在 dom 中插入 script 节点，并绑定 onload 事件来获取该模块加载实现的告诉。
• 依赖 script 全副加载实现后，调用回调函数

8.3 CMD 标准（异步加载模块）

CMD 标准和 AMD 很类似，简略，并与 CommonJS 和 Node.js 的 Modules 标准放弃了很大的兼容性；在 CMD 标准中，一个模块就是一个文件。

定义模块应用全局函数 define，其接管 factory 参数，factory 能够是一个函数，也能够是一个对象或字符串；

factory 是一个函数，有三个参数，function(require, exports, module)：

• require 是一个办法，承受模块标识作为惟一参数，用来获取其余模块提供的接口：require(id)
• exports 是一个对象，用来向外提供模块接口
• module 是一个对象，下面存储了与以后模块相关联的一些属性和办法

实例：

define(function(require, exports, module) {var a = require('./a');
  a.doSomething();
  // 依赖就近书写，什么时候用到什么时候引入
  var b = require('./b');
  b.doSomething();});

长处：

• 依赖就近，提早执行
• 能够很容易在 Node.js 中运行

毛病：

• 依赖 SPM 打包，模块的加载逻辑并重
• 实现代表库 sea.js：SeaJS 对模块的态度是懒执行, SeaJS 只会在真正须要应用 (依赖) 模块时才执行该模块

8.4 AMD 与 CMD 的区别

• 对于依赖的模块，AMD 是提前执行，CMD 是提早执行。不过 RequireJS 从 2.0 开始，也改成了能够提早执行（依据写法不同，解决形式不同）。CMD 推崇 as lazy as possible.
• AMD 推崇依赖前置；CMD 推崇依赖就近，只有在用到某个模块的时候再去 require。

// AMD
define(['./a', './b'], function(a, b) {  // 依赖必须一开始就写好  
   a.doSomething()    
   // 此处略去 100 行    
   b.doSomething()    
   ...
});
// CMD
define(function(require, exports, module) {var a = require('./a')   
   a.doSomething()   
   // 此处略去 100 行   
   var b = require('./b') 
   // 依赖能够就近书写   
   b.doSomething()
   // ... 
});

8.5 UMD

• UMD 是 AMD 和 CommonJS 的糅合
• AMD 以浏览器第一准则倒退异步加载模块。
• CommonJS 模块以服务器第一准则倒退，抉择同步加载，它的模块无需包装。
• UMD 先判断是否反对 Node.js 的模块（exports）是否存在，存在则应用 Node.js 模块模式；在判断是否反对 AMD（define 是否存在），存在则应用 AMD 形式加载模块。

(function (window, factory) {if (typeof exports === 'object') {module.exports = factory();
    } else if (typeof define === 'function' && define.amd) {define(factory);
    } else {window.eventUtil = factory();
    }
})(this, function () {//module ...});

8.6 ES6 模块化

• ES6 在语言规范的层面上，实现了模块性能，而且实现得相当简略，齐全能够取代 CommonJS 和 AMD 标准，成为浏览器和服务器通用的模块解决方案。
• ES6 模块设计思维：尽量的动态化、使得编译时就能确定模块的依赖关系，以及输出和输入的变量（CommonJS 和 AMD 模块，都只能在运行时确定这些货色）。

应用形式：

// 导入
import "/app";
import React from“react”;
import {Component} from“react”;
// 导出
export function multiply() {...};
export var year = 2018;
export default ...
...

长处：

• 容易进行动态剖析
• 面向未来的 EcmaScript 规范

毛病：

• 原生浏览器端还没有实现该规范
• 全新的命令字，新版的 Node.js 才反对。

8.7 回到问题“require 与 import 的区别”

require 应用与 CommonJs 标准，import 应用于 Es6 模块标准；所以两者的区别本质是两种标准的区别；

CommonJS：

• 对于根本数据类型，属于复制。即会被模块缓存；同时，在另一个模块能够对该模块输入的变量从新赋值。
• 对于简单数据类型，属于浅拷贝。因为两个模块援用的对象指向同一个内存空间，因而对该模块的值做批改时会影响另一个模块。
• 当应用 require 命令加载某个模块时，就会运行整个模块的代码。
• 当应用 require 命令加载同一个模块时，不会再执行该模块，而是取到缓存之中的值。也就是说，CommonJS 模块无论加载多少次，都只会在第一次加载时运行一次，当前再加载，就返回第一次运行的后果，除非手动革除零碎缓存。
• 循环加载时，属于加载时执行。即脚本代码在 require 的时候，就会全副执行。一旦呈现某个模块被 ” 循环加载 ”，就只输入曾经执行的局部，还未执行的局部不会输入。

ES6 模块

• ES6 模块中的值属于【动静只读援用】。
• 对于只读来说，即不容许批改引入变量的值，import 的变量是只读的，不论是根本数据类型还是简单数据类型。当模块遇到 import 命令时，就会生成一个只读援用。等到脚本真正执行时，再依据这个只读援用，到被加载的那个模块外面去取值。
• 对于动静来说，原始值发生变化，import 加载的值也会发生变化。不论是根本数据类型还是简单数据类型。
• 循环加载时，ES6 模块是动静援用。只有两个模块之间存在某个援用，代码就可能执行。

最初：require/exports 是必要通用且必须的；因为事实上，目前你编写的 import/export 最终都是编译为 require/exports 来执行的。