JavaScript 词法作用域

#1

前言

作用域被定义为一套规则，这套规则用来管理引擎如何在当前作用域以及嵌套的子作用域中根据标识符名称进行变量查找。

作用域共有两种主要的工作模型。第一种是最为普遍的，被大多数编程语言所采用的词法作用域，我们会对这种作用域进行深入讨论。另外一种叫作动态作用域。

词法阶段

大部分标准语言编译器的第一个工作阶段叫作词法化（也叫单词化），词法化的过程会对源代码中的字符进行检查，如果是有状态的解析过程，还会赋予单词语义。

简单地说，词法作用域就是定义在词法阶段的作用域。换句话说，词法作用域是由你在写代码时将变量和块作用域写在哪里来决定的，因此当词法分析器处理代码时会保持作用域
不变（大部分情况下是这样的）。

看下面的例子

  // (1) 包含着整个全局作用域，其中只有一个标识符：foo。
  function foo (a) {
    // (2) 包含着 foo 所创建的作用域，其中有三个标识符：a、bar 和 b。
    var b = a * 2;
    function bar (c) {
      // (3) 包含着 bar 所创建的作用域，其中只有一个标识符：c。
      console.log(a, b, c);
    }
    bar(b * 3)
  }
  foo(2);

查找

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

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

作用域查找会在找到第一个匹配的标识符时停止。在多层的嵌套作用域中可以定义同名的
标识符，这叫作“遮蔽效应”（内部的标识符“遮蔽”了外部的标识符）。抛开遮蔽效应，
作用域查找始终从运行时所处的最内部作用域开始，逐级向外或者说向上进行，直到遇见
第一个匹配的标识符为止。

欺骗词法

如果词法作用域完全由写代码期间函数所声明的位置来定义，怎样才能在运行时来“修
改”（也可以说欺骗）词法作用域呢？

JavaScript 中有两种机制来实现这个目的。社区普遍认为在代码中使用这两种机制并不是
什么好注意。但是关于它们的争论通常会忽略掉最重要的点：欺骗词法作用域会导致性能
下降。

eval

在执行 eval(…) 之后的代码时，引擎并不“知道”或“在意”前面的代码是以动态形式插
入进来，并对词法作用域的环境进行修改的。引擎只会如往常地进行词法作用域查找。

  function foo (str, a) {
    eval(str) // 词法欺骗
    console.log(a, b);
    // 此处的 b 永远也无法找到外部的b
    // 因为此处内部创建了一个 b 并且覆盖了外部的b
  }
  var b = 2;
  foo('var b = 3; ', a)

  // 注意 eval 语法在严格模式下有自己的作用域，所以无法修改作用域

with

JavaScript 中另一个难以掌握（并且现在也不推荐使用）的用来欺骗词法作用域的功能是
with 关键字。可以有很多方法来解释 with，在这里我选择从这个角度来解释它：它如何同
被它所影响的词法作用域进行交互。

with 通常被当作重复引用同一个对象中的多个属性的快捷方式，可以不需要重复引用对象本身。

  var obj = {
    a: 1,
    b: 2,
    c: 3
  };

  // 重复编写 "obj"
  obj.a = 2;
  obj.b = 3;
  obj.c = 4;

  // 简单的快捷方式
  with (obj) {
    a = 3;
    b = 4;
    c = 5;
  }

  console.log(obj) // 3, 4, 5

  function foo(obj) {
  with (obj) {
      a = 2;
    }
  }

  var o1 = {
    a: 3
  };

  var o2 = {
    b: 3
  };

  foo(o1);
  console.log(o1.a); // 2

  foo(o2);
  console.log(o2.a); // undefined

  console.log(a); // 2——不好，a 被泄漏到全局作用域上了！

此段代码为什么 o2.a 为 undefined 呢，我们可以这样理解。

当我们传递 o1 给 with 时，with 所声明的作用域是 o1，而这个作用域中含
有一个同 o1.a 属性相符的标识符。

但当我们将 o2 作为作用域时，其中并没有 a 标识符，因此进行了正常的 LHS 标识符查找，在非严格模式下 LHS 引用在全局环境下创建了一个 a 并且赋值为 2

性能

eval(…) 和 with 会在运行时修改或创建新的作用域，以此来欺骗其他在书写时定义的词法作用域。

但是，JavaScript 引擎原本会在编译阶段进行数项的性能优化。其中有些优化依赖于能够根据代码的词法进行静态分析，并预先确定所有变量和函数的定义位置，才能在执行过程中快速找到标识符。

但如果引擎在代码中发现了 eval(…) 或 with，它只能简单地假设关于标识符位置的判断
都是无效的，因为无法在词法分析阶段明确知道 eval(…) 会接收到什么代码，这些代码会
如何对作用域进行修改，也无法知道传递给 with 用来创建新词法作用域的对象的内容到底
是什么。

最悲观的情况是如果出现了 eval(…) 或 with，所有的优化可能都是无意义的，因此最简单的做法就是完全不做任何优化。

来源

1 Like