JS中欺骗词法作用域的eval和with详解

作者:异步漫步

时间:2026-10-31

浏览:637

本文深入解析JavaScript中eval和with如何动态修改或创建词法作用域,揭示其通过欺骗静态分析导致引擎放弃性能优化的机制。尽管eval在严格模式下行为受限,with会泄漏变量至外层作用域,两者均因严重性能损耗而不推荐使用。

文章目录

1、词法作用域

简单来说,词法作用域是指在代码编写阶段就已经确定的作用域范围。这意味着变量和块级作用域的位置在编码时即已固定,因此当词法分析器处理代码时,作用域结构通常保持不变(在大多数情况下)。

参考以下代码示例:

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。中间层气泡对应由 foo 函数创建的作用域,内部包含三个标识符:a、bar 和 b。最内层气泡则由 bar 函数创建,仅包含标识符:c。

这些作用域气泡的位置由对应作用域块的代码书写位置决定,它们呈现逐级包含的关系。

2、欺骗词法

如果词法作用域完全由函数声明时的代码位置决定,那么如何在运行时“修改”(或称为欺骗)词法作用域呢? JavaScript 提供了两种实现此目的的机制。社区普遍观点认为,在代码中使用这两种机制并非明智之举。然而,相关的争论往往忽略了一个关键点:欺骗词法作用域会导致程序性能下降。

2.1 eval

JavaScript 中的 eval(…) 函数接收一个字符串参数,并将其内容视为在代码编写时就存在于该位置的代码。换言之,你可以动态生成代码并在运行时执行,其效果等同于在编写代码时直接写在该位置。

当执行 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,从而遮蔽了外部(全局)作用域中的同名变量。

当 console.log(…) 执行时,会在 foo(…) 内部同时找到 a 和 b,但无法找到外部的 b。因此输出结果为“1, 3”,而非正常情况下预期的“1, 2”。

在严格模式的程序中,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.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 被泄漏到全局作用域上了!

如果 eval(…) 函数接受了包含一个或多个声明的代码,它会修改所处的词法作用域;而 with 声明实际上是根据传递给它的对象凭空创建了一个全新的词法作用域。

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

2.3 性能

eval(…) 和 with 会在运行时修改或创建新的作用域,以此欺骗其他在书写时定义的词法作用域。 你可能会问,那又怎样呢?如果它们能实现更复杂的功能,并且代码更具扩展性,难道不是非常好的功能吗?答案是否定的。

JavaScript 引擎会在编译阶段进行多项性能优化。其中一些优化依赖于根据代码的词法进行静态分析,并预先确定所有变量和函数的定义位置,从而在执行过程中快速查找标识符。 但如果引擎在代码中发现了 eval(…) 或 with,它只能简单地假设关于标识符位置的判断均无效,因为无法在词法分析阶段明确知道 eval(…) 会接收到什么代码,这些代码会如何修改作用域,也无法知道传递给 with 用来创建新词法作用域的对象内容究竟是什么。

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

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

到此这篇关于JS中欺骗词法作用域的eval和with的文章就介绍到这了,更多相关js词法作用域内容请搜索本站以前的文章或继续浏览下面的相关文章希望大家以后多多支持本站!

实用工具推荐

电子包浆

绿化、压缩、噪点和虚拟水印,自由调节做旧程度。

使用 ›
图片压缩

选择画质和输出格式,预览压缩前后的大小。

使用 ›
相关文章