js 作用域,变量提升

先看下面一段代码:

 1 var a = 0;
 2 alert("1st alert : a = " + a);
 3 function fun(){
 4     alert("2nd alert : a = " + a);
 5     var a = 1;
 6     setTimeout(function(){
 7         alert("3rd alert : a = " + a);
 8         a = 2;
 9     },1000);
10     a = 3;
11     setTimeout(function(){
12         alert("4th alert : a = " + a);
13         a = 4;
14     },4000);
15 }
16 fun();
17 alert("5th alert : a = " + a);

代码执行的结果是:

1st alert : a = 0

2nd alert : a = undefined

5th alert : a = 0

3rd alert : a = 3

4th alert : a = 2

疑问1:对于 2nd alert 而言,为什么 a 的值是 undefined ? 

首先来看 JS 的执行环境和作用域。

执行环境(executing context)定义了变量或函数有权访问的其他数据。在 JS 中,有两种执行环境,一种是全局环境,也就是 Web 浏览器中的 window 对象,而另一种就是函数的执行环境。

在执行环境中存在一个变量对象,这个对象保存了环境中定义的所有变量和函数。

当代码在执行的时候,会创建变量对象的一个作用域链,作用域链的前端是当前环境的变量对象,然后依次是外层环境的变量对象,逐层向外直到全局执行环境。

在标识符的解析过程中,会从前端开始沿着作用域链一级一级搜索,直到找到标识符或搜索完全局环境为止。

所以在 JS 中,花括号并不代表一个独立的作用域,循环体中定义的变量,循环体外依然可能访问到(在同一个执行环境中)

看下面例子:

1 var a = 0;
2 function fun(){
3     alert("a=" + a);
4 }
5 fun();

结果是 a=0

这就是因为在调用 fun 函数的时候,搜索标识符 a 并无法在本执行环境中找到,但是通过作用域链搜索到外层作用域的时候找到了 a

而为什么第一个例子中,2nd alert , a 的值是 undefined ?

这是因为在 JS 中,使用 var 声明的变量或者使用函数声明方式声明的函数(不是函数表达式)会自动被添加到最接近的环境中,也就是所谓的变量提升(hoisting)。什么意思,相当于上面的 fun 函数定义中前两行的代码变成:

1 function fun(){
2     var a;
3     alert("2nd alert : a = " + a);
4     a = 1;
5     //other codes
6 }

所以在搜索标识符 a 的时候,在本执行环境中就可以搜索到,而不用搜索到外层环境,所以在 2nd alert 中,a 的值就是 undefined。

 

而对于函数的定义也是如此,这就是为什么使用函数声明的方式时,调用函数可以放在函数声明之前,而使用函数表达式的时候却不可以的原因了。

疑问 2:5th alert 为什么在 3rd 和 4th 之前?

这是因为 JavaScript 引擎对于其任务队列是单线程处理的,而 setTimeout 属于异步代码,只有当 JS 线程中没有同步代码的时候才会执行异步代码。

1 setTimeout(function(){while(true){}},1000);
2 setTimeout(function(){alert(‘end 2‘);},2000);
3 setTimeout(function(){alert(‘end 1‘);},100);
4 alert(‘end‘);

所以在上面的代码中,首先出现的是 end ,其次是 end 1,之后就再也不会出现。因为在第一个 setTimeout 函数中死循环占用了 JS 引擎的单线程,阻塞了其他进程。

 

setTimeout的常见用法是让某个方法延迟执行。我们知道,setTimeout方法是挂在window对象下的。超时调用的代码都是在全局作用域中执行的,因此函数中this的值在非严格模式下指向window对象,在严格模式下是undefined

自动分号插入

尽管 JavaScript 有 C 的代码风格,但是它强制要求在代码中使用分号,实际上可以省略它们。

JavaScript 不是一个没有分号的语言,恰恰相反上它需要分号来就解析源代码。因此 JavaScript 解析器在遇到由于缺少分号导致的解析错误时,会自动在源代码中插入分号。

var foo = function() {
} // 解析错误,分号丢失
test()

自动插入分号,解析器重新解析。

var foo = function() {
}; // 没有错误,解析继续
test()

自动的分号插入被认为是 JavaScript 语言最大的设计缺陷之一,因为它改变代码的行为。

工作原理(How it works)

下面的代码没有分号,因此解析器需要自己判断需要在哪些地方插入分号。

(function(window, undefined) {
    function test(options) {
        log(‘testing!‘)

        (options.list || []).forEach(function(i) {

        })

        options.value.test(
            ‘long string to pass here‘,
            ‘and another long string to pass‘
        )

        return
        {
            foo: function() {}
        }
    }
    window.test = test

})(window)

(function(window) {
    window.someLibrary = {}

})(window)

下面是解析器"猜测"的结果。

(function(window, undefined) {
    function test(options) {

        // Not inserted, lines got merged
        log(‘testing!‘)(options.list || []).forEach(function(i) {

        }); // <- 插入分号

        options.value.test(
            ‘long string to pass here‘,
            ‘and another long string to pass‘
        ); // <- 插入分号

        return; // <- 插入分号, 改变了 return 表达式的行为
        { // 作为一个代码段处理

            // a label and a single expression statement
            foo: function() {}
        }; // <- 插入分号
    }
    window.test = test; // <- 插入分号

// The lines got merged again
})(window)(function(window) {
    window.someLibrary = {}; // <- 插入分号

})(window); //<- 插入分号

注意: JavaScript 不能正确的处理 return 表达式紧跟换行符的情况,虽然这不能算是自动分号插入的错误,但这确实是一种不希望的副作用。

解析器显著改变了上面代码的行为,在另外一些情况下也会做出错误的处理

前置括号(Leading parenthesis)

在前置括号的情况下,解析器不会自动插入分号。

log(‘testing!‘)
(options.list || []).forEach(function(i) {})

上面代码被解析器转换为一行。

log(‘testing!‘)(options.list || []).forEach(function(i) {})

log 函数的执行结果极大可能不是函数;这种情况下就会出现 TypeError 的错误,详细错误信息可能是 undefined is not a function

结论(In conclusion)

建议绝对不要省略分号,同时也提倡将花括号和相应的表达式放在一行,对于只有一行代码的 if 或者 else 表达式,也不应该省略花括号。这些良好的编程习惯不仅可以提到代码的一致性,而且可以防止解析器改变代码行为的错误处理。

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。