问题:词法作用域是什么?怎么才能在运行时“修改”(也可以说是欺骗)词法作用域呢?
2.1 词法作用域
简单的说,词法作用域就是定义在词法阶段的作用域。词法作用域由你写代码时把变量和块作用域写在哪里决定的。
因此,当词法分析器处理代码时会保持作用域不变(大部分情况下)。
function foo(a) {
var b = a * 2;
function bar(c) {
console.log(a, b, c);
}
bar(b * 3);
}
foo(2);
这个例子中有三个逐级嵌套的作用域
- 全局作用域,只有一个标识符,foo
- foo所创建的作用域,三个标识符,a、bar和b
- bar所创建的作用域,只有一个标识符,c
查找
作用域查找会在找到第一个匹配的标识符时停止。
在多层的嵌套作用域中可以定义同名的标识符,这叫作“遮蔽效应”(内部标识符遮蔽了外部标识符)。
抛开遮蔽效应,作用域查找始终从运行时所处的最内部作用域开始逐级向外或者说向上,直到遇见第一个匹配的标识符为止。
全局变量会自动成为全局对象(比如浏览器中的Windows对象)的属性,因此可以通过对全局对象属性的引用来对其访问(window.a)
通过这种技术可以访问那些被遮蔽的全局变量。
词法作用域查找只会查找一级标识符,比如 a、b、c。如果代码使用了foo.bar.baz,词法作用域只会试图查找foo标识符,找到这个变量后,对象属性访问规则会分别接管bar和baz属性的访问。
2.2 欺骗词法
怎么才能在运行时“修改”(也可以说是欺骗)词法作用域呢?JavaScript有两种机制来实现,但是都会导致性能下降。
2.2.1 eval
function foo(str, a) {
eval(str); //欺骗
console.log(a, b);
}
var b = 2;
foo("var b=3;", 1) //1,3
eval(..)通常用来执行动态创建的代码。
eval(..)调用的“var b=3”这段代码会被当做本来就在那里一样处理。
事实上,这段代码在foo(..)内部创建了一个变量b,并遮蔽了外部(全局)作用域中的同名变量。
在严格模式中,eval(..)有自己 的作用域,这意味着其中的声明无法修改所在的作用域。
2.2.2 with
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被泄露到全局作用域上了
with(obj)的作用实际上是一个LHS引用
找到obj,并把值赋给obj.a
- 当o1传递进去,a=2赋值操作找到了o1.a并赋值给它
- 当o2传递进去,o2并没有a这个属性,因此并不会(在with创造的作用域内)创建这个属性,o2.a保持undefined,进行正常的LHS标识符查找,一直查找到全局作用域都没有找到时,自动创建了一个全局变量(非严格模式)
with块可以将一个对象处理为一个完全隔离的词法作用域,因此这个对象的属性也会被处理为定义在这个作用域中的词法标识符
但是这个块内部正常的var声明并不会被限制在这个块的作用域中,而是被添加到with所处的函数作用域中,也就是with(..){}中
区别:eval(..)函数会修改其所处的词法作用域,而with声明实际上是根据你传递的对象凭空建造了一个全新的词法作用域。
2.2.3 性能
JavaScript引擎会在编译阶段进行数项的性能优化。其中有些优化依赖于根据代码的词法进行静态分析,并预先确定所有变量和函数的定义位置,才能在执行过程中快速的找到标识符
但如果引擎在代码中发现了eval(..)或者with,他无法知道会对作用域带来怎么样的改变,所有优化可能都是没用意义的,因此最简单的方法是完全不做任何优化。
2.3 小结
词法作用域意味着作用域是由书写代码的位置决定的。
编译的词法分析阶段基本能够知道全部标识符在哪里以及是如何声明的,从而能预测执行过程中如何进行查找
JavaScript有两个机制可以“欺骗”词法作用域:eval(..)和with。
前值可以对一段包含一个或多个声明的“代码”进行演算,并借此修改以及存在词法作用域(在运行时)
后者本质上是通过将一个对象的引用当作作用域来处理,将对象的属性当作作用域中的标识符来处理,从而创建了一个新的词法作用域(同样是在运行时)
副作用就是引擎无法在编译时对作用域进行优化,因此引擎只能谨慎的认为这样的优化是无效的。使用任何一个机制都将导致代码运行变慢。不要使用他们!