昨天圣诞节，没有写，今天写两篇。奥利给！---现在是2021-1-4 还好不算晚，才隔了几天。
词法作用域
在第一章中，我们将“作用域”定义为一套规则，这套规则用来管理引擎如何在当前作用 域以及嵌套的子作用域中根据标识符名称进行变量查找。
词法阶段
大部分标准语言编译器的第一个工作阶段叫作词法化（也叫单词化）。回 忆一下，词法化的过程会对源代码中的字符进行检查，如果是有状态的解析过程，还会赋 予单词语义。
这个概念是理解词法作用域及其名称来历的基础。
简单的说，词法作用域就是定义在词法阶段的作用域。
换句话说，词法作用域是由你在写 代码时将变量和块作用域写在哪里来决定的，因此当词法分析器处理代码时会保持作用域 不变（大部分情况下是这样的）。
看下面的例子：
function foo(a){//-----------1
var b = a * 2;//---------2
function bar(c){//-------3
console.log(a,b,c);
}
bar(b * 3);
}
foo(2);//2,4,12
考虑上面的代码，有三个逐级嵌套的作用域。让我们来一一说明一下。
- 包含着整个全局作用域，其中一个标识符：
foo。 - 包含着
foo所创建的作用域，其中有三个标识符：a,bar,b. - 包含着
bar所创建的作用域，其中只有一个标识符c.
可以看到bar的作用域完全包含在foo所创建的气泡中。
查找
作用域气泡的结构和互相之间的位置关系给引擎提供了足够的位置信息，引擎用这些信息来查找标识符的位置。
作用域查找始终会从运行时所处的最内部作用域开始，逐级向外部或者向上进行，知道遇见第一个匹配的标识符为止。
作用域查找会在找到的第一个匹配的标识符时停止。在多层的嵌套作用域中可以定义同名的 标识符，这叫作“遮蔽效应”（内部的标识符“遮蔽”了外部的标识符）。
全局变量会自动成为全局对象(比如浏览器中的window对象)的属性。因此可以不直接通过全局对象的词法名称，而是间接地通过全局对象的引用来对其进行访问。
window.a
通过这种技术可以访问那些被同名变量所遮蔽的全局变量。但非全局的变量如果被遮蔽了，无论如何都无法被访问到。
请记住这一点：
无论函数在哪里被调用，也无论如何被调用。它的词法作用域都只由函数所声明时所处的位置决定。
欺骗词法作用域
如果词法作用域完全由写代码期间函数所声明的位置来定义，怎样才能在运行时来修改(欺骗)词法作用域呢？
有两种机制可以做到，但是都强烈不推荐使用。
欺骗词法作用域会导致性能下降。
eval 函数
eval函数可以接受一个字符串为参数，并将其中的内容视为好像在书写时就存在于程序中的这个位置的代码。
也就是说，你可以在你写的代码中用程序生成代码并运行，就好像代码是写在那个位置的一样。
根据这个原理来理解eval(...)，它是如何通过代码欺骗和假装书写时也就是词法期代码就在，来实现修改词法作用环境的。这个原理可谓简单易懂。
在执行 eval(..) 之后的代码时，引擎并不“知道”或“在意”前面的代码是以动态形式插 入进来，并对词法作用域的环境进行修改的。引擎只会如往常地进行词法作用域查找。
function foo(str,a){
eval(str);
console.log(a,b);
}
var b = 2;
foo("var b = 3",1);
//VM358:2 Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive:
我们在foo函数中使用eval函数，把str变量包裹，做了处理。所以在调用foo函数的时候，我们第一个参数传入的是"var b = 3",经过eval的处理以后，我们在eval函数的位置真的声明一个b的变量。并且遮蔽了外部(全局)作用域中同名变量。
在JavaScript中还有一些其他的功能效果和eval很相似
-
setTimeout(...)和setInterval(...)的第一个参数可以字符串。字符串的内容可以被解释为一段动态生成的 函数代码。这 -
new Function(...)最后一个参数可以接受代码字符串，并将其转 化为动态生成的函数（前面的参数是这个新生成的函数的形参）。
不要这样玩。
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 被泄漏到全局作用域上了！
这个例子中创建了 o1 和 o2 两个对象。其中一个具有 a 属性，另外一个没有。foo(..) 函 数接受一个 obj 参数，该参数是一个对象引用，并对这个对象引用执行了 with(obj) {..}。 在 with 块内部，我们写的代码看起来只是对变量 a 进行简单的词法引用，实际上就是一个 LHS 引用（查看第 1 章），并将 2 赋值给它。
当我们将 o1 传递进去，a＝2 赋值操作找到了 o1.a 并将 2 赋值给它，这在后面的 console. log(o1.a) 中可以体现。而当 o2 传递进去，o2 并没有 a 属性，因此不会创建这个属性， o2.a 保持 undefined。
但是可以注意到一个奇怪的副作用，实际上 a = 2 赋值操作创建了一个全局的变量 a。这 是怎么回事？
with 可以将一个没有或有多个属性的对象处理为一个完全隔离的词法作用域，因此这个对 象的属性也会被处理为定义在这个作用域中的词法标识符。
尽管 with 块可以将一个对象处理为词法作用域，但是这个块内部正常的 var 声明并不会被限制在这个块的作用域中，而是被添加到 with 所处的函数作 用域中。
eval(..) 函数如果接受了含有一个或多个声明的代码，就会修改其所处的词法作用域，而 with 声明实际上是根据你传递给它的对象凭空创建了一个全新的词法作用域.
可以这样理解，当我们传递 o1 给 with 时，with 所声明的作用域是 o1，而这个作用域中含 有一个同 o1.a 属性相符的标识符。但当我们将 o2 作为作用域时，其中并没有 a 标识符， 因此进行了正常的 LHS 标识符查找（查看第 1 章）。
o2 的作用域、foo(..) 的作用域和全局作用域中都没有找到标识符 a，因此当 a＝2 执行 时，自动创建了一个全局变量（因为是非严格模式）
with 这种将对象及其属性放进一个作用域并同时分配标识符的行为很让人费解。但为了说 明我们所看到的现象，这是我能给出的最直白的解释了。
另外一个不推荐使用 eval(..) 和 with 的原因是会被严格模式所影响（限 制）。with 被完全禁止，而在保留核心功能的前提下，间接或非安全地使用 eval(..) 也被禁止了。
小结:
词法作用域意味着作用域是由书写代码时函数声明的位置来决定的。编译的词法分析阶段 基本能够知道全部标识符在哪里以及是如何声明的，从而能够预测在执行过程中如何对它 们进行查找。
JavaScript 中有两个机制可以“欺骗”词法作用域：eval(..) 和 with。前者可以对一段包 含一个或多个声明的“代码”字符串进行演算，并借此来修改已经存在的词法作用域（在 运行时）。后者本质上是通过将一个对象的引用当作作用域来处理，将对象的属性当作作 用域中的标识符来处理，从而创建了一个新的词法作用域（同样是在运行时）。
这两个机制的副作用是引擎无法在编译时对作用域查找进行优化，因为引擎只能谨慎地认 为这样的优化是无效的。使用这其中任何一个机制都将导致代码运行变慢。不要使用它们。
网友评论