词法作用域

文章目录

1. 词法阶段
2. 欺骗词法

作用域共有两种主要的工作模型。第一种是最为普遍的，被大多数编程语言所采用的词法作用域。另外一种叫作动态作用域，仍有一些编程语言在使用（比如
Bash脚本、Perl中的一些模式等）。

词法阶段

大部分标准语言编译器的第一个工作阶段叫作词法化（也叫单词化）。词
法化的过程会对源代码中的字符进行检查，如果是有状态的解析过程，还会赋予单词语义。
这个概念是理解词法作用域及其名称来历的基础。
简单地说，词法作用域就是定义在词法阶段的作用域。换句话说，词法作用域是由你在写代码时将
变量和块作用域写在哪里来决定的，因此当词法分析器处理代码时会保持作用域不变（大部分情
况下是这样的）。

考虑以下代码：

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。
作用域气泡由其对应的作用域块代码写在哪里决定，它们是逐级包含的。

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

全局变量会自动成为全局对象（比如浏览器中的window对象）的属性，因此可以不直接通
过全局对象的词法名称，而是间接地通过对全局对象属性的引用来对其进行访问。

window.a

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

无论函数在哪里被调用，也无论它如何被调用，它的词法作用域都只由函数被声明时所处的位置
决定。
词法作用域查找只会查找一级标识符，比如a、b和c。如果代码中引用了foo.bar.baz，词法作用域查
找只会试图查找foo标识符，找到这个变量后，对象属性访问规则会分别接管对bar和baz属性的访
问。

欺骗词法

如果词法作用域完全由写代码期间函数所声明的位置来定义，怎样才能在运行时来“修改”（也可以
说欺骗）词法作用域呢？
JavaScript中有两种机制来实现这个目的。社区普遍认为在代码中使用这两种机制并不是什么好
方法。但是关于它们的争论通常会忽略掉最重要的点：欺骗词法作用域会导致性能下降。

eval

JavaScript中的eval(..)函数可以接受一个字符串为参数，并将其中的内容视为好像在书写时就存
在于程序中这个位置的代码。换句话说，可以在你写的代码中用程序生成代码并运行，就好像代码
是写在那个位置的一样。

考虑以下代码：

function foo(str, a) {
    eval( str ); // 欺骗！
    console.log( a, b );
}
var b = 2;
foo( "var b = 3;", 1 ); // 1, 3

eval(..)调用中的”var b = 3;”这段代码会被当作本来就在那里一样来处理。由于那段代码声明了
一个新的变量b，因此它对已经存在的foo(..)的词法作用域进行了修改。事实上，和前面提到的原
理一样，这段代码实际上在foo(..)内部创建了一个变量b，并遮蔽了外部（全局）作用域中的同名
变量。

在严格模式的程序中，eval(..)在运行时有其自己的词法作用域，意味着其中的声明无法
修改所在的作用域。

function foo(str) {
    "use strict";
    eval( str );
    console.log( a ); // ReferenceError: a is not defined
}
foo( "var a = 2");

JavaScript中还有其他一些功能效果和eval(..)很相似。setTimeout(..)和setInterval(..)的第一
个参数可以是字符串，字符串的内容可以被解释为一段动态生成的函数代码。这些功能已经过时
且并不被提倡。不要使用它们！
new Function(..)函数的行为也很类似，最后一个参数可以接受代码字符串，并将其转化为动态生
成的函数（前面的参数是这个新生成的函数的形参）。这种构建函数的语法比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;
}

但实际上这不仅仅是为了方便地访问对象属性。考虑如下代码：

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被泄漏到全局作用域上了！

这个例子中创建了o1和o2两个对象。其中一个具有a属性，另外一个没有。foo(..)函数接受一个obj
参数，该参数是一个对象引用，并对这个对象引用执行了with(obj) {..}。在with块内部，我们写的
代码看起来只是对变量a进行简单的词法引用，实际上就是一个LHS引用（查看第1章），并将2赋值
给它。
当我们将o1传递进去，a = 2赋值操作找到了o1.a并将2赋值给它，这在后面的console.log(o1.a)中
可以体现。而当o2传递进去，o2并没有a属性，因此不会创建这个属性，o2.a保持undefined。
但是可以注意到一个奇怪的副作用，实际上a = 2赋值操作创建了一个全局的变量a。这是怎么回
事？
with可以将一个没有或有多个属性的对象处理为一个完全隔离的词法作用域，因此这个对象的属
性也会被处理为定义在这个作用域中的词法标识符。

尽管with块可以将一个对象处理为词法作用域，但是这个块内部正常的var声明并不会被
限制在这个块的作用域中，而是被添加到with所处的函数作用域中。

eval(..)函数如果接受了含有一个或多个声明的代码，就会修改其所处的词法作用域，而with声明
实际上是根据你传递给它的对象凭空创建了一个全新的词法作用域。
可以这样理解，当我们传递o1给with时，with所声明的作用域是o1，而这个作用域中含有一个
同o1.a属性相符的标识符。但当我们将o2作为作用域时，其中并没有a标识符，因此进行了正常的
LHS标识符查找。
o2的作用域、foo(..)的作用域和全局作用域中都没有找到标识符a，因此当a = 2执行时，自动创建
了一个全局变量（因为是非严格模式）。

另外一个不推荐使用eval(..)和with的原因是会被严格模式所影响（限制）。with被完全
禁止，而在保留核心功能的前提下，间接或非安全地使用eval(..)也被禁止了。

性能

如果代码中大量使用eval(..)或with，那么运行起来一定会变得非常慢。无论引擎多聪明，试图将
这些悲观情况的副作用限制在最小范围内，也无法避免如果没有这些优化，代码会运行得更慢这
个事实。

fire on the world!

try to take over the world

词法作用域

词法阶段

欺骗词法

eval

with

性能