JS-词法作用域

词法作用域

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

作用域查找会在找到第一个匹配的标识符时停止

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

词法作用域查找只会查找一级标识符，比如a、b和c。如果代码中引用了foo.bar.baz，词法作用域查找只会试图查找foo标识符，找到这个变量后，对象属性访问规则会分别接管对bar和baz属性的访问。

欺骗词法

1.eval

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

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

无论何种情况，eval(…)都可以在运行期修改书写期的词法作用域。

在严格模式的程序中，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(…)略微安全一些，但也要尽量避免使用。

在程序中动态生成代码的使用场景非常罕见，因为它所带来的好处无法抵消性能上的损失。

2.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标识符查找（查看第1章）。

o2的作用域、foo(…)的作用域和全局作用域中都没有找到标识符a，因此当a＝2执行时，自动创建了一个全局变量（因为是非严格模式）。
with这种将对象及其属性放进一个作用域并同时分配标识符的行为很让人费解。但为了说明我们所看到的现象，这是我能给出的最直白的解释了。

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

3.性能

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

你可能会问，那又怎样呢？如果它们能实现更复杂的功能，并且代码更具有扩展性，难道不是非常好的功能吗？答案是否定的。

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

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

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

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

小结
词法作用域意味着作用域是由书写代码时函数声明的位置来决定的。编译的词法分析阶段基本能够知道全部标识符在哪里以及是如何声明的，从而能够预测在执行过程中如何对它们进行查找。

JavaScript中有两个机制可以“欺骗”词法作用域：eval(…)和with。前者可以对一段包含一个或多个声明的“代码”字符串进行演算，并借此来修改已经存在的词法作用域（在运行时）。后者本质上是通过将一个对象的引用当作作用域来处理，将对象的属性当作作用域中的标识符来处理，从而创建了一个新的词法作用域（同样是在运行时）。

这两个机制的副作用是引擎无法在编译时对作用域查找进行优化，因为引擎只能谨慎地认为这样的优化是无效的。使用这其中任何一个机制都将导致代码运行变慢。不要使用它们。