转载

理解ES6中的暂时死区(TDZ)

Temporal Dead Zone(TDZ)是ES6(ES2015)中对作用域新的专用语义。TDZ名词并没有明确地写在ES6的标准文件中,一开始是出现在 ES Discussion 讨论区中,是对于某些遇到在区块作用域绑定早于声明语句时的状况时,所使用的专用术语。

以英文名词来说明,Temporal是"时间的、暂时的"意义,Dead Zone则是"死区",意指"电波达不到的区域"。所以TDZ可以翻为"时间上暂时的无法达到的区域",简称为"时间死区"或"暂时死区"。

let/const与var

在ES6的新特性中,最容易看到TDZ作用就是在let/const的使用上,let/const与var的主要不同有两个地方:

  • let/const是使用区块作用域;var是使用函数作用域

  • 在let/const声明之前就访问对应的变量与常量,会抛出 ReferenceError 错误;但在var声明之前就访问对应的变量,则会得到 undefined

console.log(aVar) // undefined
console.log(aLet) // causes ReferenceError: aLet is not defined
var aVar = 1
let aLet = 2

根据ES6标准中对于let/const声明的章节 13.3.1 ,有以下的文字说明:

The variables are created when their containing Lexical Environment is instantiated but may not be accessed in any way until the variable’s LexicalBinding is evaluated.

意思是说由let/const声明的变量,当它们包含的词法环境(Lexical Environment)被实例化时会被创建,但只有在变量的词法绑定(LexicalBinding)已经被求值运算后,才能够被访问。

注: 这里指的"变量"是let/const两者,const在ES6定义中是constant variable(固定的变量)的意思。

说得更明白些,当程序的控制流程在新的作用域(module, function或block作用域)进行实例化时,在此作用域中的用let/const声明的变量会先在作用域中被创建出来,但因此时还未进行词法绑定,也就是对声明语句进行求值运算,所以是不能被访问的,访问就会抛出错误。所以在这运行流程一进入作用域创建变量,到变量开始可被访问之间的一段时间,就称之为TDZ(暂时死区)。

以上面解说来看,以let/const声明的变量,的确也是有提升(hoist)的作用。这个是很容易被误解的地方,实际上以let/const声明的变量也是会有提升(hoist)的作用。提升是JS语言中对于变量声明的基本特性,只是因为TDZ的作用,并不会像使用var来声明变量,只是会得到 undefined 而已,现在则是会直接抛出 ReferenceError 错误,而且很明显的这是一个在运行期间才会出现的错误。

用一个简单的例子来说明let声明的变量会在作用域中被提升,就像下面这样:

let x = 'outer value'

(function() {
  // 这里会产生 TDZ for x
  console.log(x) // TDZ期间访问,产生ReferenceError错误
  let x = 'inner value' // 对x的声明语句,这里结束 TDZ for x
}())

在例子中的IIFE里的函数作用域,变量x在作用域中会先被提升到函数区域中的最上面,但这时会产生TDZ,如果在程序流程还未运行到x的声明语句时,算是在TDZ作用的期间,这时候访问x的值,就会抛出 ReferenceError 错误。

在let与const声明的章节 13.3.1 接着的几句,说明有关变量是如何进行初始化的:

A variable defined by a LexicalBinding with an Initializer is assigned the value of its Initializer’s AssignmentExpression when the LexicalBinding is evaluated, not when the variable is created. If a LexicalBinding in a let declaration does not have an Initializer the variable is assigned the value undefined when the LexicalBinding is evaluated.

这几句比较重点的部份是关于初始化的过程。以let/const声明的变量或常量,必需是经过对声明的赋值语句的求值后,才算初始化完成,创建时并不算初始化。如果以let声明的变量没有赋给初始值,那么就赋值给它 undefined 值。也就是经过初始化的完成,才代表着TDZ期间的真正结束,这些在作用域中的被声明的变量才能够正常地被访问。

下面这个例子是一个未初始化完成的结果,它一样是在TDZ中,也是会抛出 ReferenceError 错误:

let x = x

因为右值(要被赋的值),它在此时是一个还未被初始化完成的变量,实际上我们就在这一个同一表达式中要初始化它。

注: TDZ最一开始是为了const所设计的,但后来的对let的设计也是一致的,例子中都用let来说明会比较容易。

