一、词法阶段
词法作用域，就是定义在词法阶段的作用域，也是你再写代码时将变量和块作用域写在哪里来决定的。
看下如下代码
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
2.包含着foo做创建的作用域，其中有三个标识符：a,bar,b
3.包含着bar所创建的作用域，其中只有一个标识符c
在这个代码片段中，引擎执行console.log()，并查找a,b,c三个变量的引用，它首先从最内部的作用域bar中开始查找，找到了c，没有其他的就去上一层foo中继续查找，找了a,b，如果a，c都存在与bar和foo中，那他会直接使用bar中的变量，无需再去foo中查找
总之，作用域查找始终从运行时所需的最内部作用域开始，逐级向上进行，直到遇见第一个匹配的标识符为止。
全局变量会自动成为全局对象（在浏览器中是window）的属性，因此可以不直接通过全局对象的词法名称，而是简介的通过对全局属性的引用来对其进行访问window.a
无论函数在哪里被调用，也无论它如何被调用，它的词法作用域都治由函数声明时所处的位置决定
词法作用域只会查找以及标识符，比如a, b, 如果代码中引用了foo.bar.baz，词法作用域查找只会视图查找foo，找到这个变量后，对象属性访问规则会分别接管对bar，baz属性的访问。
二、欺骗词法
当然，凡事无绝对，在运行时也可以‘修改’作用域。
在JavaScript中有两种机制来实现这个目的，这两种都会导致性能下降。见过的次数不多，做了解使用。
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这段代码会被当做本来就在那里一样来处理，由于那段代码声明了一个新的变量b，因此他对foo的词法作用域进行了修改，所以当console.log执行的时候，会在foo内部同时找到a,b，因此会输出1，3，而不是成情况下输出的1，2
在严格模式中，eval()在运行时有自己的词法作用域，意味着其中的声明无法修改所在的作用域，所以上段代码在严格作用域下回输出1，2
new Function(..)函数的行为也很类似，最后一个参数可以接受代码字符串，并将其转化为动态生成的函数（前面的参数是这个新生成的函数的形参）。这种构建函数的语法比eval(..)略微安全一些，但也要尽量避免使用。
width
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){
width (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被泄漏到全局作用域上了
这个例子中创建了o1,o2两个对象，其中一个具有a属性，另一个没有。foo函数接受一个obj参数，该参数是一个对象引用，并对这个对象引用执行了width(obj){}。
当我们将o1传递进去，a=2赋值操作找到了o1.a并将2赋值给它，而当o2传递进去，o2并没有a属性，因此不会创建这个属性，o2.a保持undefined，但是a=2却执行了LHS引用（查看《你不知道的JavaScript》-作用域是什么(01)），创建了一个全局变量a，并将2赋值给它（非严格模式）。
可以这样理解，当我们传递o1给with时，with所声明的作用域是o1，而这个作用域中含有一个同o1.a属性相符的标识符。但当我们将o2作为作用域时，o2的作用域，foo的作用域，全局作用域都没有找到标识符a，因此进行了正常的LHS标识符查找，自动创建了一个全局变量（非严格模式）。
性能
eval(..)和with会在运行时修改或创建新的作用域，以此来欺骗其他在书写时定义的词法作用域。
你可能会问，那又怎样呢？如果它们能实现更复杂的功能，并且代码更具有扩展性，难道不是非常好的功能吗？答案是否定的。
JavaScript引擎会在编译阶段进行数项的性能优化。其中有些优化依赖于能够根据代码的词法进行静态分析，并预先确定所有变量和函数的定义位置，才能在执行过程中快速找到标识符。
但如果引擎在代码中发现了eval(..)或with，它只能简单地假设关于标识符位置的判断都是无效的，因为无法在词法分析阶段明确知道eval(..)会接收到什么代码，这些代码会如何对作用域进行修改，也无法知道传递给with用来创建新词法作用域的对象的内容到底是什么。最悲观的情况是如果出现了eval(..)或with，所有的优化可能都是无意义的，因此最简单的做法就是完全不做任何优化。
如果代码中大量使用eval(..)或with，那么运行起来一定会变得非常慢。无论引擎多聪明，试图将这些悲观情况的副作用限制在最小范围内，也无法避免如果没有这些优化，代码会运行得更慢这个事实。
