木灵鱼儿

木灵鱼儿

阅读:160

最后更新:2022/10/18/ 0:42:03

词法作用域

什么是词法作用域

在上文中我们说道作用域的概念,这套规则是用来管理引擎如何在当前作用域以及嵌套的子作用域中根据标识符名称进行变量查找。

而作用域共有两种工作模型:

  1. 词法作用域
  2. 动态作用域

词法作用域是被普遍使用的一种工作模式,也是JavaScript所使用的,而动态作用域也是有语言在使用的,比如:Bash脚本,perl。

词法作用域称之为静态作用域,这个也是由他的实际原理所提现的,具体我们往下看。

词法阶段

在JavaScript编译时,第一个阶段就是词法分析; 简单来说,词法作用域就是定义在词法分析阶段的作用域,换句话说,词法作用域是由你在写代码时将变量和块作用域写在哪里来决定的,因此当词法分析器处理代码时会保持作用域不变(大部分情况下是这样的)。

function foo(a) {
    var b = a * 2;

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

上面这段代码一共有三个作用域,一个是全局作用域,存储foo函数,一个是foo的函数作用域,存放变量a、b、bar函数,第三个是bar函数的作用域,存放变量c

查找

作用域气泡的结构和互相之间的位置关系给引擎提供了足够的位置信息,引擎用这些信息来查找标识符的位置。

在上一个代码片段中,引擎执行 console.log(..) 声明,并查找 a、b 和 c 三个变量的引用。它首先从最内部的作用域,也就是 bar(..) 函数的作用域气泡开始查找。引擎无法在这里找到 a,因此会去上一级到所嵌套的 foo(..) 的作用域中继续查找。在这里找到了 a,因此引擎使用了这个引用。对 b 来讲也是一样的。而对 c 来说,引擎在 bar(..) 中就找到了它。

如果 a、c 都存在于 bar(..) 和 foo(..) 的内部,console.log(..) 就可以直接使用 bar(..)中的变量,而无需到外面的 foo(..) 中查找。

作用域查找会在找到第一个匹配的标识符时停止。在多层的嵌套作用域中可以定义同名的标识符,这叫作“遮蔽效应”(内部的标识符“遮蔽”了外部的标识符)。抛开遮蔽效应,作用域查找始终从运行时所处的最内部作用域开始,逐级向外或者说向上进行,直到遇见第一个匹配的标识符为止。

全局变量会自动成为全局对象(比如浏览器中的 window 对象)的属性,因此可以不直接通过全局对象的词法名称,而是间接地通过对全局对象属性的引用来对其进行访问。

window.a

通过这种技术可以访问那些被同名变量所遮蔽的全局变量。但非全局的变量

如果被遮蔽了,无论如何都无法被访问到。

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

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

欺骗词法作用域

如果词法作用域完全由写代码期间函数所声明的位置来定义,怎样才能在运行时来“修改”(也可以说欺骗)词法作用域呢?

JavaScript有两种机制来实现这个目的,但是这两种方式不但会导致性能下降,还会有安全隐患,它们就是:

  • eval
  • with

eval

eval函数接收一个字符串为参数,并将其的内容视为好像书写在调用eval函数时的位置上一样,该内容享有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;"共享它的作用域,它的第一个作用域就是foo函数作用域,于是在该作用域下创建了一个变量b;这是直接操作了词法作用域,所以当后面的console打印时,在查询b变量时,会优先从foo函数作用域查找,从而得到值3

默认情况下,如果 eval(..) 中所执行的代码包含有一个或多个声明(无论是变量还是数),就会对 eval(..) 所处的词法作用域进行修改。技术上,通过一些技巧(已经超出们的讨论范围)可以间接调用 eval(..) 来使其运行在全局作用域中,并对全局作用域进行修改。但无论何种情况,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(..) 略微安全一些,但也要尽量避免使用。

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

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 被泄漏到全局作用域上了!

o2对象上没有a属性,在with中对a进行赋值的时候,看起来像引用的o2对象上的a属性,但其实它是一个LHS的查询,然后将2赋值给a。

那按道理应该是对o2赋值了一个新属性,但是结果并没有。

这就需要我们了解一下with的实现,它会将传入的对象处理成一个词法作用域,而对象的属性会成为词法作用域中的词法标识符。但是再with的作用域中,var声明或者隐式全局声明,其声明并不会限制在该作用域中,而是被添加到with所处的作用域中。

这也是为什么我们赋值操作的时候赋值到了全局作用域中。

个人测试const、let的声明也不会对with接收的对象赋值新属性,那么with应该只是一个只读已有属性的处理,对于没有的属性,或者说是词法标识符,会直接通过LHS的方式查询并赋值。

在严格模式中,with是被禁用的。

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

可以这样理解,当我们传递 o1 给 with 时,with 所声明的作用域是 o1,而这个作用域中有一个同 o1.a 属性相符的标识符。但当我们将 o2 作为作用域时,其中并没有 a 标识符,因此进行了正常的 LHS 标识符查找。

o2 的作用域、foo(..) 的作用域和全局作用域中都没有找到标识符 a,因此当 a=2 执行时,自动创建了一个全局变量(因为是非严格模式)。

性能

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

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

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

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

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

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

小结

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

JavaScript中有两个机制可以欺骗词法作用域,一个是eval,一个是with。eval可以对代码字符串进行演算,并借此来修改已经生成的静态的词法作用域,这是在运行时。而with则是通过将一个对象当做作用域来处理,将对象的属性作为作用域中的词法标识符,从而创建了一个新的词法作用域,虽然这也是在运行时,但是不是很好使,对象不存在的属性就会导致污染到外部作用域了。

这两个的机制都会导致引擎在编译时无法对作用域查找进行优化,这就导致代码的运行变慢。不推荐使用,或者谨慎使用它们。

版权申明

本文系作者 @木灵鱼儿 原创发布在木灵鱼儿 - 有梦就能远航站点。未经许可,禁止转载。

关于作者

站点职位 博主
获得点赞 1
文章被阅读 160

相关文章