|
目录 1.静态作用域与动态作用域 2.变量的作用域 3.JavaScript 中变量的作用域 4.JavaScript 欺骗作用域 5.JavaScript 执行上下文 6.JavaScript 中的作用域链 7.JavaScript 中的闭包 8.JavaScript 中的模块 一 静态作用域与动态作用域 在电脑程序设计中，作用域（scope，或译作有效范围）是名字（name）与实体（entity）的绑定（binding）保持有效的那部分计算机程序。不同的编程语言可能有不同的作用域和名字解析。而同一语言内也可能存在多种作用域，随实体的类型变化而不同。作用域类别影响变量的绑定方式，根据语言使用静态作用域还是动态作用域变量的取值可能会有不同的结果。
原文中此处为链接，暂不支持采集 原文中此处为链接，暂不支持采集 原文中此处为链接，暂不支持采集 原文中此处为链接，暂不支持采集 作用域又分为两种，静态作用域和动态作用域。 静态作用域又叫做词法作用域，采用词法作用域的变量叫词法变量。词法变量有一个在编译时静态确定的作用域。词法变量的作用域可以是一个函数或一段代码，该变量在这段代码区域内可见（visibility）；在这段区域以外该变量不可见（或无法访问）。词法作用域里，取变量的值时，会检查函数定义时的文本环境，捕捉函数定义时对该变量的绑定。
静态(词法)作用域，就是可以无须执行程序而只从程序源码的角度，就可以看出程序是如何工作的。从上面的例子中可以肯定，函数 g 是被函数 f 包围在内部。 大多数现在程序设计语言都是采用静态作用域规则，如C/C 、C#、Python、Java、JavaScript…… 相反，采用动态作用域的变量叫做动态变量。只要程序正在执行定义了动态变量的代码段，那么在这段时间内，该变量一直存在；代码段执行结束，该变量便消失。这意味着如果有个函数f，里面调用了函数g，那么在执行g的时候，f里的所有局部变量都会被g访问到。而在静态作用域的情况下，g不能访问f的变量。动态作用域里，取变量的值时，会由内向外逐层检查函数的调用链，并打印第一次遇到的那个绑定的值。显然，最外层的绑定即是全局状态下的那个值。
当我们调用f()，它会调用g()。在执行期间，g被f调用代表了一种动态的关系。 采用动态作用域的语言有Pascal、Emacs Lisp、Common Lisp（兼有静态作用域）、Perl（兼有静态作用域）。C/C 是静态作用域语言，但在宏中用到的名字，也是动态作用域。 二 变量的作用域 1. 变量的作用域 变量的作用域是指变量在何处可以被访问到。比如：
这里的 bar 的直接作用域是函数作用域foo()； 2. 词法作用域 JavaScript 中的变量都是有静态(词法)作用域的，因此一个程序的静态结构就决定了一个变量的作用域，这个作用域不会被函数的位置改变而改变。 3. 嵌套作用域 如果一个变量的直接作用域中嵌套了多个作用域，那么这个变量在所有的这些作用域中都可以被访问：
arg的直接作用域是foo()，但是它同样可以在嵌套的作用域bar()中被访问，foo()是外部的作用域，bar()是内部作用域。 4. 覆盖的作用域 如果在一个作用域中声明了一个与外层作用域同名的变量，那么这个内部作用域以及内部的所有作用域中将会访问不到外面的变量。并且内部的变量的变化也不会影响到外面的变量，当变量离开内部的作用域以后，外部变量又可以被访问了。
这就是覆盖的作用域。 三 JavaScript 中变量的作用域 大多数的主流语言都是有块级作用域的，变量在最近的代码块中，Objective-C 和 Swift 都是块级作用域的。但是在 JavaScript 中的变量是函数级作用域的。不过在最新的 ES6 中加入了 let 和 const 关键字以后，就变相支持了块级作用域。到了 ES6 以后支持块级作用域的有以下几个： with 语句 用 with 从对象中创建出的作用域仅在 with 声明中而非外 部作用域中有效。 try/catch 语句 JavaScript 的 ES3 规范中规定 try/catch 的 catch 分句会创建一个块作用域，其中声明的变量仅在 catch 内部有效。 let 关键字 let关键字可以将变量绑定到所在的任意作用域中(通常是{ .. }内部)。换句话说，let 为其声明的变量隐式地了所在的块作用域。 const 关键字 除了 let 以外，ES6 还引入了 const，同样可以用来创建块作用域变量，但其值是固定的 (常量)。之后任何试图修改值的操作都会引起错误。 这里就需要注意变量和函数提升的问题了，这个问题在前一篇文章里面详细的说过了，这里不再赘述了。 不过这里还有一个坑，如果赋值给了一个未定义的变量，会产生一个全局变量。 在非严格模式下，不通过 var 关键字直接给一个变量赋值，会产生一个全局的变量
不过在严格模式下，这里会直接报错。
在 ES5 中，经常会通过引入一个新的作用域来限制变量的生命周期，通过 IIFE（Immediately-invoked function expression，立即执行的函数表达式）来引入新的作用域。 通过 IIFE ，我们可以
四 JavaScript 欺骗作用域 (1). with 语句 with 语句被很多人都认为是 JavaScript 里面的糟粕( Bad Parts )。起初它被设计出来的目的是好的，但是它导致的问题多于它解决的问题。 with 起初设计出来是为了避免冗余的对象调用。 举个例子：
这时候用 with 语句就可以缩短调用：
但是这种特性却带来了很多问题：
可以看到输出就出现问题了，由于 with 语句，覆盖掉了第一个入参。通过阅读代码，有时候是不能分辨出这些问题，它也会随着程序的运行，导致发生不多的变化，这种对未来的不确定性就很容易出现 bug。 with 会导致3个问题：
变量查找会变慢，因为对象是临时性的插入到作用域链中的。
@Brendan Eich 解释，废弃 with 的根本原因不是因为性能问题，原因是因为“with 可能会违背当前的代码上下文，使得程序的解析（例如安全性）变得困难而繁琐”。
所以在严格模式下，已经严格禁止使用 with 语句。
如果还是想避免使用 with 语句，有两种方法：
或者
(2). eval 函数 eval 函数传递一个字符串给 JavaScript 编译器，并且执行其结果。
它是 JavaScript 中被滥用的最多的特性之一。
eval 函数以及它的亲戚（ Function 、setTimeout、setInterval）都提供了访问 JavaScript 编译器的机会。 Function() 构造函数的形式比 eval() 函数好一点的地方在于，它令入参更加清晰。
用 Function() 的方式至少不用使用间接的 eval() 调用来确保所执行的代码除了其自己的作用域只能访问全局的变量。 在 Weex 的代码中，就还存在着 eval() 的代码，不过 Weex 团队在注释里面承诺会改掉。总的来说，最好应该避免使用 eval() 和 new Function() 这些动态执行代码的方法。动态执行代码相对会比较慢，并且还存在安全隐患。 再说说另外两个亲戚，setTimeout、setInterval 函数，它们也能接受字符串参数或者函数参数。当传递的是字符串参数时，setTimeout、setInterval 会像 eval 那样去处理。同样也需要避免使用这两个函数的时候使用字符串传参数。 eval 函数带来的问题总结如下：
五 JavaScript 执行上下文 这个事情要从 JavaScript 源代码如何被运行开始说起。 我们都知道 JavaScript 是脚本语言，它只有 runtime，没有编译型语言的 buildTime，那它是如何被各大浏览器运行起来的呢？ JavaScript 代码是被各个浏览器引擎编译和运行起来的。JavaScript 引擎的代码解析和执行过程的目标就是在最短时间内编译出最优化的代码。JavaScript 引擎还需要负责管理内存，负责垃圾回收，与宿主语言的交互等。流行的引擎有以下几种： 苹果公司的 JavaScriptCore （JSC） 引擎，Mozilla 公司的 SpiderMonkey，微软 Internet Explorer 的 Chakra (JScript引擎)，Microsoft Edge 的 Chakra (JavaScript引擎) ，谷歌 Chrome 的 V8。 其中 V8 引擎是最著名的开源的引擎，它和前面那几个引擎有一个最大的区别是：主流引擎都是基于字节码的实现，V8 的做法非常极致，直接跳过了字节码这一层，直接把 JS 编译成机器码。所以 V8 是没有解释器的。（但是这都是历史，V8 现在最新版是有解释器的） 在2017年5月1号之后， Chrome 的 V8 引擎的v8 5.9 发布了，其中的 Ignition 字节码解释器将默认启动 ：V8 Release 5.9 。v8 自此回到了字节码的怀抱。 V8 在有了字节码以后，消除 Cranshaft 这个旧的编译器，并让新的 Turbofan 直接从字节码来优化代码，并当需要进行反优化的时候直接反优化到字节码，而不需要再考虑 JS 源代码。去掉 Cranshaft 以后，就成了 Turbofan Ignition 的组合了。 Ignition TurboFan 的组合，就是字节码解释器 JIT 编译器的黄金组合。这一黄金组合在很多 JS 引擎中都有所使用，例如微软的 Chakra，它首先解释执行字节码，然后观察执行情况，如果发现热点代码，那么后台的 JIT 就把字节码编译成高效代码，之后便只执行高效代码而不再解释执行字节码。苹果公司的 SquirrelFish Extreme 也引入了 JIT。SpiderMonkey 更是如此，所有 JS 代码最初都是被解释器解释执行的，解释器同时收集执行信息，当它发现代码变热了之后，JaegerMonkey、IonMonkey 等 JIT 便登场，来编译生成高效的机器码。 总结一下： JavaScript 代码会先被引擎编译，转化成能被解释器识别的字节码。 源码会被词法分析，语法分析，生成 AST 抽象语法树。 AST 抽象语法树又会被字节码生成器进行多次优化，最终生成了中间态的字节码。这时的字节码就可以被解释器执行了。 这样，JavaScript 代码就可以被引擎跑起来了。 JavaScript 在运行过程中涉及到的作用域有3种：
当 JavaScript 代码执行的时候，引擎会创建不同的执行上下文，这些执行上下文就构成了一个执行上下文栈（Execution context stack，ECS）。 全局执行上下文永远都在栈底，当前正在执行的函数在栈顶。 当 JavaScript 引擎遇到一个函数执行的时候，就会创建一个执行上下文，并且压入执行上下文栈，当函数执行完毕的时候，就会将函数的执行上下文从栈中弹出。 对于每个执行上下文都有三个重要的属性，变量对象（Variable object，VO），作用域链（Scope chain）和this。这三个属性跟代码运行的行为有很重要的关系。 变量对象 VO 是与执行上下文相关的数据作用域。它是一个与上下文相关的特殊对象，其中存储了在上下文中定义的变量和函数声明。也就是说，一般 VO 中会包含以下信息：
上图也解释了，为何函数提升优先级会在变量提升前面。 这里还会牵扯到活动对象（Activation object）： 只有全局上下文的变量对象允许通过 VO 的属性名称间接访问。在函数执行上下文中，VO 是不能直接访问的，此时由活动对象(Activation Object, 缩写为AO)扮演 VO 的角色。活动对象是在进入函数上下文时刻被创建的，它通过函数的 arguments 属性初始化。 Arguments Objects 是函数上下文里的激活对象 AO 中的内部对象，它包括下列属性：
JavaScript 解释器创建执行上下文的时候，会经历两个阶段：
创建 Scope chain，创建 VO/AO（variables, functions and arguments），设置 this 的值。
设置变量的值，函数的引用，然后解释/执行代码。 VO 和 AO 的区别就在执行上下文的这两个生命周期里面。 VO 和 AO 的关系可以理解为，VO 在不同的 Execution Context 中会有不同的表现：当在 Global Execution Context 中，直接使用的 VO；但是，在函数 Execution Context 中，AO 就会被创建。 六 JavaScript 中的作用域链 在 JavaScript 中有两种变量传递的方式 1. 通过调用函数，执行上下文的栈传递变量。 函数每调用一次，就需要给它的参数和变量准备新的存储空间，就会创建一个新的环境将（变量和参数的）标识符合变量做映射。对于递归的情况，执行上下文，即通过环境的引用是在栈中进行管理的。这里的栈对应了调用栈。 JavaScript 引擎会以堆栈的方式来处理它们，这个堆栈，我们称其为函数调用栈(call stack)。栈底永远都是全局上下文，而栈顶就是当前正在执行的上下文。 这里举个例子：比如用递归的方式计算n的阶乘。 2. 作用域链 在 JavaScript 中有一个内部属性 [[ Scope ]] 来记录函数的作用域。在函数调用的时候，JavaScript 会为这个函数所在的新作用域创建一个环境，这个环境有一个外层域，它通过 [[ Scope ]] 创建并指向了外部作用域的环境。因此在 JavaScript 中存在一个作用域链，它以当前作用域为起点，连接了外部的作用域，每个作用域链最终会在全局环境里终结。全局作用域的外部作用域指向了null。 作用域链，是由当前环境与上层环境的一系列变量对象组成，它保证了当前执行环境对符合访问权限的变量和函数的有序访问。 作用域是一套规则，是在 JavaScript 引擎编译的时候确定的。 作用域链是在执行上下文的创建阶段创建的，这是在 JavaScript 引擎解释执行阶段确定的。
当程序运行到标志 1 的时候：
函数 myFunc 通过 [[ Scope]] 连接着它的作用域，全局作用域。 当程序运行到标志 2 的时候，JavaScript 会创建一个新的作用域用来管理参数和本地变量。
由于外层作用域链，使得 myFunC 可以访问到外层的 myFloat 。 这就是 Javascript 语言特有的'作用域链'结构（chain scope），子对象会一级一级地向上寻找所有父对象的变量。所以，父对象的所有变量，对子对象都是可见的，反之则不成立。
七 JavaScript 中的闭包 当函数可以记住并访问所在的词法作用域，即使函数是在当前词法作用域之外执行，这时就产生了闭包。 接下来看看大家对闭包的定义是什么样的： MDN 对闭包的定义：
《JavaScript 权威指南(第6版)》对闭包的定义：
《JavaScript 高级程序设计(第3版)》对闭包的定义：
最后是阮一峰老师对闭包的解释：
再来对比看看 OC，Swift，JS，Python 4种语言的闭包写法有何不同：
可以看出 OC 的写法默认是和其他三种语言不同的。关于 OC 的闭包原理，iOS 开发的同学应该都很清楚了，这里不再赘述。当然，想要第一种 OC 的写法输出11，也很好改，只要把外部需要捕获进去的变量前面加上 __block 关键字就可以了。 最后结合作用域链和闭包举一个例子：
当代码进入到 Global Execution Context 之后，会创建 Global Variable Object。全局执行上下文压入执行上下文栈。
Global Variable Object 初始化会创建 createInc ，并指向一个函数对象，初始化 inc ，此时还是 undefined。 接着代码执行到 createInc(5)，会创建 Function Execution Context，并压入执行上下文栈。会创建 createInc Activation Object。
由于还没有执行这个函数，所以 startValue 的值还是 undefined。接下来就要执行 createInc 函数了。
当 createInc 函数执行的最后，并退出的时候，Global VO中的 inc 就会被设置；这里需要注意的是，虽然 create Execution Context 退出了执行上下文栈，但是因为 inc 中的成员仍然引用 createInc AO（因为 createInc AO 是 function(step) 函数的 parent scope ），所以 createInc AO 依然在 Scope 中。 接着再开始执行 inc(3)。
当执行 inc(3) 代码的时候，代码将进入 inc Execution Context，并为该执行上下文创建 VO/AO，scope chain 和设置 this；这时，inc AO将指向 createInc AO。
最后，inc Execution Context 退出了执行上下文栈，但是 createInc AO 没有销毁，可以继续访问。 八 JavaScript 中的模块 由作用域又可以引申出模块的概念。 在 ES6 中会大量用到模块，通过模块系统进行加载时，ES6 会将文件当作独立的模块来处理。每个模块都可以导入其他模块或特定的 API 成员，同样也可以导出自己的 API 成员。 模块有两个主要特征:
JavaScript 最主要的有 CommonJS 和 AMD 两种，前者用于服务器，后者用于浏览器。在 ES6 中的 Module 使得编译时就能确定模块的依赖关系，以及输入输出的变量。CommonJS 和 AMD 模块都只能运行时确定这些东西。 CommonJS 模块就是对象，输入时必须查找对象属性。属于运行时加载。CommonJS 输入的是被输出值的拷贝，并不是引用。 ES6 的 Module 在编译时就完成模块编译，属于编译时加载，效率要比 CommonJS 模块的加载方式高。ES6 模块的运行机制与 CommonJS 不一样，它遇到模块加载命令 import 时不会去执行模块，只会生成一个动态的只读引用。等到真正需要的时候，再去模块中取值。ES6 模块加载的变量是动态引用，原始值变了，输入的值也会跟着变，并且不会缓存值，模块里面的变量绑定其所在的模块。
多线程的同步机制对资源进行加锁，使得在同一个时间，只有一个线程可以进行操作，同步用以解决多个线程同时访问时可能出现的问题。 同步机制可以使用synchronized关键字实现。 当synchronized关键字修饰一个方法的时候，该方法叫做同步方法。 当synchronized方法执行完或发生异常时，会自动释放锁。 下面通过一个例子来对synchronized关键字的用法进行解析。 1，是否使用synchronized关键字的不同public class ThreadTest{ public static void main(String[] args) { Example example = new Example(); Thread t1 = new Thread1(example); Thread t2 = new Thread1(example); t1.start(); t2.start(); }}class Example{ public synchronized void execute() { for (int i = 0; i < 10; i) { try { Thread.sleep(500); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println('Hello: ' i); } }}class Thread1 extends Thread{ private Example example; public Thread1(Example example) { this.example = example; } @Override public void run() { example.execute(); }} 是否在execute()方法前加上synchronized关键字，这个例子程序的执行结果会有很大的不同。 如果不加synchronized关键字，则两个线程同时执行execute()方法，输出是两组并发的。 如果加上synchronized关键字，则会先输出一组0到9，然后再输出下一组，说明两个线程是顺次执行的。 2.多个方法的多线程情况将程序改动一下，Example类中再加入一个方法execute2()。 之后再写一个线程类Thread2，Thread2中的run()方法执行的是execute2()。Example类中的两个方法都是被synchronized关键字修饰的。 public class ThreadTest{ public static void main(String[] args) { Example example = new Example(); Thread t1 = new Thread1(example); Thread t2 = new Thread2(example); t1.start(); t2.start(); }}class Example{ public synchronized void execute() { for (int i = 0; i < 20; i) { try { Thread.sleep((long) Math.random() * 1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println('Hello: ' i); } } public synchronized void execute2() { for (int i = 0; i < 20; i) { try { Thread.sleep((long) Math.random() * 1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println('World: ' i); } }}class Thread1 extends Thread{ private Example example; public Thread1(Example example) { this.example = example; } @Override public void run() { example.execute(); }}class Thread2 extends Thread{ private Example example; public Thread2(Example example) { this.example = example; } @Override public void run() { example.execute2(); }} 如果去掉synchronized关键字，则两个方法并发执行，并没有相互影响。 但是如例子程序中所写，即便是两个方法： 执行结果永远是执行完一个线程的输出再执行另一个线程的。 说明： 如果一个对象有多个synchronized方法，某一时刻某个线程已经进入到了某个synchronized方法，那么在该方法没有执行完毕前，其他线程是无法访问该对象的任何synchronized方法的。 结论： 当synchronized关键字修饰一个方法的时候，该方法叫做同步方法。 Java中的每个对象都有一个锁（lock），或者叫做监视器（monitor），当一个线程访问某个对象的synchronized方法时，将该对象上锁，其他任何线程都无法再去访问该对象的synchronized方法了（这里是指所有的同步方法，而不仅仅是同一个方法），直到之前的那个线程执行方法完毕后（或者是抛出了异常），才将该对象的锁释放掉，其他线程才有可能再去访问该对象的synchronized方法。 注意这时候是给对象上锁，如果是不同的对象，则各个对象之间没有限制关系。 尝试在代码中构造第二个线程对象时传入一个新的Example对象，则两个线程的执行之间没有什么制约关系。 3.考虑静态的同步方法当一个synchronized关键字修饰的方法同时又被static修饰，之前说过，非静态的同步方法会将对象上锁，但是静态方法不属于对象，而是属于类，它会将这个方法所在的类的Class对象上锁。 一个类不管生成多少个对象，它们所对应的是同一个Class对象。 public class ThreadTest{ public static void main(String[] args) { Example example = new Example(); Thread t1 = new Thread1(example); // 此处即便传入不同的对象，静态方法同步仍然不允许多个线程同时执行 example = new Example(); Thread t2 = new Thread2(example); t1.start(); t2.start(); }}class Example{ public synchronized static void execute() { for (int i = 0; i < 20; i) { try { Thread.sleep((long) Math.random() * 1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println('Hello: ' i); } } public synchronized static void execute2() { for (int i = 0; i < 20; i) { try { Thread.sleep((long) Math.random() * 1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println('World: ' i); } }}class Thread1 extends Thread{ private Example example; public Thread1(Example example) { this.example = example; } @Override public void run() { Example.execute(); }}class Thread2 extends Thread{ private Example example; public Thread2(Example example) { this.example = example; } @Override public void run() { Example.execute2(); }} 所以如果是静态方法的情况（execute()和execute2()都加上static关键字），即便是向两个线程传入不同的Example对象，这两个线程仍然是互相制约的，必须先执行完一个，再执行下一个。 结论： 如果某个synchronized方法是static的，那么当线程访问该方法时，它锁的并不是synchronized方法所在的对象，而是synchronized方法所在的类所对应的Class对象。Java中，无论一个类有多少个对象，这些对象会对应唯一一个Class对象，因此当线程分别访问同一个类的两个对象的两个static，synchronized方法时，它们的执行顺序也是顺序的，也就是说一个线程先去执行方法，执行完毕后另一个线程才开始。 4. synchronized块synchronized块写法： synchronized(object) { } 表示线程在执行的时候会将object对象上锁。（注意这个对象可以是任意类的对象，也可以使用this关键字）。 这样就可以自行规定上锁对象。 public class ThreadTest{ public static void main(String[] args) { Example example = new Example(); Thread t1 = new Thread1(example); Thread t2 = new Thread2(example); t1.start(); t2.start(); }}class Example{ private Object object = new Object(); public void execute() { synchronized (object) { for (int i = 0; i < 20; i) { try { Thread.sleep((long) Math.random() * 1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println('Hello: ' i); } } } public void execute2() { synchronized (object) { for (int i = 0; i < 20; i) { try { Thread.sleep((long) Math.random() * 1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println('World: ' i); } } }}class Thread1 extends Thread{ private Example example; public Thread1(Example example) { this.example = example; } @Override public void run() { example.execute(); }}class Thread2 extends Thread{ private Example example; public Thread2(Example example) { this.example = example; } @Override public void run() { example.execute2(); }} 例子程序4所达到的效果和例子程序2的效果一样，都是使得两个线程的执行顺序进行，而不是并发进行，当一个线程执行时，将object对象锁住，另一个线程就不能执行对应的块。 synchronized方法实际上等同于用一个synchronized块包住方法中的所有语句，然后在synchronized块的括号中传入this关键字。当然，如果是静态方法，需要锁定的则是class对象。 可能一个方法中只有几行代码会涉及到线程同步问题，所以synchronized块比synchronized方法更加细粒度地控制了多个线程的访问，只有synchronized块中的内容不能同时被多个线程所访问，方法中的其他语句仍然可以同时被多个线程所访问（包括synchronized块之前的和之后的）。 注意：被synchronized保护的数据应该是私有的。 结论： synchronized方法是一种粗粒度的并发控制，某一时刻，只能有一个线程执行该synchronized方法； synchronized块则是一种细粒度的并发控制，只会将块中的代码同步，位于方法内、synchronized块之外的其他代码是可以被多个线程同时访问到的。 JDK 5.0的并发包使用synchronized关键字解决线程的同步问题会带来一些执行效率上的问题。 JDK1.4及之前是无法避免这些问题的。 【免责声明】本账号旨在介绍更多的最新信息，部分信息转载自各类纸媒、网媒之所有作品，版权归作者本人所有，转载文章目的在于分享信息、提供阅读，不代表本平台赞同其观点和对其真实性负责！若作者或版权人不愿被使用，请即与我方公众号tedu_java联系，如有侵权本账号将迅速给您回应并做处理 如果你身边的小伙伴还在为找工作发愁，或者想转行，赶快将他（她）的姓名和联系方式发给茜茜老师（17600265125），茜茜老师会与他（她）致电并给他（她）最合适的学习建议并免费邀请他试听5天的课程，座位有限，抓紧时间哦~~
目录 1.静态作用域与动态作用域 2.变量的作用域 3.JavaScript 中变量的作用域 4.JavaScript 欺骗作用域 5.JavaScript 执行上下文 6.JavaScript 中的作用域链 7.JavaScript 中的闭包 8.JavaScript 中的模块 一 静态作用域与动态作用域 在电脑程序设计中，作用域（scope，或译作有效范围）是名字（name）与实体（entity）的绑定（binding）保持有效的那部分计算机程序。不同的编程语言可能有不同的作用域和名字解析。而同一语言内也可能存在多种作用域，随实体的类型变化而不同。作用域类别影响变量的绑定方式，根据语言使用静态作用域还是动态作用域变量的取值可能会有不同的结果。
原文中此处为链接，暂不支持采集 原文中此处为链接，暂不支持采集 原文中此处为链接，暂不支持采集 原文中此处为链接，暂不支持采集 作用域又分为两种，静态作用域和动态作用域。 静态作用域又叫做词法作用域，采用词法作用域的变量叫词法变量。词法变量有一个在编译时静态确定的作用域。词法变量的作用域可以是一个函数或一段代码，该变量在这段代码区域内可见（visibility）；在这段区域以外该变量不可见（或无法访问）。词法作用域里，取变量的值时，会检查函数定义时的文本环境，捕捉函数定义时对该变量的绑定。
静态(词法)作用域，就是可以无须执行程序而只从程序源码的角度，就可以看出程序是如何工作的。从上面的例子中可以肯定，函数 g 是被函数 f 包围在内部。 大多数现在程序设计语言都是采用静态作用域规则，如C/C 、C#、Python、Java、JavaScript…… 相反，采用动态作用域的变量叫做动态变量。只要程序正在执行定义了动态变量的代码段，那么在这段时间内，该变量一直存在；代码段执行结束，该变量便消失。这意味着如果有个函数f，里面调用了函数g，那么在执行g的时候，f里的所有局部变量都会被g访问到。而在静态作用域的情况下，g不能访问f的变量。动态作用域里，取变量的值时，会由内向外逐层检查函数的调用链，并打印第一次遇到的那个绑定的值。显然，最外层的绑定即是全局状态下的那个值。
当我们调用f()，它会调用g()。在执行期间，g被f调用代表了一种动态的关系。 采用动态作用域的语言有Pascal、Emacs Lisp、Common Lisp（兼有静态作用域）、Perl（兼有静态作用域）。C/C 是静态作用域语言，但在宏中用到的名字，也是动态作用域。 二 变量的作用域 1. 变量的作用域 变量的作用域是指变量在何处可以被访问到。比如：
这里的 bar 的直接作用域是函数作用域foo()； 2. 词法作用域 JavaScript 中的变量都是有静态(词法)作用域的，因此一个程序的静态结构就决定了一个变量的作用域，这个作用域不会被函数的位置改变而改变。 3. 嵌套作用域 如果一个变量的直接作用域中嵌套了多个作用域，那么这个变量在所有的这些作用域中都可以被访问：
arg的直接作用域是foo()，但是它同样可以在嵌套的作用域bar()中被访问，foo()是外部的作用域，bar()是内部作用域。 4. 覆盖的作用域 如果在一个作用域中声明了一个与外层作用域同名的变量，那么这个内部作用域以及内部的所有作用域中将会访问不到外面的变量。并且内部的变量的变化也不会影响到外面的变量，当变量离开内部的作用域以后，外部变量又可以被访问了。
这就是覆盖的作用域。 三 JavaScript 中变量的作用域 大多数的主流语言都是有块级作用域的，变量在最近的代码块中，Objective-C 和 Swift 都是块级作用域的。但是在 JavaScript 中的变量是函数级作用域的。不过在最新的 ES6 中加入了 let 和 const 关键字以后，就变相支持了块级作用域。到了 ES6 以后支持块级作用域的有以下几个： with 语句 用 with 从对象中创建出的作用域仅在 with 声明中而非外 部作用域中有效。 try/catch 语句 JavaScript 的 ES3 规范中规定 try/catch 的 catch 分句会创建一个块作用域，其中声明的变量仅在 catch 内部有效。 let 关键字 let关键字可以将变量绑定到所在的任意作用域中(通常是{ .. }内部)。换句话说，let 为其声明的变量隐式地了所在的块作用域。 const 关键字 除了 let 以外，ES6 还引入了 const，同样可以用来创建块作用域变量，但其值是固定的 (常量)。之后任何试图修改值的操作都会引起错误。 这里就需要注意变量和函数提升的问题了，这个问题在前一篇文章里面详细的说过了，这里不再赘述了。 不过这里还有一个坑，如果赋值给了一个未定义的变量，会产生一个全局变量。 在非严格模式下，不通过 var 关键字直接给一个变量赋值，会产生一个全局的变量
不过在严格模式下，这里会直接报错。
在 ES5 中，经常会通过引入一个新的作用域来限制变量的生命周期，通过 IIFE（Immediately-invoked function expression，立即执行的函数表达式）来引入新的作用域。 通过 IIFE ，我们可以
四 JavaScript 欺骗作用域 (1). with 语句 with 语句被很多人都认为是 JavaScript 里面的糟粕( Bad Parts )。起初它被设计出来的目的是好的，但是它导致的问题多于它解决的问题。 with 起初设计出来是为了避免冗余的对象调用。 举个例子：
这时候用 with 语句就可以缩短调用：
但是这种特性却带来了很多问题：
可以看到输出就出现问题了，由于 with 语句，覆盖掉了第一个入参。通过阅读代码，有时候是不能分辨出这些问题，它也会随着程序的运行，导致发生不多的变化，这种对未来的不确定性就很容易出现 bug。 with 会导致3个问题：
变量查找会变慢，因为对象是临时性的插入到作用域链中的。
@Brendan Eich 解释，废弃 with 的根本原因不是因为性能问题，原因是因为“with 可能会违背当前的代码上下文，使得程序的解析（例如安全性）变得困难而繁琐”。
所以在严格模式下，已经严格禁止使用 with 语句。
如果还是想避免使用 with 语句，有两种方法：
或者
(2). eval 函数 eval 函数传递一个字符串给 JavaScript 编译器，并且执行其结果。
它是 JavaScript 中被滥用的最多的特性之一。
eval 函数以及它的亲戚（ Function 、setTimeout、setInterval）都提供了访问 JavaScript 编译器的机会。 Function() 构造函数的形式比 eval() 函数好一点的地方在于，它令入参更加清晰。
用 Function() 的方式至少不用使用间接的 eval() 调用来确保所执行的代码除了其自己的作用域只能访问全局的变量。 在 Weex 的代码中，就还存在着 eval() 的代码，不过 Weex 团队在注释里面承诺会改掉。总的来说，最好应该避免使用 eval() 和 new Function() 这些动态执行代码的方法。动态执行代码相对会比较慢，并且还存在安全隐患。 再说说另外两个亲戚，setTimeout、setInterval 函数，它们也能接受字符串参数或者函数参数。当传递的是字符串参数时，setTimeout、setInterval 会像 eval 那样去处理。同样也需要避免使用这两个函数的时候使用字符串传参数。 eval 函数带来的问题总结如下：
五 JavaScript 执行上下文
这个事情要从 JavaScript 源代码如何被运行开始说起。 我们都知道 JavaScript 是脚本语言，它只有 runtime，没有编译型语言的 buildTime，那它是如何被各大浏览器运行起来的呢？ JavaScript 代码是被各个浏览器引擎编译和运行起来的。JavaScript 引擎的代码解析和执行过程的目标就是在最短时间内编译出最优化的代码。JavaScript 引擎还需要负责管理内存，负责垃圾回收，与宿主语言的交互等。流行的引擎有以下几种： 苹果公司的 JavaScriptCore （JSC） 引擎，Mozilla 公司的 SpiderMonkey，微软 Internet Explorer 的 Chakra (JScript引擎)，Microsoft Edge 的 Chakra (JavaScript引擎) ，谷歌 Chrome 的 V8。
其中 V8 引擎是最著名的开源的引擎，它和前面那几个引擎有一个最大的区别是：主流引擎都是基于字节码的实现，V8 的做法非常极致，直接跳过了字节码这一层，直接把 JS 编译成机器码。所以 V8 是没有解释器的。（但是这都是历史，V8 现在最新版是有解释器的）
在2017年5月1号之后， Chrome 的 V8 引擎的v8 5.9 发布了，其中的 Ignition 字节码解释器将默认启动 ：V8 Release 5.9 。v8 自此回到了字节码的怀抱。 V8 在有了字节码以后，消除 Cranshaft 这个旧的编译器，并让新的 Turbofan 直接从字节码来优化代码，并当需要进行反优化的时候直接反优化到字节码，而不需要再考虑 JS 源代码。去掉 Cranshaft 以后，就成了 Turbofan Ignition 的组合了。
Ignition TurboFan 的组合，就是字节码解释器 JIT 编译器的黄金组合。这一黄金组合在很多 JS 引擎中都有所使用，例如微软的 Chakra，它首先解释执行字节码，然后观察执行情况，如果发现热点代码，那么后台的 JIT 就把字节码编译成高效代码，之后便只执行高效代码而不再解释执行字节码。苹果公司的 SquirrelFish Extreme 也引入了 JIT。SpiderMonkey 更是如此，所有 JS 代码最初都是被解释器解释执行的，解释器同时收集执行信息，当它发现代码变热了之后，JaegerMonkey、IonMonkey 等 JIT 便登场，来编译生成高效的机器码。 总结一下： JavaScript 代码会先被引擎编译，转化成能被解释器识别的字节码。
源码会被词法分析，语法分析，生成 AST 抽象语法树。
AST 抽象语法树又会被字节码生成器进行多次优化，最终生成了中间态的字节码。这时的字节码就可以被解释器执行了。 这样，JavaScript 代码就可以被引擎跑起来了。 JavaScript 在运行过程中涉及到的作用域有3种：
当 JavaScript 代码执行的时候，引擎会创建不同的执行上下文，这些执行上下文就构成了一个执行上下文栈（Execution context stack，ECS）。 全局执行上下文永远都在栈底，当前正在执行的函数在栈顶。 当 JavaScript 引擎遇到一个函数执行的时候，就会创建一个执行上下文，并且压入执行上下文栈，当函数执行完毕的时候，就会将函数的执行上下文从栈中弹出。 对于每个执行上下文都有三个重要的属性，变量对象（Variable object，VO），作用域链（Scope chain）和this。这三个属性跟代码运行的行为有很重要的关系。 变量对象 VO 是与执行上下文相关的数据作用域。它是一个与上下文相关的特殊对象，其中存储了在上下文中定义的变量和函数声明。也就是说，一般 VO 中会包含以下信息：
上图也解释了，为何函数提升优先级会在变量提升前面。 这里还会牵扯到活动对象（Activation object）： 只有全局上下文的变量对象允许通过 VO 的属性名称间接访问。在函数执行上下文中，VO 是不能直接访问的，此时由活动对象(Activation Object, 缩写为AO)扮演 VO 的角色。活动对象是在进入函数上下文时刻被创建的，它通过函数的 arguments 属性初始化。
Arguments Objects 是函数上下文里的激活对象 AO 中的内部对象，它包括下列属性：
JavaScript 解释器创建执行上下文的时候，会经历两个阶段：
创建 Scope chain，创建 VO/AO（variables, functions and arguments），设置 this 的值。
设置变量的值，函数的引用，然后解释/执行代码。 VO 和 AO 的区别就在执行上下文的这两个生命周期里面。
VO 和 AO 的关系可以理解为，VO 在不同的 Execution Context 中会有不同的表现：当在 Global Execution Context 中，直接使用的 VO；但是，在函数 Execution Context 中，AO 就会被创建。 六 JavaScript 中的作用域链 在 JavaScript 中有两种变量传递的方式 1. 通过调用函数，执行上下文的栈传递变量。 函数每调用一次，就需要给它的参数和变量准备新的存储空间，就会创建一个新的环境将（变量和参数的）标识符合变量做映射。对于递归的情况，执行上下文，即通过环境的引用是在栈中进行管理的。这里的栈对应了调用栈。 JavaScript 引擎会以堆栈的方式来处理它们，这个堆栈，我们称其为函数调用栈(call stack)。栈底永远都是全局上下文，而栈顶就是当前正在执行的上下文。 这里举个例子：比如用递归的方式计算n的阶乘。 2. 作用域链 在 JavaScript 中有一个内部属性 [[ Scope ]] 来记录函数的作用域。在函数调用的时候，JavaScript 会为这个函数所在的新作用域创建一个环境，这个环境有一个外层域，它通过 [[ Scope ]] 创建并指向了外部作用域的环境。因此在 JavaScript 中存在一个作用域链，它以当前作用域为起点，连接了外部的作用域，每个作用域链最终会在全局环境里终结。全局作用域的外部作用域指向了null。 作用域链，是由当前环境与上层环境的一系列变量对象组成，它保证了当前执行环境对符合访问权限的变量和函数的有序访问。 作用域是一套规则，是在 JavaScript 引擎编译的时候确定的。 作用域链是在执行上下文的创建阶段创建的，这是在 JavaScript 引擎解释执行阶段确定的。
当程序运行到标志 1 的时候：
函数 myFunc 通过 [[ Scope]] 连接着它的作用域，全局作用域。 当程序运行到标志 2 的时候，JavaScript 会创建一个新的作用域用来管理参数和本地变量。
由于外层作用域链，使得 myFunC 可以访问到外层的 myFloat 。 这就是 Javascript 语言特有的'作用域链'结构（chain scope），子对象会一级一级地向上寻找所有父对象的变量。所以，父对象的所有变量，对子对象都是可见的，反之则不成立。
七 JavaScript 中的闭包 当函数可以记住并访问所在的词法作用域，即使函数是在当前词法作用域之外执行，这时就产生了闭包。 接下来看看大家对闭包的定义是什么样的： MDN 对闭包的定义：
《JavaScript 权威指南(第6版)》对闭包的定义：
《JavaScript 高级程序设计(第3版)》对闭包的定义：
最后是阮一峰老师对闭包的解释：
再来对比看看 OC，Swift，JS，Python 4种语言的闭包写法有何不同：
可以看出 OC 的写法默认是和其他三种语言不同的。关于 OC 的闭包原理，iOS 开发的同学应该都很清楚了，这里不再赘述。当然，想要第一种 OC 的写法输出11，也很好改，只要把外部需要捕获进去的变量前面加上 __block 关键字就可以了。 最后结合作用域链和闭包举一个例子：
当代码进入到 Global Execution Context 之后，会创建 Global Variable Object。全局执行上下文压入执行上下文栈。
Global Variable Object 初始化会创建 createInc ，并指向一个函数对象，初始化 inc ，此时还是 undefined。 接着代码执行到 createInc(5)，会创建 Function Execution Context，并压入执行上下文栈。会创建 createInc Activation Object。
由于还没有执行这个函数，所以 startValue 的值还是 undefined。接下来就要执行 createInc 函数了。
当 createInc 函数执行的最后，并退出的时候，Global VO中的 inc 就会被设置；这里需要注意的是，虽然 create Execution Context 退出了执行上下文栈，但是因为 inc 中的成员仍然引用 createInc AO（因为 createInc AO 是 function(step) 函数的 parent scope ），所以 createInc AO 依然在 Scope 中。 接着再开始执行 inc(3)。
当执行 inc(3) 代码的时候，代码将进入 inc Execution Context，并为该执行上下文创建 VO/AO，scope chain 和设置 this；这时，inc AO将指向 createInc AO。
最后，inc Execution Context 退出了执行上下文栈，但是 createInc AO 没有销毁，可以继续访问。 八 JavaScript 中的模块 由作用域又可以引申出模块的概念。 在 ES6 中会大量用到模块，通过模块系统进行加载时，ES6 会将文件当作独立的模块来处理。每个模块都可以导入其他模块或特定的 API 成员，同样也可以导出自己的 API 成员。 模块有两个主要特征:
JavaScript 最主要的有 CommonJS 和 AMD 两种，前者用于服务器，后者用于浏览器。在 ES6 中的 Module 使得编译时就能确定模块的依赖关系，以及输入输出的变量。CommonJS 和 AMD 模块都只能运行时确定这些东西。 CommonJS 模块就是对象，输入时必须查找对象属性。属于运行时加载。CommonJS 输入的是被输出值的拷贝，并不是引用。 ES6 的 Module 在编译时就完成模块编译，属于编译时加载，效率要比 CommonJS 模块的加载方式高。ES6 模块的运行机制与 CommonJS 不一样，它遇到模块加载命令 import 时不会去执行模块，只会生成一个动态的只读引用。等到真正需要的时候，再去模块中取值。ES6 模块加载的变量是动态引用，原始值变了，输入的值也会跟着变，并且不会缓存值，模块里面的变量绑定其所在的模块。 |
|
|
来自： Levy_X > 《JavaScript》
