20 | (0, eval)("x = 100") ：一行让严格模式形同虚设的破坏性设计（上）

作者回复: 是这样的，全局环境GlobalEnv是一个复合环境，包括一个由global构成的对象环境(objEnv)和一个一般的声明环境(declsEnv)，它是双环境组成的，统一交付一个环境存取界面。这个是它的结构（objEnv/declsEnv很类似或者是直接对应你在DevTools's scope中看到的Global/Script）。 let/const声明会放在declsEnv里面，而var的变量名会通过objEnv来声明，这个之前也讲过了。它们组合而成的，整个的环境叫GlobalEnv，并且用来作为ScriptCtx中的变量环境和词法环境，并且后面的两种环境都指向“同一个”GlobalEnv，没有差别，也不会分开。——再次强调，ScriptCtx的“变量环境和词法环境”是相同的。 但是你在使用eval的时候，对“变量环境和词法环境”的使用却是有所不同的。eval会自己创建一个执行上下文，称为evalCtx。那么这个上下文中也有“变量环境和词法环境”，它们指向却是不同的。evalCtx.LexicalEnvironment将是新创建的、独立的，用来存放eval(x)的`x`中声明的const/let，并且当eval结束时，就销毁了。而evalCtx.VariableEnvironment将指向全局的ScriptCtx.VariableEnvironment，这样也就指向了GlobalEnv。所以在`x`中声明的var，就丢到了全局环境中，也就写到了global这个对象上面，不会受eval结束的影响。这就是它的完整机制了。 你可以写一个test.js用node运行起来看看： ``` // 运行中x, y有值 eval('var x = 100; let y = 200; console.log(x, y)'); // eval结束后x留在了全局，而y没有了 console.log(typeof x, typeof y) ``` 关于在浏览器环境中的情况，也与这个逻辑没差。只不过DevTools展示那些内部组件（例如Script/Globa/Scope）的时候，使用的术语或者展示方式跟ECMAScript约定不一致罢了。

作者回复: 1. 这个问题我之前没细想过。但是ES5本来也不是一个突然提出来的东西，它其实是在ES4的基础上的一次“缩减”，并为以后的ES6之类做一个奠基性的事情。所以他们应该是考虑到了今后对词法环境的需求，并且事实上严格模式的提出，也是这样的目的，都是为后面的语言设计做一些基础性的工作。此外，事实上在当时他们已经有意地在设计和使用词法环境了，例如try...catch(x)中的这个x，在IE和Firefox里面它的作用域一直就不同，IE是用变量环境的，而Firefox是用词法环境的。这个争端早于ES5之前就有的，所以问题出在哪里，以及将来需要做成怎样，这些在当时应该已经有明确的选择了，而ES5只不过把其中的冰山一角显露出来了而已。 2. var的多次声明只算第一次，其它的都是按赋值处理的（准确地说，是按多次绑定值处理的）。 3. 环境跟作用域的关系，浅层地说，它是后者的一个扩展版本的实现。——这样理解并没有问题。但是从概念层面来说，作用域在文本解析和引擎执行中的语义并不相同，而环境更是清晰地区分了这种不同。最后，环境与作用域的关系，有点类似于“类与对象实例”之间的关系。总之，他们有差异，但不明显。关于这个概念的进化演变过程，我在给D2的演讲《 JS 语言在引擎级别的执行过程》中有讲过，只是目前D2组委会那边还没有视频放出来，回头你可以找来看看。

作者回复: 是的。函数每调用一次，“函数（的声明）”就会实例化一次。 不过，这个“函数声明的实例化”与你所理解的并不同，它不是说“function f() { ... }”这个函数要被实例化，而是“函数内的那些声明（包括形式参数名和var/let/const声明名字等）”——这些东西需要被实例化。 也就是说，之所以每次调用一下这个函数f，函数内的那些变量都被初始化为undfefined，且形式参数要跟调用时的实际参数绑定一下，这些都是“函数（的声明）实例化”阶段帮你做掉的。 还有，这与“函数是一等公民”并没有什么关系，以及与“函数提升”也没有关系。“函数是一等公民”与“函数提升”之间，也没有关系。这些不要混着讲，他们是不同领域或不同层面的概念。——在第22讲的时候，我会略略地提及到“一等公民”的意义的。 最后，函数（作为声明文本），与函数的引用（作为一个变量名），以及函数的实例（作为一个对象），还有作为函数的闭包（是一个环境/作用域的映射/上下文的参考），这些概念之间有相关性，但并不是一一对应的。例如我常常说的，一个函数的实例，可以有多个闭包。——关于这个示例，你想一下下面这种调用就明白了： ``` function f() { // 当前闭包，return当前函数实例，而在外部又调用该函数实例再创建了一个闭包 // 因此一个函数实例就有了两个闭包（递归就是更多个了） return arguments.callee; } // （类似递归，）与递归的效果是相同的 f()(); ```

作者回复: :) 对的。 但还可以有更深入的分析，把这些东西讲透，也是下一讲的主要目的。

