关于javascript:作用域三欺骗词法

在上一篇文章中，小编介绍了词法作用域，并在其中提到了两个会呈现“坑骗”词法作用域的关键字——eval 和 with，明天小编就和大家一起揭开这两个关键字的神秘面纱。在摸索明天的内容之前，先把上一篇文章的债还上。

在上一篇文章中，我提到了【通过这种技术能够拜访那些被同名变量所遮蔽的全局变量，但非全局变量如果被遮蔽了，无论如何都无奈被拜访到。】，上面的代码没有写进去。也就是这样：

var b = 3
function foo(){
  var b = 4;
  function bar(){
    var b = 5;
    console.log(b);
  }
  bar();}

在这个函数中，能够通过调用函数 foo，能够看到词法作用域的遮蔽效应，在这个函数中，遮蔽了全局变量 var b = 3，也遮蔽了在 foo 内的 var b=4; 咱们能够通过 window.b 来拜访到 3，然而目前为止，咱们还不能拜访到 4

上面明天的干货才正式开始：

如果词法作用域齐全由写代码期间函数所申明的地位来定义，怎样才能在运行时来“批改”（也能够说坑骗）词法作用域呢？

JavaScript 中有两种机制来实现这个目标。社区普遍认为在代码中应用这两种机制并不是什么好主见。然而对于他们的争执通常会疏忽掉最重要的点：坑骗词法作用域会导致性能降落。

在具体解释性能问题之前，先来看看这两种机制别离是什么原理。

一、eval
JavaScript 中的 eval 函数能够承受一个字符串作为参数，并将其中的内容视为如同在书写时就在于程序中的这个地位的代码。换句话说，能够在你写的代码中用程序生成代码并运行，就如同代码是写在那个地位的一样。【其实这自身如同就影响了代码的失常运行。】

依据这个原理来了解 eval，它是如何通过代码坑骗和伪装书写时（也就是词法期）代码就在那，来实现批改词法作用域环境的，这个原理就变得清晰易懂了。

在执行 eval 之后的代码时，引擎并不“晓得”或者“在意”后面的代码是以动静模式插入进来【也就是通过 eval 函数外部的代码】，并对词法作用域的环境进行批改的。引擎只会如平常地进行词法作用域查找【就这么把引擎坑骗了】。

思考以下代码

function foo(a){eval(str); // 坑骗【因为咱们不晓得 str 中会传入什么，弄不好就是一个新的作用域】console.log(a, b);
}

var b = 2;
foo(“var b=3”,1); // 1,3

eval 调用中的“var b=3;”这段代码会被当作原本就在那里一样来解决
【这个时候，函数在援用的时候就变成了这样】

function foo(a){
  var b=3;
  console.log(a, b);
}

var b = 2;
foo(1); // 1,3

因为那段代码申明了一个新的变量 b，因而它对曾经存在的 foo 的词法作用域进行了批改。事实上，和后面提到的原理一样，这段代码实际上在 foo 外部创立了一个变量 b，并遮蔽了内部（全局）作用域中的同名变量。【是否还记得变量的遮蔽效应，不记得的话，能够翻看小编的上一篇文章】

当 console.log 被执行时，会在 foo 外部同时找到 a 和 b，然而永远也无奈找到内部的 b。【因为在 eval 外部，建设了一个部分作用域，遮蔽了全局的 b，如果要拜访全局的 b，能够通过 window.b 拜访到】因而会输入“1，3”，而不是失常状况下会输入的“1，2”

【如果要是想强制的输入“1，2”，咱们能够顽皮的把代码改成这样】

function foo(a){eval(str);
  console.log(a, window.b); // 通过 window，拜访的就是全局上的 b 变量的值
}

var b = 2;
foo(“var b=3”,1); // 1,2

在下面的例子中，为了展现的不便和简洁，咱们传递进去的“代码”字符串是固定不变的。而在理论状况中，能够非常容易的依据程序逻辑动静的将字符串拼接在一起之后再传递进去。eval 通常被用来执行动态创建的代码，因为像例子中这样动静的执行一段固定字符串所组成的代码，并没有比间接将代码写在那里更有益处。

在严格模式的程序中，eval 在运行时有其本人的词法作用域，意味着其中的申明无奈批改所在的作用域

fuction 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 援用，并将 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 执行时，主动创立了一个全局变量（因为是非严格模式）【在严格模式下，会报出 ReferenceError】

with 这种讲对象及其属性放进一个作用域并同时调配标识符的行为很让人费解。但为了阐明咱们所看到的景象，这是我能给出的最直白的解释了。

另外一个不举荐应用 eval 和 with 的起因是会被严格模式所影响（限度）。with 被齐全禁止，而在保留外围性能的前提下，简洁或非平安的应用 eval 也被禁止了。

三、性能

eval 和 with 会在运行时批改或创立新的作用域，以此来坑骗其余在书写时定义的词法作用域。

你可能会问，那又怎么呢？如果他们能实现更简单的性能，并且代码更具备扩展性，难道不是十分好的性能吗？答案是否定的。

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

但如果引擎在代码中发现了 eval 或 with，他只能简略地假如对于标识符地位的判断都是有效的，因为无奈在词法分析阶段明确晓得 eval 会接管到什么代码，这些代码会如何对作用域进行批改，也无奈晓得传递给 with 用来创立新词法作用域的对象的内容到底是什么。

最乐观的状况是如果呈现了 eval 或 with，所有的优化可能都是无意义的，因而最简略的做法就是齐全不做任何优化。【因为两头有太多的不确定性，那最好的方法就是不动，保持原状】

如果代码中大量应用 eval 或 with，那么运行起来肯定会变得十分慢。无论引擎多聪慧，试图将这些乐观状况的副作用限度在最小范畴内，也无奈防止如果这些优化，代码会运行的更慢的这个事实。

大家还能够扫描上面的二维码，关注我的微信公众号，蜗牛全栈