注: 在ES6标准中,对于const所声明的识别子仍然也经常为variable(变量),称为constant variable(固定的变量)。以const声明所创建出来的常量,在JS中只是不能再被赋(can't re-assignment),并不是不可被改变(immutable)的,这两种概念仍然有很大的差异。

函数的传参预设值

TDZ作用在ES6中,很明确的就是与区块作用域(block scope),以及变量/常量的要如何被初始化有关。实际上在许多ES6新特性中都有出现TDZ作用,而另一个常会被提及的是函数的传参预设值中的TDZ作用。

下面的例子可以看到在传参预设值的识别名称,在未经初始化(有赋到值)时,它会进入TDZ而产生错误,而这个错误是只有在函数调用时,要使用到传参预设值时才会出现:

function foo(x = y, y = 1) {
  console.log(y)
}

foo(1) // 这不会有错误
foo(undefined, 1) // 错误 ReferenceError: y is not defined
foo() // 错误 ReferenceError: y is not defined

从这个例子可以知道TDZ的作用,实际上在ES6中到处都有类似的作用。

传参预设值有另一个作用域的议题会被讨论,就是对于传参预设值的作用域,到底是属于"全局作用域"还是"函数中的作用域"的议题,目前看到比较常见的说法是,它是处于"中介的作用域",夹在这两者之间,但仍然会互相影响。中介的作用域的一个例子,是使用其他函数作为传参的预设值,这通常会是一个callback(回调、回呼)函数,一般的情况没什么特别,但涉及作用域时互相影响的情况下会不易理解。下面这个例子 来自这里 :

let x = 1

function foo(a = 1, b = function(){ x = 2 }){
  let x = 3
  b()
  console.log(x)
}

foo()

console.log(x)

这个例子中的最后结果,在函数foo中输出的x值到底是1、2还是3?另外,在最外围作用域的x最后会被改变吗?

函数中的x输出结果不可能是1,这是很明确的,因为函数区块中有另一个x的声明与赋值 let x = 3 语句,这两个都有可能被运行产生作用。剩下的是传参预设值中的那个函数,是不是会变量到函数区块中的x值的问题。另一个是,在全局中的那个x变量,会不会被改变,这也是一个问题。

按照这个例子的出处文档的说明,作者认为答案是3与1。但是根据我的实验,下面的几个浏览器与编译器并不是这样认为:

  • babel编译器: 2与1

  • Closure Compiler: 3与2

  • Google Chrome(v55): 3与2

  • Firefox(v50): 2与1

  • Edge(v38): 3与2

实际测试的结果,怎么都不会有3与1的答案,要不就3与2,要不就2与1。

3与2的答案是让b传参的 x = 2 运行出来,但因为受到中介作用域的影响,因此干扰不到函数中的原本区块中的作用域,但会影响到全局中的x变量。也就是基本上认定函数预设值中的那个callback中的作用域与全局(或外层)有关系。

2与1的答案则是倒过来,只会影响到函数中的区块,对全局(或外层)没有影响。

所以除非中介作用域,有自己独立的作用域,完全与函数区块中的作用域与全局都不相干,才有可能产生3与1的结果,这是这篇文档的作者所认为的。

这个函数预设值的作用域因为实作不同,造成两种不同的结果,但如果以Chrome(v55)与Firefox(v50)来实验,在TDZ期间的抛出错误的行为基本上会一致,但Firefox有两种不同的错误消息,例如下面的几个例子:

// Chrome: ReferenceError: x is not defined
// Firefox: ReferenceError: x is not defined
function foo(a = 1, b = function(){ let x = 2 }){
  b()
  console.log(x)
}
foo()
// Chrome: ReferenceError: x is not defined
// Firefox: ReferenceError: can't access lexical declaration `x' before initialization
function foo(a = 1, b = function(){ x = 2 }){
  b()
  console.log(x)
}
foo()
let x = 1
// Chrome: ReferenceError: x is not defined
// Firefox: ReferenceError: can't access lexical declaration `x' before initialization
function foo(a = 1, b = function(){ x = 2 }){
  b()
  console.log(x)
  let x = 3
}
foo()

不管如何,这个作用域的影响仍然是有争议的,目前并没有统一的答案。这代表ES6虽然标准定好了,但里面的一些新特性仍然有实作细节的差异,未来有可能这些差异才会慢慢一致。但对一般的开发者来说,因为知道了有这些情况,所以要尽量避免,以免产生不兼容的情况。

要如何避免这种情况?最重要的就是,"不要在传参预设值中作有副作用的运算",上面的 function(){ x = 2 } 是有副作用的,它有可能会改变函数区块中,或是全局中的同名称变量,而在整个代码中,可能会互相影响的作用域彼此间,避免使用同样识别名称的变量,这也是一个很基本的撰写规则。

注: 本节的内容可以参考这几篇文档 TEMPORAL DEAD ZONE (TDZ) DEMYSTIFIED 、 ES6 Notes: Default values of parameters 与这个 Default parameters intermediate scope 讨论文。

TDZ的其它议题(陷阱)

typeof语句

对TDZ期间中的变量/常量作任何的访问动作,一律会抛出错误,使用 typeof 的语句也一样。如下面的例子:

typeof x // "undefined"

{
  // TDZ
  typeof x // ReferenceError
  let x = 42
}

但有些开发者会认为像 typeof 这样的语句,需要被用来判断变量是否存在,不应该是导致抛出错误,所以有部份反对的声音,认为它让 typeof 语句变得不安全,会造成使用上的陷阱。实际上这原本就是TDZ的设计,变量本来就不该在没声明完成前访问,这是为了让JS运行更为合理的改善设计,只是之前JS在这一部份是有缺陷的作法,实际上会用 typeof 与undefined来判别变量/常量存在与否的方式,通常是对于全局变量的才会作的事情。

TDZ期间抛出的错误是运行阶段的错误

TDZ期间所抛出的错误,是一种运行阶段的错误,因为TDZ除了作用域的绑定过程外,还需要有变量/常量初始化的过程,才会创建出TDZ的期间。下面两个例子就可以看到TDZ的错误需要真正运行到才会出现:

// 这个例子会有因TDZ抛出的错误
function f() { return x }
f() // ReferenceError
// 这个例子不会有错误
function f() { return x }
let x = 1

那这会有什么问题出现?因为要能侦测出代码中的因TDZ造成的错误,唯有透过静态的代码分析工具,或是要真正调用到函数运行里面的代码,才会产生错误,这将会让TDZ在编译工具中实作变得困难。

不过只要你理解TDZ的设计,就知道只能这样设计,初始化过程原本就只会在调用运行阶段作这事,这部份还是只能靠其它工具来补强。

支持ES6的浏览器上的运行效能

在 ES Discussion 上对于let/const的效能很早以前就已经有些批评的,认为在浏览器上实作的结果,由于TDZ的设计,会让let相较于var的效能至少要慢5%。

上面这篇贴文是在4年前所发表,就算是当时的实验性质的实作在JS引擎上,没有经过优化,实际上真的效能有差这么大也不得而知。加上let本身在for回圈上有另外的花费,与var的设计不同,这两个比较当然会有所不同,是不是都是TDZ影响的也不知道。

以最近在讨论区中的 let与var的效能 比较议题来看,let的运行效率只有在某些情况下(for回圈中)会慢var很多,在基本的内部作用域测试反而是快过var的,当然这也是要视不同的浏览器与版本而定。

题外话是,在其它的回答中就有明确的指出,会促使加入TDZ的主因是针对const,而不是let。但最后TC39的决议是让let与const都有一致的TDZ设计。

ES6到ES5的编译

ES6中的许多新式的设计仍然是很新的JS语言特性,目前ES6仍然需要依赖如babel之类的编译器,将ES6语法编译到ES5,来进行在浏览器上运行前的最后编译。

这些编译器对于TDZ是会如何编译?答案是目前"并不会直接编译"。

以babel来说,它预设不会编译出具有TDZ的代码,它需要额外使用 babel-plugin-transform-es2015-block-scoping 或编译时的选项 es6.blockScopingTDZ ,才会将TDZ与区域作用域的功能编译出来。基本上这应该属于实验性质的,而且现在在使用上还有满多问题的。ES5标准中原本就没这种设计,所以说实在硬要使用也是麻烦,TDZ会造成的错误是运行期间的错误,对于编译器来说,在实作上也有一定的难度。

原文  https://segmentfault.com/a/1190000008213835
正文到此结束
Loading...