作者回复: 是的。函数每调用一次，“函数（的声明）”就会实例化一次。

不过，这个“函数声明的实例化”与你所理解的并不同，它不是说“function f() { ... }”这个函数要被实例化，而是“函数内的那些声明（包括形式参数名和var/let/const声明名字等）”——这些东西需要被实例化。

也就是说，之所以每次调用一下这个函数f，函数内的那些变量都被初始化为undfefined，且形式参数要跟调用时的实际参数绑定一下，这些都是“函数（的声明）实例化”阶段帮你做掉的。

还有，这与“函数是一等公民”并没有什么关系，以及与“函数提升”也没有关系。“函数是一等公民”与“函数提升”之间，也没有关系。这些不要混着讲，他们是不同领域或不同层面的概念。——在第22讲的时候，我会略略地提及到“一等公民”的意义的。

最后，函数（作为声明文本），与函数的引用（作为一个变量名），以及函数的实例（作为一个对象），还有作为函数的闭包（是一个环境/作用域的映射/上下文的参考），这些概念之间有相关性，但并不是一一对应的。例如我常常说的，一个函数的实例，可以有多个闭包。——关于这个示例，你想一下下面这种调用就明白了：

```
function f() {
  // 当前闭包，return当前函数实例，而在外部又调用该函数实例再创建了一个闭包
  // 因此一个函数实例就有了两个闭包（递归就是更多个了）
  return arguments.callee;
}

// （类似递归，）与递归的效果是相同的
f()();
```

作者回复: :) 对的。

但还可以有更深入的分析，把这些东西讲透，也是下一讲的主要目的。

作者回复: 哈哈。问题的密度好大。^^.

首先，环境的确是在执行之前创建的，但比语法分析阶段要略晚。环境是“因为要执行，所以才创建的”。而语法分析，与执不执行并没有关系。当一个东西（例如全局的代码块）需要执行时，引擎才会创建它对应的环境。

当然除了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都会降低效率。

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

作者回复: 'b is not defined'应该是一个不太友好的错误提示。但是ECMAScript只规范了错误的类型，并不规范错误的提示，所以……不同的引擎在这上面的表现确实不一样哦，也没有什么道理可言哦~

“执行脚本前貌似只处理varDecl(变量声明)lexicalDecls（词法声明）没有处理”，这样的理解不太正确。因为引擎对这两种都是处理的，只不过var变量是绑定了初值的，而let/const不绑定初值（直到执行到它们声明并赋值的那行语句为止）。由于后者不绑定初值，所以出错提示“Cannot access 'b' before initialization”才是正确的意思，并且你按照这个来理解varDecl(变量声明)lexicalDecls（词法声明）就好了。

至于“b is not defined”，老实说我之前也发现这个东东，我觉得这样提示不对，但没可奈何不是么。:(~

作者回复: 是这样的，全局环境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约定不一致罢了。

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