总结篇---闭包问题从此再不难

在阅读完前两个系列文章，终于要厚积薄发了，这里，你将会发现，闭包真的很简单！

仍旧是一个简单的例子：

function foo() {
  var a=1;
  function plus(){
    var b=2;
    alert(a+b);
  }
  return plus;
 }

 var f=foo();
 f();//3

在前面的积累后，你会有如下的分析过程：

• 函数plus的[scope]属性包含了函数foo的执行上下文

• 当return plus后，plus作为一个引用类型返回给变量f, 此时函数plus有什么? plus有它的函数体及[scope]属性

• 调用f()既是在调用plus(),但此时foo()的执行上下文已经被销毁，plus()是取不到变量a的值，但是可以取到，为什么?

这里，我将要指出这个分析过程的错误的地方：

1. 函数plus的[scope]属性包含了函数foo的执行上下文?

   错误，函数plus的[scope]属性包含了函数foo的变量对象，而非执行上下文。执行上下文是在函数调用时创建的，创建执行上下文的时候，会创建变量对象保存相关变量。但是执行上下文销毁的时候，变量对象却不一定被销毁。因为它们的销毁方式不一样。执行上下文是在函数调用结束后即销毁，但是变量对象是根据js垃圾自动回收机制的引用计数的方式才被销毁。所以，执行上下文和变量对象“同生不同死”。一般情况下，函数调用结束，也不存在引用其变量对象了，所以变量对象随着执行上下文的销毁而被回收，但是闭包恰恰就是这个例外。

2. 当return plus后，plus作为一个引用类型返回给变量f, 此时函数plus有什么? plus有它的函数体及[scope]属性

   正确，作用域链本质上是一个指向变量对象的指针链表，它只引用但不包含变量对象。[scope]也是如此。

3. 调用f()既是在调用plus(),但此时foo()的执行上下文已经被销毁，plus()是取不到变量a的值，但是可以取到，为什么?

   因为，foo()的[scope]引用的是变量对象，不是执行上下文，而且plus()还引用着foo()的变量，所以根据js引擎的垃圾自动回收机制的引用计数法，可以知道，foo()的变量对象因为存在着plus()的引用，所以并不被理解回收。也就是说，foo()的执行上下文被销毁，但是它的变量对象仍在。因为foo()的变量对象还在，所以plus()仍旧可以取到变量a的值。

所以，大家可以明白了，闭包的精髓即是 即使执行上下文被销毁了，但它的变量对象仍在。

写在后面

这篇总结篇需要前两系列文章的积累，这两个系列文章的地址收录在我的这篇文章里：厚积薄发—从此再也不用担心闭包问题