先看下面一段代码：
代码执行的结果是：
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 中，花括号并不代表一个独立的作用域，循环体中定义的变量，循环体外依然可能访问到（在同一个执行环境中）
看下面例子：
结果是 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 表达式，也不应该省略花括号。这些良好的编程习惯不仅可以提到代码的一致性，而且可以防止解析器改变代码行为的错误处理。