JavaScript中eval和with语句如何影响作用域链的深度探索

前言

在前文《JavaScript作用域深度剖析：从局部到全局一网打尽》中，我们详细解析了作用域的概念，将其定义为一套规则体系，用于管理JavaScript引擎如何在当前作用域及其嵌套的子作用域中，依据标识符名称进行变量查找。

上篇文章入口：JavaScript作用域深度剖析：从局部到全局一网打尽

作用域主要分为两种类型：词法作用域和动态作用域。本文将聚焦于词法作用域，深入探讨其工作原理及特殊情况。

词法阶段

简而言之，词法作用域是指在代码编写阶段（即词法分析阶段）就已确定的作用域。这意味着变量和块级作用域的位置是在代码书写时由开发者决定的，而非运行时动态确定的。

上述代码作用域：

该结构包含整个全局作用域，其中仅包含一个标识符：foo。

该结构包含由foo函数创建的作用域，其中包含三个标识符：a、bar和b。

该结构包含由bar函数创建的作用域，其中仅包含一个标识符：c。

• 在此，我们可以假设每个函数调用都会创建一个新的作用域气泡。
• 需要记住的是：作用域查找过程会在找到第一个匹配的标识符时立即停止。在多层嵌套作用域中，内部作用域可以定义与外部作用域同名的标识符，这种现象被称为“遮蔽效应”，即内部标识符会遮蔽外部同名标识符。
• 作用域查找的基本规则是：查找始终从运行时所处的最内部作用域开始，逐级向外（向上）进行，直到遇到第一个匹配的标识符为止。

无论函数在何处被调用或以何种方式被调用，其词法作用域始终由函数声明时所处的位置决定。

function foo(a) {
var b = a * 2;
function bar(c) {
    console.log(a, b, c);
}
bar(b * 3);
}
foo(2); // 2 4 12

• 词法作用域仅查找一级标识符，例如a、b、c。如果代码中引用了foo.bar.baz，词法作用域查找只会尝试查找foo标识符。一旦找到该变量，对象属性访问规则将接管后续对bar和baz属性的访问。

欺骗词法

JavaScript提供了两种机制来实现对词法作用域的“欺骗”。

eval(不推荐使用)

• JS中的eval(...)函数可以接收一个字符串作为参数。换句话说，在此处传入的字符串内容会被引擎视为在该位置直接编写的代码。基于这一原理，eval(...)通过动态插入代码并假装这些代码在编写时就存在，从而修改词法作用域环境。

在执行eval(...)之后的代码时，引擎并不关心或在意前面的代码是否以动态形式插入进来，也不关心其是否修改了词法作用域环境。引擎只会像往常一样进行词法作用域查找。

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

• 在eval(...)调用中的var b = 3;这段代码会被引擎当作原本就存在于该位置一样处理。由于这段代码声明了一个新的变量b，因此它修改了foo(...)函数的词法作用域。事实上，这段代码在foo(...)内部创建了一个变量b，并遮蔽了外部（全局）作用域中的同名变量。
• 当执行console.log(...)时，引擎会在foo(...)内部找到a和b，但永远无法找到外部的b。因此输出结果为1, 3，而不是正常情况下预期的1, 2。
• 默认情况下，eval(...)中执行的代码若包含一个或多个声明（无论是变量声明还是函数声明），都会修改eval(...)所处的词法作用域。

在严格模式下：eval(...)在运行时拥有自己独立的词法作用域，这意味着其中的声明无法修改外层所在的作用域。

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

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的区别？

  • eval(...)函数接收一个或多个声明的代码，会修改其所处的词法作用域，而with声明实际上是根据你传递给它的对象凭空创建一个全新的词法作用域。
• 另外不推荐使用eval(...)和with(...){...}的原因是会被严格模式所影响(限制)。with被完全禁止，而在保留核心功能的前提下，间接或非安全地使用eval(...)也被禁止了。

性能

• 你可能会问，如果他们能实现更复杂的功能，并且代码更具有扩展性，难道不是非常好的功能吗？答案是否定的。
• JavaScript引擎会在编译阶段进行数项的性能优化。其中有些优化依赖于能够根据代码的词法进行静态分析，并预先确定所有变量和函数的定义位置，才能在执行过程中快速找到标识符。
• 但如果引擎在代码中发现了eval(..)或with，它只能简单地假设关于标识符位置的判断都是无效的，因为无法在词法分析阶段明确知道eval(..)会接收到什么代码，这些代码会如何对作用域进行修改，也无法知道传递给with用来创建新词法作用域的对象的内容到底是什么。
• 最悲观的情况是如果出现了eval(..)或with，所有的优化可能都是无意义的，因此最简单的做法就是完全不做任何优化。
• 如果代码中大量使用eval(..)或with，那么运行起来一定会变得非常慢。无论引擎多聪明，试图将这些悲观情况的副作用限制在最小范围内，也无法避免如果没有这些优化，代码会运行得更慢这个事实。

小结

• 词法作用域意味着作用域是由书写代码时函数声明的位置来决定。

• JavaScript有两种机制可欺骗词法作用域：eval(...)和with(...){...}。

  • eval(...):修改所处位置的词法作用域。
  • with(...){...}:将对象的引用当做作用域来处理，将对象中的属性当做作用域中标识符来处理，从而创建一个新的词法作用域。
• eval(...)和with(...){...}这两个机制的副作用是引擎无法在编译时对作用域查找进行优化的。所以,不要使用他们。

特殊字符描述：

• 问题标注Q:(question)
• 答案标注R:(result)
• 注意事项标准：A:(attention matters)
• 详情描述标注：D:(detail info)
• 总结标注：S:(summary)
• 分析标注：Ana:(analysis)
• 提示标注：T:(tips)

以上就是JavaScript中eval和with语句如何影响作用域链的深度探索的详细内容，更多关于JS eval with作用域链的资料请关注本站其它相关文章！