哎，你不要把 定义 和 实现 混淆起来嘛。

可以通过静态分析确定作用域，不等于在实践中一定要通过一次性的静态编译过程来确定作用域。否则解释语言岂不是都只能用动态作用域？

再者说，我已经强调过了，JS并不是完全的lexical scope，所以无法仅仅通过静态编译过程来确定作用域。

由上述两点，可以知道认为JS不是“静态作用域”而是“lexical scope”，进而认为static scope不等于lexical scope，纯粹是认识上的误区。Scott的解释完全没有问题。纯粹的静态作用域语言，肯定可以在编译时确定作用域。但是当然也可以留待到运行时确定，这并不矛盾。现有的JS为什么采用在运行时才确定作用域的scope chain机制，是因为JS不是纯粹的静态作用域语言，无法在编译时确定所有的作用域。

再，关于lexical scope和scope chain的关系。

之前已经说过，scope chain只是一种实现手段，可以用来实现静态作用域（当然也可以实现非静态作用域，例如with的构造）。唯一独特的是，ES3规范把scope chain机制写到了规范之内，这可能使人误以为所有JS引擎都必须采用scope chain的方式。从某种程度上说，scope chain不应出现在ES规范中，现在ES3规范中对于scope chain的描述，应该被理解为，通过对此种机制的描述来更准确的定义JS语言的行为，而不是说，JS引擎就必须采用scope chain。

实际上未必如此，只要效果等价，你完全可以用其他方式。许多JS引擎都有优化，即在某些条件下并不使用scope chain机制。

反过来说，之所以现在JS要使用scope chain，也是因为JS不是完全的lexical scope。

未来JS可能加入一个pragma：“use lexical scope”，在开启此pragma之后，不允许使用with结构，不允许在eval中修改当前scope，不允许scope chain上的任何一个属性被delete，总是使用初始的global绑定（即动态的增加一个global变量是不能被访问到的，除非显式的使用window.xxx来访问）……总而言之一句话，允许引擎在这种情况下按照完全的静态作用域方式来确定变量，而不必缓慢的在scope chain上逐级检索。

此外，scope chain机制可以实现closure，但是也并不表示closure一定要用scope chain实现。Python 2.1开始支持static nested scope，它是采用flat closures方式来实现的。Lua也采用flat closures来实现，参见：http://blog.csdn.net/hunhun1981/archive/2008/04/10/2276334.aspx 。如果JS没有with和eval捣蛋，也可以抛开scope chain转用其他方式实现closure。

所以回到你举的这个例子来说，f(1)和f(2)运行时创建了2个不同的执行环境，也就产生了2个不同的作用域链，而返回的函数g1和g2内部也就拥有了不同的作用域链，在g1的作用域链中保存x=1，而在g2的作用域链中保存x=2。