作者回复: 词法环境的链表逆向查找（回溯），是发生在执行过程中的。当前执行上下文，总是持有环境（一个词法环境+一个变量环境）链的末端，通过parent属性往上找就行了。跟对象的原型链回溯是完全一致的。——所以，使用with (x) ...的时候，也就是将对象x展开成一个环境添加到上述链的末端就可以了。 @Elmer 你的另一个问题我一直挂着没回复，是因为那个问题涉及的内容太复杂，我想另开一篇文章去写写，所以还得稍等...

作者回复: 哈哈。问题的密度好大。^^. 首先，环境的确是在执行之前创建的，但比语法分析阶段要略晚。环境是“因为要执行，所以才创建的”。而语法分析，与执不执行并没有关系。当一个东西（例如全局的代码块）需要执行时，引擎才会创建它对应的环境。 当然除了4个与执行直接相关的环境之外，其它的环境是“不用于执行的”。——这个在文章中一再区分它们，就是因为历史中它们混淆得非常厉害。不用于执行的环境，只是说它们与“某个执行上下文不直接关联，不是用来作为context.VariableEnvironment或context.LexicalEnvironment的。但是，它们仍然也是“因为某个东西要被执行，才会被创建出来的”，只是“不直接关联给context”而已。 关于问题1，环境确实也是链式的，它的创建接口类似于： ``` aEnv = new DeclarativeEnvironment ( outerEnv ) ```` 所以你在“问题2”中的推论也就正确：缺省情况下，环境内的内容是不应该改变的。但JavaScript又允许“eval()”来动态地添加（以及使用var来动态删除）变量，所以才会有了“词法环境和变量环境（VariableEnvironment and LexicalEnvironment）”双设计，因为其中的VariableEnvironment就是交由eval()来动态操作的。——所以“Eval环境”才与众不同。 所以总的来说，你的“问题2”中的理解是对的，方向也没错。只是你不敢大胆确认而已。^^. 关于问题3，是独立目的。本质就是名字表的影射。事实上在引擎内部，从parser阶段得来的语法分析树是另外的一个结构，那个分析过程也“可以有（不一定会有）”标识符冲突之类的判断，与环境中的检测无关。环境，其实是基于这个语法分析结果的一个映射，是为执行服务的。 关于问题4，确实很类似。它们都创建了新的环境。不过with(x)创建的环境不用于执行，它的context（用于管理一个独立的代码片断）仍然是当前函数或全局的；而“Eval环境”是用于执行代码的，它有自己的context。eval和with都会降低效率。

作者回复: 多谢多谢。^^.

作者回复: “上下文”是一个特定概念，即执行上下文（ExecuteContext）。这个东西只是在引擎的执行环境中才有意义，它push到执行器的栈里就执行，pop出来就抛弃。此第一。 词法环境与变量环境，是执行上下文（是一个Record格式的数据结构）的两个成员，并且只关联到这种执行上下文中。也就是说，在执行上下文之外讨论词法环境与变量环境是没有意义的。此其二。 我们通常说的“环境”，是一个“环境（规范类型）”的数据结构。它被创建出来之后，要么放到一个可执行上下文中去（这时它是词法环境或变量环境），要么就只是一个环境，能被“环境块的链（Chain）”回溯访问到，但并不是直接关联到执行上下文中的。——举例来说，可能有100个“环境（记录）”，但只有20个执行上下文，那么也就只有20个词法环境或变量环境，其它的80个，虽然也都是环境记录，但只是在Chain上，能被访问而已。 环境是执行过程中的物理结构，作用域是我们在文本分析代码时（在形式上、人为地）可以理解的抽象结构。事实上，环境是作用域的映射，你可以理解为作用域（至少）有一个环境。也就是说，有很多作用域“是环境”，但并不是“（可执行的上下文的）变量环境或词法环境”，就如上面举的100个环境块的例子一样。 所以后面才会说： > 从语法上，（在代码文本中）你可以找到除了上述四种环境之外的其他任何一种块级作用域，事实上它们每个作用域都有一个对应的环境…… 不过从行文措辞的角度上来说，后文中“对于这些用于执行的环境中的其中三个，……”，其中的“这些”改成“那些”要好一点。呵呵，因为在上下文的关系中这里其实有个转折的性质~~~ 不知道……有没有再次把你说昏。:(~

作者回复: 'b is not defined'应该是一个不太友好的错误提示。但是ECMAScript只规范了错误的类型，并不规范错误的提示，所以……不同的引擎在这上面的表现确实不一样哦，也没有什么道理可言哦~ “执行脚本前貌似只处理varDecl(变量声明)lexicalDecls（词法声明）没有处理”，这样的理解不太正确。因为引擎对这两种都是处理的，只不过var变量是绑定了初值的，而let/const不绑定初值（直到执行到它们声明并赋值的那行语句为止）。由于后者不绑定初值，所以出错提示“Cannot access 'b' before initialization”才是正确的意思，并且你按照这个来理解varDecl(变量声明)lexicalDecls（词法声明）就好了。 至于“b is not defined”，老实说我之前也发现这个东东，我觉得这样提示不对，但没可奈何不是么。:(~

作者回复: 不是的，“use strict”其实并没有这样的作用。关于这些，请期待下一讲。^^.