named-function-expressions-demystified.html

<!DOCTYPE html>
<html lang="zh-CN">
  <head>
    <meta http-equiv="Content-type" content="text/html; charset=utf-8">
    <title>命名函数表达式探秘 - justjavac的博客</title>
    <meta content="An article about named function expressions in Javascript" name="description">
    <meta content="named function expressions, function expression, javascript, jscript identifier leak, function names in debuggers" name="keywords">
    <meta name="author" content="justjavac">
    <link rel="alternate" title="justjavac的博客" href="/atom.xml" type="application/rss+xml" />
    <script src="/assets/js/jquery-1.9.0.min.js"></script>
   <!-- Le HTML5 shim, for IE6-8 support of HTML elements -->
    <!--[if lt IE 9]>
      <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
    <![endif]-->

    <!-- Le styles -->
    <link href="/assets/themes/twitter/bootstrap/css/bootstrap.min.css" rel="stylesheet">
    <link href="/assets/themes/twitter/css/style.css?body=1" rel="stylesheet" media="all">

    <!-- Le fav and touch icons -->
  <!-- Update these with your own images
    <link rel="shortcut icon" href="images/favicon.ico">
    <link rel="apple-touch-icon" href="images/apple-touch-icon.png">
    <link rel="apple-touch-icon" sizes="72x72" href="images/apple-touch-icon-72x72.png">
    <link rel="apple-touch-icon" sizes="114x114" href="images/apple-touch-icon-114x114.png">
  -->
  </head>

  <body>

    <div class="navbar navbar-fixed-top">
      <div class="navbar-inner">
        <div class="container">
          <a class="brand" href="/">justjavac的博客</a>
          <ul class="nav">
            <li><a href="javascript:void(0)">代码之谜</a></li>
            <li><a href="javascript:void(0)" title="转载的文章">它山之石</a></li>
            <li><a href="javascript:void(0)" title="翻译的文章">师夷长技</a></li>
            <li><a href="/categories.html">目录</a></li>
            <li><a href="/tags.html">标签</a></li>
            <li><a href="/archive.html">归档</a></li>
            <li><a href="javascript:void(0)">关于我</a></li>
          </ul>
        </div>
      </div>
    </div>

    <div class="container" style="margin-left: 200px;">

      <div class="content">
     
<div class="page-header">
  <h1>命名函数表达式探秘</h1>
</div>


    <div style="text-align: right;"><em>作者：<a href="http://perfectionkills.com/" title="" target="_blank" rel="nofollow">Juriy "kangax" Zaytsev</a></em></div>
    <div style="text-align: right;"><em>译者：<a href="http://www.cn-cuckoo.com/" title="" target="_blank" rel="nofollow">为之漫笔</a></em></div>
    <div style="text-align: right;"> 发表时间：<span class="dtstart">2009年6月17日</span> 最近修改：<span class="dtstart">2009年10月9日</span> </div>
    <div style="text-align: right;"> 翻译时间：<span class="dtstart">2009年12月9日</span> 修订时间：<span class="dtstart">2009年12月22日</span> </div>
    <ol>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#introduction">前言</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#expr-vs-decl">函数表达式与函数声明</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#function-statements">函数语句</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#named-expr">命名函数表达式</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#names-in-debuggers">调试器中的函数名</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#jscript-bugs">JScript的bug</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#jscript-memory-management">JScript的内存管理</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#tests">测试</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#safari-bug">Safari中存在的bug</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#spidermonkey-peculiarity">SpiderMonkey的怪癖</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#solution">解决方案</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#alt-solution">替代方案</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#webkit-displayName">WebKit的displayName</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#future-considerations">对未来的思考</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#credits">致谢</a></li>
    </ol>

  <h2 id="introduction">前言</h2>
  <p>我觉得很奇怪，网上好像一直没有人认真地讨论过命名函数表达式（Named Function Expression，即“有名字函数表达式”，与“匿名函数”相对。——译者注）。而这也许正是各种各样的误解随处可见的一个原因。在这篇文章里，我打算从理论和实践两个方面出发，对这些令人惊叹的JavaScript结构的优缺点给出一个结论。</p>
  <p>简单来讲，命名函数表达式只有一个用处——在调试器或性能分析程序中描述函数的名称。没错，也可以使用函数名实现递归，但你很快就会知道，目前来看这通常是不切实际的。当然，如果你不关注调试，那就没什么可担心的。否则，就应该往下看一看，看看在跨浏览器开发中都会出现哪些小毛病（glitch），也看看应该怎样解决它们。</p>
  <p>一开始呢，我会先介绍一下什么是函数表达式，以及现代调试器如何处理它们之类的内容。要是你比较心急，请直接跳到<a href="http://justjavac.com/named-function-expressions-demystified.html#solution">“最终方案”</a>部分，该部分详细说明了怎样才能安全地使用这些结构。</p>

  <h2 id="expr-vs-decl">函数表达式与函数声明</h2>
  <p>在ECMAScript中，有两个最常用的创建函数对象的方法，即使用<em>函数表达式</em>或者使用<em>函数声明</em>。这两种方法之间的区别可谓 <strong>相当地令人困惑</strong>；至少我是相当地困惑。对此，ECMA规范只明确了一点，即<em>函数声明</em> 必须始终带有一个<em>标识符（Identifier）</em>——也就是函数名呗，而<em>函数表达式</em> 则可省略这个标识符：</p>
  <blockquote>
    <p>函数声明：<br>
      function Identifier ( FormalParameterList <sub>opt</sub> ){ FunctionBody }</p>
    <p>函数表达式：<br>
      function Identifier <sub>opt</sub> ( FormalParameterList <sub>opt</sub> ){ FunctionBody }</p>
  </blockquote>
  <p>显然，在省略标识符的情况下， &#8220;表达式&#8221; 也就只能是表达式了。可要是不省略标识符呢？谁知道它是一个函数声明，还是一个函数表达式——毕竟，这种情况下二者是完全一样的啊？实践表明，ECMAScript是通过上下文来区分这两者的：假如 <code>function foo(){}</code> 是一个赋值表达式的一部分，则认为它是一个函数表达式。而如果 <code>function foo(){}</code> 被包含在一个函数体内，或者位于程序（的最上层）中，则将它作为一个函数声明来解析。</p>
  <pre lang="javascript" class="prettyprint">
  function foo(){}; // 声明，因为它是<em>程序</em>的一部分
  var bar = function foo(){}; // 表达式，因为它是<em>赋值表达式（AssignmentExpression）的一部分</em>

  new function bar(){}; // 表达式，因为它是<em>New表达式（NewExpression）</em>的一部分

  (function(){
    function bar(){}; // 声明，因为它是<em>函数体（FunctionBody）</em>的一部分
  })();
</pre>
  <p>还有一种不那么显而易见的函数表达式，就是被包含在一对圆括号中的函数—— <code>(function foo(){})</code>。将这种形式看成表达式同样是因为上下文的关系：(和)构成一个分组操作符，而分组操作符只能包含表达式：</p>
  <p>下面再多看几个例子吧：</p>
  <pre lang="javascript" class="prettyprint">
  
  function foo(){}; // 函数声明
  (function foo(){}); // 函数表达式：注意它被包含在分组操作符中
  
  try {
    (var x = 5); // 分组操作符只能包含表达式，不能包含语句（这里的var就是语句）
  } catch(err) {
    // SyntaxError（因为“var x = 5”是一个语句，而不是表达式——对表达式求值必须返回值，但对语句求值则未必返回值。——译者注）
  }
</pre>
  <p>不知道大家有没有印象，在使用 <code>eval</code> 对JSON求值的时候，JSON字符串通常是被包含在一对圆括号中的—— <code>eval('(' + json + ')')</code>。这样做的原因当然也不例外——分组操作符，也就是那对圆括号，会导致解析器强制将JSON的花括号当成表达式而不代码块来解析：</p>
  <pre lang="javascript" class="prettyprint">
  try {
    { "x": 5 }; // {和}会被作为块来解析
  } catch(err) {
    // SyntaxError（“'x':5”只是构建对象字面量的语法，但该语法不能出现在外部的语句块中。——译者注）
  }
  
  ({ "x": 5 }); // 分组操作符会导致解析器强制将{和}作为对象字面量来解析
</pre>
  <p>声明和表达式的行为存在着十分微妙而又十分重要的差别。</p>
  <p>首先，函数声明会在任何表达式被解析和求值之前先行被解析和求值。即使声明位于源代码中的最后一行，它也会先于同一作用域中位于最前面的表达式被求值。还是看个例子更容易理解。在下面这个例子中，函数 <code>fn</code> 是在 <code>alert</code> 后面声明的。但是，在 <code>alert</code> 执行的时候，<code>fn</code>已经有定义了：</p>
  <pre lang="javascript" class="prettyprint">
  alert(fn());

  function fn() {
    return 'Hello world!';
  }
</pre>
  <p>函数声明还有另外一个重要的特点，即通过条件语句控制函数声明的行为并未标准化，因此不同环境下可能会得到不同的结果。有鉴于此，奉劝大家千万不要在条件语句中使用函数声明，而要使用函数表达式。</p>
  <pre lang="javascript" class="prettyprint">
  // <strong>千万不要这样做！</strong>
  // 有的浏览器会把foo声明为返回first的那个函数
  // 而有的浏览器则会让foo返回second

  if (true) {
    function foo() {
      return 'first';
    }
  }
  else {
    function foo() {
      return 'second';
    }
  }
  foo();

  // 记住，这种情况下要使用函数表达式：
  var foo;
  if (true) {
    foo = function() {
      return 'first';
    };
  }
  else {
    foo = function() {
      return 'second';
    };
  }
  foo();
</pre>
  <p>想知道使用函数声明的实际规则到底是什么？继续往下看吧。嗯，有人不想知道？那请跳过下面这段摘录的文字。</p>
  <div id="function-declarations-in-blocks" class="excerpt">
    <p> <em>FunctionDeclaration（函数声明）</em>只能出现在<em>Program（程序）</em>或<em>FunctionBody（函数体）</em>内。从句法上讲，它们 <strong>不能出现在<em>Block（块）</em></strong>（<code>{ ... }</code>）中，例如不能出现在 <code>if</code>、<code>while</code> 或 <code>for</code> 语句中。因为 <em>Block（块）</em> 中只能包含<em>Statement（语句）</em>， 而不能包含<em>FunctionDeclaration（函数声明）</em>这样的<em>SourceElement（源元素）</em>。另一方面，仔细看一看产生规则也会发现，唯一可能让<em>Expression（表达式）</em>出现在<em>Block（块）</em>中情形，就是让它作为<em>ExpressionStatement（表达式语句）</em>的一部分。但是，规范明确规定了<em>ExpressionStatement（表达式语句）</em><strong>不能以关键字function开头</strong>。而这实际上就是说，<em>FunctionExpression（函数表达式）</em>同样也不能出现在<em>Statement（语句）</em>或<em>Block（块）</em>中（别忘了<em>Block（块）</em>就是由<em>Statement（语句）</em>构成的）。 </p>
    <p> 由于存在上述限制，只要函数出现在块中（像上面例子中那样），实际上就应该将其<strong>看作一个语法错误</strong>，而不是什么函数声明或表达式。但问题是，我还没见过哪个实现是按照上述规则来解析这些函数的；好像每个实现都有自己的一套。 </p>
  </div>
  <p>有必要提醒大家一点，根据规范的描述，实现可以引入<strong>语法扩展</strong>（见第16部分），只不过任何情况下都不能违反规定。而目前的诸多客户端也正是照此办理的。其中有一些会把块中的函数声明当作一般的函数声明来解析——把它们提升到封闭作用域的顶部；另一些则引入了不同的语义并采用了稍复杂一些的规则。</p>
  <h2 id="function-statements">函数语句</h2>
  <div>
    <p> 在诸如此类的对ECMAScript的语法扩展中，有一项就是<strong>函数语句</strong>，基于Gecko的浏览器（在Mac OS X平台的Firefox 1-3.7a1pre中测试过）目前都实现了该项扩展。可是不知道为什么，很多人好像都不知道这项扩展，也就更谈不上对其优劣的评价了（<a href="https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference:Functions#Conditionally_defining_a_function">MDC（Mozilla Developer Center，Mozilla开发者中心）提到过这个问题</a>，但是只有那么三言两语）。请大家记住，我们是抱着学习和满足自己好奇心的态度来讨论函数语句的。因此，除非你只针对基于Gecko的环境编写脚本，否则<strong>我不建议你使用这个扩展</strong>。 </p>
    <p> 闲话少说，下面我们就来看看这些非标准的结构有哪些特点： </p>
    <ol>
      <li>一般<em>语句</em>可以出现的地方，函数语句也可以出现。当然包括<em>块</em>中：</li>
      <pre lang="javascript" class="prettyprint">
  if (true) {
    function f(){ }
  }
  else {
    function f(){ }
  }
</pre>
      <li>函数语句可以像其他语句一样被解析，包含基于条件执行的情形：</li>
      <pre lang="javascript" class="prettyprint">
  if (true) {
    function foo(){ return 1; }
  }
  else {
    function foo(){ return 2; }
  }
  foo(); // 1
  // 注意其他类型的客户端会把这里的foo解析为函数声明
  // 因此，第二个foo会覆盖第一个，结果返回2而不返回1
</pre>
      <li> 函数语句不是在变量初始化期间声明的，而是在运行时声明的——与函数表达式一样。不过，一旦声明，函数语句的标识符就在函数的<strong>整个作用域有效了</strong>。标识符有效性正是导致函数语句与函数表达式不同的关键所在（下一节将会展示命名函数表达式的具体行为）。
        <pre lang="javascript" class="prettyprint">
  // 此时，foo还没有声明
  typeof foo; // "undefined"
  if (true) {
    // 一进入这个块，foo就被声明并在整个作用域中有效了
    function foo(){ return 1; }
  }
  else {
    // 永远不会进入这个块，因此这里的foo永远不会被声明
    function foo(){ return 2; }
  }
  typeof foo; // "function"
  
</pre>
        通常，可以通过下面这样符合标准（但更繁琐一点）的代码来模拟前例中函数语句的行为：
        <pre lang="javascript" class="prettyprint">
  var foo;
  if (true) {
    foo = function foo(){ return 1; };
  }
  else {
    foo = function foo() { return 2; };
  }
</pre>
      </li>
      <li> 函数语句与函数声明或命名函数表达式的字符串表示类似（而且包含标识符——即此例中的foo）：
        <pre lang="javascript" class="prettyprint">
  if (true) {
    function foo(){ return 1; }
  }
  String(foo); // function foo() { return 1; }
</pre>
      </li>
      <li> 最后，早期基于Gecko的实现（Firefox 3及以前版本）中存在一个bug，即函数语句覆盖函数声明的方式不正确。在这些早期的实现中，函数语句不知何故不能覆盖函数声明：
        <pre lang="javascript" class="prettyprint">
  // 函数声明
  function foo(){ return 1; }
  if (true) {
    // 使用函数语句来重写
    function foo(){ return 2; }
  }
  foo(); // FF及以前版本返回1，FF3.5及以后版本返回2
  
  // 但是，如果前面是函数表达式，则没有这个问题
  var foo = function(){ return 1; };
  if (true) {
    function foo(){ return 2; }
  }
  foo(); // 在所有版本中都返回2
</pre>
      </li>
    </ol>
    <p id="function-statements-in-safari"> 大家请注意，Safari的某些早期版本（至少包括1.2.3、2.0 - 2.0.4以及3.0.4，可能也包括更早的版本）实现了<strong>与SpiderMonkey完全一样的</strong>函数语句。本节所有的例子（不包括最后一个bug示例），在Safari的那些版本中都会得到与Firefox完全相同的结果。此外，Blackberry（至少包括8230、9000和9530）浏览器好像也具有类似的行为。上述这种行为的差异化再次说明——千万不能盲目地依赖这些扩展啊（如下所述，可以根据特性测试来使用函数表达式。——译者注）！ </p>
  </div>
  <h2 id="named-expr">命名函数表达式</h2>
  <p>函数表达式实际上还是很常见的。Web开发中有一个常用的模式，即基于对某种特性的测试来“伪装”函数定义，从而实现性能最优化。由于这种伪装通常都出现在相同的作用域中，因此基本上一定要使用函数表达式。毕竟，如前所述，不应该根据条件来执行函数声明：</p>
  <pre lang="javascript" class="prettyprint">
  // 这里的contains取自APE Javascript库的源代码，网址为http://dhtmlkitchen.com/ape/，作者盖瑞特·斯密特（Garrett Smit）
  var contains = (function() {
    var docEl = document.documentElement;

    if (typeof docEl.compareDocumentPosition != 'undefined') {
      return function(el, b) {
        return (el.compareDocumentPosition(b) &amp; 16) !== 0;
      }
    }
    else if (typeof docEl.contains != 'undefined') {
      return function(el, b) {
        return el !== b &amp;&amp; el.contains(b);
      }
    }
    return function(el, b) {
      if (el === b) return false;
      while (el != b &amp;&amp; (b = b.parentNode) != null);
      return el === b;
    }
  })();
</pre>
  <p>提到<strong>命名函数表达式</strong>，很显然，指的就是有名字（技术上称为<em>标识符</em>）的函数表达式。在最前面的例子中，<code>var bar = function foo(){};</code>实际上就是一个以<code>foo</code>作为函数名字的函数表达式。对此，有一个细节特别重要，请大家一定要记住，即这个名字<strong>只在新定义的函数的作用域中有效</strong>——规范要求标识符不能在外围的作用域中有效：</p>
  <pre lang="javascript" class="prettyprint">
  var f = function foo(){
    return typeof foo; // foo只在内部作用域中有效
  };
  // foo在“外部”永远是不可见的
  typeof foo; // "undefined"
  f(); // "function"
</pre>
  <p>那么，这些所谓的命名函数表达式到底有什么用呢？为什么还要给它们起个名字呢？</p>
  <p>原因就是有名字的函数可以让调试过程更加方便。在调试应用程序时，如果调用栈中的项都有各自描述性的名字，那么调试过程带给人的就是另一种完全不同的感受。</p>
  <h2 id="names-in-debuggers">调试器中的函数名</h2>
  <p>在函数有相应标识符的情况下，调试器会将该标识符作为函数的名字显示在调用栈中。有的调试器（例如Firebug）甚至会为匿名函数起个名字并显示出来，让它们与那些引用函数的变量具有相同的角色。可遗憾的是，这些调试器通常只使用简单的解析规则，而依据简单的解析规则提取出来的“名字”有时候没有多大价值，甚至会得到错误结果。（Such extraction is usually quite fragile and often produces false results. ）</p>
  <p>下面我们来看一个简单的例子：</p>
  <pre lang="javascript" class="prettyprint">
  function foo(){
    return bar();
  }
  function bar(){
    return baz();
  }
  function baz(){
    debugger;
  }
  foo();

  // 这里使用函数声明定义了3个函数
  // 当调试器停止在debugger语句时，
  // Firgbug的调用栈看起来非常清晰：
  baz
  bar
  foo
  expr_test.html()
</pre>
  <p>这样，我们就知道<code>foo</code>调用了<code>bar</code>，而后者接着又调用了<code>baz</code>（而<code>foo</code>本身又在<code>expr_test.html</code>文档的全局作用域中被调用）。但真正值得称道的，则是Firebug会在我们使用匿名表达式的情况下，替我们解析函数的“名字”：</p>
  <pre lang="javascript" class="prettyprint">
  function foo(){
    return bar();
  }
  var bar = function(){
    return baz();
  }
  function baz(){
    debugger;
  }
  foo();

  // 调用栈：
  baz
  bar()
  foo
  expr_test.html()
</pre>
  <p>相反，不那么令人满意的情况是，当函数表达式复杂一些时（现实中差不多总是如此），调试器再如何尽力也不会起多大的作用。结果，我们只能在调用栈中显示函数名字的位置上赫然看到一个问号：</p>
  <pre lang="javascript" class="prettyprint">
  function foo(){
    return bar();
  }
  var bar = (function(){
    if (window.addEventListener) {
      return function(){
        return baz();
      }
    }
    else if (window.attachEvent) {
      return function() {
        return baz();
      }
    }
  })();
  function baz(){
    debugger;
  }
  foo();

  // 调用栈：
  baz
  (?)()
  foo
  expr_test.html()
</pre>
  <p>此外，当把一个函数赋值给多个变量时，还会出现一个令人困惑的问题：</p>
  <pre lang="javascript" class="prettyprint">
  function foo(){
    return baz();
  }
  var bar = function(){
    debugger;
  };
  var baz = bar;
  bar = function() { 
    alert('spoofed');
  }
  foo();

  // 调用栈：
  bar()
  foo
  expr_test.html()
</pre>
  <p>可见，调用栈中显示的是<code>foo</code>调用了<code>bar</code>。但实际情况显然并非如此。之所以会造成这种困惑，完全是因为<code>baz</code>与另一个函数——包含代码alert('spoofed');的函数——“交换了”引用所致。实事求是地说，这种解析方式在简单的情况下固然好，但对于不那么简单的大多数情况而言就没有什么用处了。</p>
  <p>归根结底，只有命名<strong>函数表达式才是产生可靠的栈调用信息的唯一途径</strong>。下面我们有意使用命名函数表达式来重写前面的例子。请大家注意，从自执行包装块中返回的两个函数都被命名为了<code>bar</code>：</p>
  <pre lang="javascript" class="prettyprint">
  function foo(){
    return bar();
  }
  var bar = (function(){
    if (window.addEventListener) {
      return function bar(){
        return baz();
      }
    }
    else if (window.attachEvent) {
      return function bar() {
        return baz();
      }
    }
  })();
  function baz(){
    debugger;
  }
  foo();

  // 这样，我们就又可以看到清晰的调用栈信息了！
  baz
  bar
  foo
  expr_test.html()
</pre>
  <p>在我们为发现这根救命稻草而欢呼雀跃之前，请大家稍安勿躁，再听我聊一聊大家所衷爱的JScript。</p>
  <h2 id="jscript-bugs">JScript的bug</h2>
  <p>令人讨厌的是，JScript（也就是IE的ECMAScript实现）严重混淆了命名函数表达式。JScript搞得现如今很多人都站出来<strong>反对</strong>命名函数表达式。而且，直到<strong>JScript的最近一版——IE8中使用的5.8版——仍然存在下列的所有怪异问题。</strong></p>
  <p>下面我们就来看看IE在它的这个“破”实现中到底都搞出了哪些花样。唉，只有知已知彼，才能百战不殆嘛。请注意，为了清晰起见，我会通过一个个相对独立的小例子来说明这些问题，虽然这些问题很可能是一个主bug引起的一连串的后果。</p>
  <h3 id="example_1_function_expression_identifier_leaks_into_an_enclosing_scope">例1：函数表达式的标识符渗透到外部（enclosing）作用域中</h3>
  <pre lang="javascript" class="prettyprint">
    var f = function g(){};
    typeof g; // "function"
</pre>
  <p>还有人记得吗，我们说过：命名函数表达式的标识符<strong>在其外部作用域中是无效的</strong>? 好啦，JScript明目张胆地违反了这一规定——上面例子中的标识符<code>g</code>被解析为函数对象。这是最让人头疼的一个问题了。这样，任何标识符都可能会在不经意间“污染”某个外部作用域——甚至是全局作用域。而且，这种污染常常就是那些难以捕获的bug的来源。</p>
  <h3 id="example_2_named_function_expression_is_treated_as_both_function_declaration_and_function_expression">例2：将命名函数表达式同时当作函数声明和函数表达式</h3>
  <pre lang="javascript" class="prettyprint">
    typeof g; // "function"
    var f = function g(){};
</pre>
  <p>如前所述，在特定的执行环境中，函数声明会先于任何表达式被解析。上面这个例子展示了<strong>JScript实际上是把命名函数表达式当作函数声明了</strong>；因为它在“实际的”声明之前就解析了<code>g</code>。</p>
  <p>这个例子进而引出了下一个例子：</p>
  <h3 id="example_3_named_function_expression_creates_two_distinct_function_objects">例3：命名函数表达式会创建两个截然不同的函数对象！</h3>
  <pre lang="javascript" class="prettyprint">
    var f = function g(){};
    f === g; // false

    f.expando = 'foo';
    g.expando; // undefined
</pre>
  <p>问题至此就比较严重了。或者可以说修改其中一个对象对另一个丝毫没有影响——这简直就是胡闹！通过例子可以看出，出现两个不同的对象会存在什么风险。假如你想利用缓存机制，在<code>f</code>的属性中保存某个信息，然后又想当然地认为可以通过引用相同对象的<code>g</code>的同名属性取得该信息，那么你的麻烦可就大了。</p>
  <p>再来看一个稍微复杂点的情况。</p>
  <h3 id="example_4_function_declarations_are_parsed_sequentially_and_are_not_affected_by_conditional_blocks">例4：只管顺序地解析函数声明而忽略条件语句块</h3>
  <pre lang="javascript" class="prettyprint">
    var f = function g() {
        return 1;
    };
    if (false) {
        f = function g(){
            return 2;
        };
    }
    g(); // 2
</pre>
  <p>要查找这个例子中的bug就要困难一些了。但导致bug的原因却非常简单。首先，<code>g</code>被当作函数声明解析，而由于JScript中的函数声明不受条件代码块约束（与条件代码块无关），所以在“该死的”<code>if</code>分支中，<code>g</code>被当作另一个函数——<code>function g(){ return 2 }</code>——又被声明了一次。然后，所有“常规的”表达式被求值，而此时<code>f</code>被赋予了另一个新创建的对象的引用。由于在对表达式求值的时候，永远不会进入“该死的”<code>if</code>分支，因此<code>f</code>就会继续引用第一个函数——<code>function g(){ return 1 }</code>。分析到这里，问题就很清楚了：假如你不够细心，在<code>f</code>中调用了<code>g</code>（在执行递归操作的时候会这样做。——译者注），那么实际上将会调用一个毫不相干的<code>g</code>函数对象（即返回2的那个函数对象。——译者注）。</p>
  <p>聪明的读者可能会联想到：在将不同的函数对象与<code>arguments.callee</code>进行比较时，这个问题会有所表现吗？<code>callee</code>到底是引用<code>f</code>还是引用<code>g</code>呢？下面我们就来看一看：</p>
  <pre lang="javascript" class="prettyprint">
  var f = function g(){
    return [
      arguments.callee == f,
      arguments.callee == g
    ];
  };
  f(); // [true, false]
  g(); // [false, true]
</pre>
  <p>看到了吧，<code>arguments.callee</code>引用的始终是被调用的函数。实际上，这应该是件好事儿，原因你一会儿就知道了。</p>
  <p>另一个“意外行为”的好玩的例子，当我们<strong>在不包含声明的赋值语句中使用命名函数表达式</strong>时可以看到。不过，此时函数的名字必须与引用它的标识符相同才行：</p>
  <pre lang="javascript" class="prettyprint">
  (function(){
    f = function f(){};
  })();
</pre>
  <p>众所周知（但愿如此。——译者注），不包含声明的赋值语句（注意，我们<strong>不建议</strong>使用，这里只是出于示范需要才用的）在这里会创建一个全局属性<code>f</code>。而这也是标准实现的行为。可是，JScript的bug在这里又会出点乱子。由于JScript把命名函数表达式当作函数声明来解析（参见<a href="#example_2_named_function_expression_is_treated_as_both_function_declaration_and_function_expression">前面的“例2”</a>），因此在变量声明阶段，<code>f</code>会被声明为局部变量。然后，在函数执行时，赋值语句已经不是未声明的了（因为f已经被声明为局部变量了。——译者注），右手边的<code>function f(){}</code>就会被直接赋给刚刚创建的<strong>局部</strong>变量<code>f</code>。而全局作用域中的<code>f</code>根本不会存在。</p>
  <p>看完这个例子后，相信大家就会明白，如果你对JScript的“怪异”行为缺乏了解，你的代码中出现“严重不符合预期”的行为就不难理解了。</p>
  <p>明白了JScript的缺陷以后，要采取哪些预防措施就非常清楚了。首先，要注意防范<strong>标识符泄漏（渗透）</strong>（不让标识符污染外部作用域）。其次，应该<strong>永远不引用被用作函数名称的标识符</strong>；还记得前面例子中那个讨人厌的标识符<code>g</code>吗？——如果我们能够当<code>g</code>不存在，可以避免多少不必要的麻烦哪。因此，关键就在于始终要通过<code>f</code>或者<code>arguments.callee</code>来引用函数。如果你使用了命名函数表达式，那么应该只在调试的时候利用那个名字。最后，还要记住一点，<strong>一定要把NFE（Named Funciont Expresssions，命名函数表达式）声明期间错误创建的函数清理干净</strong>。
  <p>嗯，对于上面最后一点，我觉得还要再啰嗦两句：</p>
  <h2 id="jscript-memory-management">JScript的内存管理</h2>
  <p>熟悉上述JScript缺陷之后，再使用这些有毛病的结构，就会发现内存占用方面的潜在问题。下面看一个简单的例子：</p>
  <pre lang="javascript" class="prettyprint">
  var f = (function(){
    if (true) {
      return function g(){};
    }
    return function g(){};
  })();
</pre>
  <p>我们知道，这里匿名（函数）调用返回的函数——带有标识符<code>g</code>的函数——被赋值给了外部的<code>f</code>。我们也知道，命名函数表达式会导致产生多余的函数对象，而该对象与返回的函数对象不是一回事。由于有一个多余的<code>g</code>函数被“截留”在了返回函数的闭包中，因此内存问题就出现了。这是因为（if语句）内部（的）函数与讨厌的<code>g</code>是在同一个作用域中被声明的。在这种情况下 ，除非我们<strong>显式地断开对（匿名调用返回的）<code>g</code>函数的引用</strong>，否则那个讨厌的家伙会一直占着内存不放。</p>
  <pre lang="javascript" class="prettyprint">
  var f = (function(){
    var f, g;
    if (true) {
      f = function g(){};
    }
    else {
      f = function g(){};
    }
    // 废掉g，这样它就不会再引用多余的函数了
    g = null;
    return f;
  })();
</pre>
  <p>请注意，这里也明确声明了变量<code>g</code>，因此赋值语句<code>g = null</code>就不会在符合标准的客户端（如非JScript实现）中创建全局变量<code>g</code>了。通过<code>废掉</code>对<code>g</code>的引用，垃圾收集器就可以把<code>g</code>引用的那个隐式创建的函数对象清除了。</p>
  <p>在解决JScript NFE内存泄漏问题的过程中，我运行了一系列简单的测试，以便确定<code>废掉</code><code>g</code>能够释放内存。</p>
  <h2 id="tests">测试</h2>
  <p>这里的测试很简单。就是通过命名函数表达式创建10000个函数，把它们保存在一个数组中。过一会儿，看看这些函数到底占用了多少内存。然后，再废掉这些引用并重复这一过程。下面是我使用的一个测试用例：</p>
  <pre lang="javascript" class="prettyprint">
  function createFn(){
    return (function(){
      var f;
      if (true) {
        f = function F(){
          return 'standard';
        }
      }
      else if (false) {
        f = function F(){
          return 'alternative';
        }
      }
      else {
        f = function F(){
          return 'fallback';
        }
      }
      // var F = null;
      return f;
    })();
  }

  var arr = [ ];
  for (var i=0; i&lt;10000; i++) {
    arr[i] = createFn();
  }
</pre>
  <p>通过运行在Windows XP SP2中的Process Explorer可以看到如下结果：</p>
  <pre lang="javascript" class="prettyprint">
  IE6:

    without `null`:   7.6K -> 20.3K
    with `null`:      7.6K -> 18K

  IE7:

    without `null`:   14K -> 29.7K
    with `null`:      14K -> 27K
</pre>
  <p>这个结果大致验证了我的想法——显式地清除多余的引用确实可以释放内存，但释放的内存空间相对不多。在创建10000个函数对象的情况下，大约有3MB左右。对于大型应用程序，以及需要长时间运行或者在低内存设备（如手持设备）上运行的程序而言，这是绝对需要考虑的。但对小型脚本而言，这点差别可能也算不了什么。</p>
  <p>有读者可能认为本文到此差不多就该结尾了——实际上还差得远呢 :)。我还想再多谈一点，这些内容涉及的是Safari 2.x。</p>
  <h2 id="safari-bug">Safari中存在的bug</h2>
  <p> 在Safari较早的版本——Safari 2.x系列中，也存在一些鲜为人知的与NFE有关的bug。我在Web上看到<a href="http://meyerweb.com/eric/thoughts/2005/07/11/safari-syntaxerror/" target="_blank">有人说Safari 2.x不支持NFE</a> 。实际上不是那么回事。Safari确实支持NFE，只不过它的实现中存在bug而已（很快你就会看到）。</p>
  <p>在某些情况下，Safari 2.x遇到函数表达式时会出现不能完全解析程序的问题。而且，此时的Safari不会抛出任何错误（例如<code>SyntaxError</code>），只会“默默地知难而退”：</p>
  <pre lang="javascript" class="prettyprint">
  (function f(){})(); // &lt;== NFE
  alert(1); // 由于前面的表达式破坏了整个程序，因此这一行永远不会执行
</pre>
  <p>经过多次测试，我得出一个结论：Safari 2.x <strong>不能解析非赋值表达式中的命名函数表达式</strong>。下面是一些赋值表达式的例子：</p>
  <pre lang="javascript" class="prettyprint">
    // 变量声明
    var f = 1;

    // 简单赋值
    f = 2, g = 3;

    // 返回语句
    (function(){
      return (f = 2);
    })();
</pre>
  <p>换句话说，把命名函数表达式放到一个赋值表达式中会让Safari“很高兴”：</p>
  <pre lang="javascript" class="prettyprint">
  (function f(){}); // 失败

  var f = function f(){}; // 没问题

  (function(){
    return function f(){}; // 失败
  })();

  (function(){
    return (f = function f(){}); // 没问题
  })();

  setTimeout(function f(){ }, 100); // 失败
  
  Person.prototype = {
    say: function say() { ... } // 失败
  }
  
  Person.prototype.say = function say(){ ... }; // 没问题
</pre>
  <p>同时这也就意味着，在不使用赋值表达式的情况下，我们不能使用习以为常的模式返回命名函数表达式：</p>
  <pre lang="javascript" class="prettyprint">

  // 以下返回命名函数表达式的常见模式，对Safari 2.x来说是不兼容的：
  (function(){
    if (featureTest) {
      return function f(){};
    }
    return function f(){};
  })();

  // 在Safari 2.x中，应该使用以下稍麻烦一点的方式：
  (function(){
    var f;
    if (featureTest) {
      f = function f(){};
    }
    else {
      f = function f(){};
    }
    return f;
  })();

  // 或者，像下面这样也行：
  (function(){
    var f;
    if (featureTest) {
      return (f = function f(){});
    }
    return (f = function f(){});
  })();

  /* 
    可是，这样一来，就额外使用了一个对函数的引用，而该引用还被封闭在了返回函数的闭包中。
	为了最大限度地降低额外的内存占用，可以考虑把所有命名函数表达式都赋值给一个变量。
  */

  var __temp;

  (function(){
    if (featureTest) {
      return (__temp = function f(){});
    }
    return (__temp = function f(){});
  })();

  ...

  (function(){
    if (featureTest2) {
      return (__temp = function g(){});
    }
    return (__temp = function g(){});
  })();

  /*
    这样，后续的赋值语句通过“重用”前面的引用，达到了不过多占用内存的目的。
  */
</pre>
  <p>如果兼容Safari 2.x非常重要，就应该保证<strong>源代码中不能出现任何“不兼容”的结构</strong>。虽然这样做不免会让人着急上火，可只要抓住了问题的根源，还是绝对能够做到的。</p>
  <p>对了，还有个小问题必须说明一下：在Safari 2.x中声明命名函数时，函数的字符串表示不会包含函数的标识符：</p>
  <pre lang="javascript" class="prettyprint">
  var f = function g(){};

  // 看到了吗，函数的字符串表示中没有标识符g
  String(f); // function () { }
</pre>
  <p>这不算什么大问题。但正如我以前说过的，<a href="http://thinkweb2.com/projects/prototype/those-tricky-functions/" target="_blank">函数的反编译结果是无论如何也不能相信的</a>。 </p>
  <h2 id="spidermonkey-peculiarity">SpiderMonkey的怪癖</h2>
  <p> 大家都知道，命名函数表达式的标识符只在函数的局部作用域中有效。但包含这个标识符的局部作用域又是什么样子的吗？其实非常简单。在命名函数表达式被求值时，会<strong>创建一个特殊的对象</strong>，该对象的唯一目的就是保存一个属性，而这个属性的名字对应着函数标识符，属性的值对应着那个函数。这个对象会被注入到当前作用域链的前端。然后，被“扩展”的作用域链又被用于初始化函数。 </p>
  <p> 在这里（想象一下本山大叔在小品《火炬手》中发表获奖感言的情景吧。——译者注），有一点十分有意思，那就是ECMA-262定义这个（保存函数标识符的）“特殊”对象的方式。标准说<strong>“像调用new Object()表达式那样”</strong>创建这个对象。如果从字面上来理解这句话，那么这个对象就应该是全局<code>Object</code>的一个实例。然而，只有一个实现是按照标准字面上的要求这么做的，这个实现就是SpiderMonkey。因此，在SpiderMonkey中，扩展<code>Object.prototype</code>有可能会干扰函数的局部作用域： </p>
  <pre lang="javascript" class="prettyprint">
  
  Object.prototype.x = 'outer';
  
  (function(){
    
    var x = 'inner';
    
    /*
      函数foo的作用域链中有一个特殊的对象——用于保存函数的标识符。这个特殊的对象实际上就是{ foo: &lt;function object&gt; }。
      当通过作用域链解析x时，首先解析的是foo的局部环境。如果没有找到x，则继续搜索作用域链中的下一个对象。下一个对象
      就是保存函数标识符的那个对象——{ foo: &lt;function object&gt; }，由于该对象继承自Object.prototype，所以在此可以找到x。
      而这个x的值也就是Object.prototype.x的值（outer）。结果，外部函数的作用域（包含x = 'inner'的作用域）就不会被解析了。
    */
    
    (function foo(){
      
      alert(x); // 提示框中显示：outer
    
    })();
  })();
  
</pre>
  <p> 不过，更高版本的SpiderMonkey<strong>改变了上述行为</strong>，原因可能是认为那是一个安全漏洞。也就是说，“特殊”对象不再继承<code>Object.prototype</code>了。不过，如果你使用Firefox 3或者更低版本，还可以“重温”这种行为。 </p>
  <p id="activation-object-in-blackberry-browser"> 另一个把内部对象实现为全局<code>Object</code>对象的是<strong>黑莓（Blackberry）浏览器</strong>。目前，它的<em>活动对象（Activation Object）</em>仍然继承<code>Object.prototype</code>。可是，ECMA-262并没有说<em>活动对象</em>也要“像调用new Object()表达式那样”来创建（或者说像创建保存NFE标识符的对象一样创建）。
    人家规范只说了<em>活动对象</em>是规范中的一种机制。 </p>
  <p>好，那我们下面就来看看黑莓浏览器的行为吧：</p>
  <pre lang="javascript" class="prettyprint">
  
  Object.prototype.x = 'outer';
  
  (function(){
    
    var x = 'inner';
    
    (function(){
      
      /*
      在沿着作用域链解析x的过程中，首先会搜索局部函数的活动对象。当然，在该对象中找不到x。
      可是，由于活动对象继承自Object.prototype，因此搜索x的下一个目标就是Object.prototype；而
      Object.prototype中又确实有x的定义。结果，x的值就被解析为——outer。跟前面的例子差不多，
      包含x = 'inner'的外部函数的作用域（活动对象）就不会被解析了。
      */
      
      alert(x); // 提示框中显示：outer
      
    })();
  })();
</pre>
  <p> 虽然这有点让人不可思议，但更令人匪夷所思的则是函数中的变量甚至会与已有的<code>Object.prototype</code>的成员发生冲突： </p>
  <pre lang="javascript" class="prettyprint">
  (function(){
    
    var constructor = function(){ return 1; };
    
    (function(){
      
      constructor(); // 求值结果是{}（即相当于调用了Object.prototype.constructor()。——译者注）而不是1
      
      constructor === Object.prototype.constructor; // true
      toString === Object.prototype.toString; // true
      
      // ……
      
    })();
  })();
</pre>
  <h2 id="solution">解决方案</h2>
  <pre lang="javascript" class="prettyprint">
  var fn = (function(){

    // 声明要引用函数的变量
    var f;

    // 有条件地创建命名函数
    // 并将其引用赋值给f
    if (true) {
      f = function F(){ }
    }
    else if (false) {
      f = function F(){ }
    }
    else {
      f = function F(){ }
    }

    // 声明一个与函数名（标识符）对应的变量，并赋值为null
    // 这实际上是给相应标识符引用的函数对象作了一个标记，
    // 以便垃圾回收器知道可以回收它了
    var F = null;

    // 返回根据条件定义的函数
    return f;
  })();
</pre>
  <p>最后，我要给出一个应用上述“技术”的实例。这是一个跨浏览器的<code>addEvent</code>函数的代码：</p>
  <pre lang="javascript" class="prettyprint">

  // 1) 使用独立的作用域包含声明
  var addEvent = (function(){

    var docEl = document.documentElement;

    // 2) 声明要引用函数的变量
    var fn;

    if (docEl.addEventListener) {

      // 3) 有意给函数一个描述性的标识符
      fn = function addEvent(element, eventName, callback) {
        element.addEventListener(eventName, callback, false);
      }
    }
    else if (docEl.attachEvent) {
      fn = function addEvent(element, eventName, callback) {
        element.attachEvent('on' + eventName, callback);
      }
    }
    else {
      fn = function addEvent(element, eventName, callback) {
        element['on' + eventName] = callback;
      }
    }

    // 4) 清除由JScript创建的addEvent函数
    //    一定要保证在赋值前使用var关键字
    //    除非函数顶部已经声明了addEvent
    var addEvent = null;

    // 5) 最后返回由fn引用的函数
    return fn;
  })();
</pre>
  <h2 id="alt-solution">替代方案</h2>
  <p>不要忘了，如果我们不想在调用栈中保留描述性的名字，实际上还有其他选择。换句话说，就是还存在不必使用命名函数表达式的方案。首先，很多时候都可以通过声明而非表达式定义函数。这个方案只适合不需要创建多个函数的情形：</p>
  <pre lang="javascript" class="prettyprint">
  var hasClassName = (function(){

    // 定义私有变量
    var cache = { };

    // 使用函数声明
    function hasClassName(element, className) {
      var _className = '(?:^|\\s+)' + className + '(?:\\s+|$)';
      var re = cache[_className] || (cache[_className] = new RegExp(_className));
      return re.test(element.className);
    }

    // 返回函数
    return hasClassName;
  })();
</pre>
  <p>显然，当存在多个分支函数定义时，这个方案就不能胜任了。不过，我最早见过<a href="http://tobielangel.com/" target="_blank" rel="nofollow">托比·兰吉（Tobiel Langel）</a>使用过一个很有味道的模式。他的这种模式是<strong>提前使用函数声明来定义所有函数，并分别为这些函数指定不同的标识符</strong>：</p>
  <pre lang="javascript" class="prettyprint">
  var addEvent = (function(){

    var docEl = document.documentElement;

    function addEventListener(){
      /* ... */
    }
    function attachEvent(){
      /* ... */
    }
    function addEventAsProperty(){
      /* ... */
    }

    if (typeof docEl.addEventListener != 'undefined') {
      return addEventListener;
    }
    elseif (typeof docEl.attachEvent != 'undefined') {
      return attachEvent;
    }
    return addEventAsProperty;
  })();
</pre>
  <p>虽然这个方案很优雅，但也不是没有缺点。第一，由于使用不同的标识符，导致丧失了命名的一致性。且不说这样好还是坏，最起码它不够清晰。有人喜欢使用相同的名字，但也有人根本不在乎字眼上的差别。可毕竟，不同的名字会让人联想到所用的不同实现。例如，在调试器中看到attachEvent，我们就知道<code>addEvent</code>是基于<code>attachEvent</code>的实现（即基于IE的事件模型。——译者注）。当然，基于实现来命名的方式也不一定都行得通。假如我们要提供一个API，并按照这种方式把函数命名为inner。那么API用户的很容易就会被相应实现的细节搞得晕头转向。（也许是因为inner这个名字太通用，不同实现中可能都会有，因此容易让人分不清这个API到底基于哪个实现。——译者注） </p>
  <p>要解决这个问题，当然就得想一套更合理的命名方案了。但关键是不要再额外制造麻烦。我现在能想起来的方案大概有如下几个：</p>
  <pre lang="javascript" class="prettyprint">
  'addEvent', 'altAddEvent', 'fallbackAddEvent'
  // 或者
  'addEvent', 'addEvent2', 'addEvent3'
  // 或者
  'addEvent_addEventListener', 'addEvent_attachEvent', 'addEvent_asProperty'
</pre>
  <p>另外，托比使用的模式还存在一个小问题，即增加内存占用。提前创建N个不同名字的函数，等于有N-1的函数是用不到的。具体来讲，如果<code>document.documentElement</code>中包含<code>attachEvent</code>，那么<code>addEventListener</code> 和<code>addEventAsProperty</code>则根本就用不着了。可是，他们都占着内存哪；而且，这些内存将永远都得不到释放，原因跟JScript臭哄哄的命名表达式相同——这两个函数都被“截留”在返回的那个函数的闭包中了。</p>
  <p>不过，增加内存占用这个问题确实没什么大不了的。如果某个库——例如Prototype.js——采用了这种模式，无非也就是多创建一两百个函数而已。只要不是（在运行时）重复地创建这些函数，而是只（在加载时）创建一次，那么就没有什么好担心的。</p>
  <h2 id="webkit-displayName">WebKit的displayName</h2>
  <p>WebKit团队在这个问题采取了有点儿另类的策略。囿于函数（包括匿名和命名函数）如此之差的表现力，WebKit引入了一个“特殊的”<code>displayName</code>属性（本质上是一个字符串），如果开发人员为函数的这个属性赋值，则该属性的值将在调试器或性能分析器中被显示在函数“名称”的位置上。<a href="http://www.alertdebugging.com/2009/04/29/building-a-better-javascript-profiler-with-webkit/" target="_blank" rel="nofollow">弗朗西斯科·托依玛斯基（Francisco Tolmasky）详细地解释了这个策略的原理和实现</a>。</p>
  <h2 id="future-considerations">对未来的思考</h2>
  <p>将来的ECMAScript-262第5版（目前还是草案）会引入所谓的<strong>严格模式（strict mode）</strong>。开启严格模式的实现会禁用语言中的那些不稳定、不可靠和不安全的特性。据说出于安全方面的考虑，<code>arguments.callee</code>属性将在严格模式下被“封杀”。因此，在处于严格模式时，访问<code>arguments.callee</code>会导致<code>TypeError</code>（参见ECMA-262第5版的10.6节）。而我之所以在此提到严格模式，是因为如果在基于第5版标准的实现中无法使用<code>arguments.callee</code>来执行递归操作，那么使用命名函数表达式的可能性就会大大增加。从这个意义上来说，理解命名函数表达式的语义及其bug也就显得更加重要了。</p>
  <pre lang="javascript" class="prettyprint">
  // 此前，你可能会使用arguments.callee
  (function(x) {
    if (x &lt;= 1) return 1;
    return x * arguments.callee(x - 1);
  })(10);
  
  // 但在严格模式下，有可能就要使用命名函数表达式
  (function factorial(x) {
    if (x &lt;= 1) return 1;
    return x * factorial(x - 1);
  })(10);
  
  // 要么就退一步，使用没有那么灵活的函数声明
  function factorial(x) {
    if (x &lt;= 1) return 1;
    return x * factorial(x - 1);
  }
  factorial(10);
</pre>
  <h2 id="credits">致谢</h2>
  <p><strong><em>理查德· 康福德（Richard Cornford）</em></strong>，是他率先<a href="http://groups.google.com/group/comp.lang.javascript/msg/5b508b03b004bce8" target="_blank" rel="nofollow">解释了JScript中命名函数表达式所存在的bug</a>。理查德解释了我在这篇文章中提及的大多数bug，所以我强烈建议大家去看看他的解释。我还要感谢<strong><em>Yann-Erwan Perio（这是中国人吗？——译者注）</em></strong>和<strong><em>道格拉斯·克劳克佛德（Douglas Crockford）</em></strong>，他们早在2003年就在<a href="http://groups.google.com/group/comp.lang.javascript/msg/03d53d114d176323" target="_blank" rel="nofollow">comp.lang.javascript论坛中提及并讨论NFE问题了</a>。</p>
  <p><strong><em>约翰-戴维·道尔顿（John-David Dalton）</em></strong>对“最终解决方案”提出了很好的建议。</p>
  <p><strong><em>托比·兰吉</em></strong>的点子被我用在了“替代方案”中。</p>
  <p><strong><em>盖瑞特·史密斯（Garrett Smith）</em></strong>和<strong><em>德米特里·苏斯尼科（Dmitry Soshnikov）</em></strong>对本文的多方面作出了补充和修正。</p>
  <p style="margin-top: 2em; background: #ffc; float: left; padding: 0.5em;"> 要提建议或者反馈错误吗？可以<a href="http://thinkweb2.com/projects/prototype/named-function-expressions-demystified/" title="" target="_blank" rel="nofollow">在这篇博文中留言</a> 或者<a href="http://cloudflare.com/email-protection.html#117a707f76706951767c70787d3f727e7c" title="给我写邮件吧" target="_blank" rel="nofollow">给我写封邮件</a>，随便，怎么都行。 <br>
    这篇文章也 <a href="http://github.com/kangax/nfe/tree/master" title="this article on github" target="_blank" rel="nofollow">通过github实现了版本管理</a>，访问这个链接可以看到本文的最新版本。 </p>
  <p style="float: right; margin-top: 2em; padding: 0.5em;"> 发表时间：<span class="dtstart">2009年6月17日</span> 最近修改：<span class="dtstart">2009年10月9日</span> </p>
 <div class="clearfix"></div>
</div>

      <footer>
        <p>&copy; justjavac 2012 
          基于 <a href="http://jekyllbootstrap.com" target="_blank" rel="nofollow" title="The Definitive Jekyll Blogging Framework">Jekyll Bootstrap</a>
          和 <a href="http://twitter.github.com/bootstrap/" target="_blank" rel="nofollow">Twitter Bootstrap</a> 构建, 
          源码托管在 <a href="https://github.com/justjavac/justjavac.github.com" target="_blank" rel="nofollow">github</a> 上
        </p>
      </footer>

    </div> <!-- /container -->
    
<div id="menu_fly">
    <ol>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#introduction">前言</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#expr-vs-decl">函数表达式与函数声明</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#function-statements">函数语句</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#named-expr">命名函数表达式</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#names-in-debuggers">调试器中的函数名</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#jscript-bugs">JScript的bug</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#jscript-memory-management">JScript的内存管理</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#tests">测试</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#safari-bug">Safari中存在的bug</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#spidermonkey-peculiarity">SpiderMonkey的怪癖</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#solution">解决方案</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#alt-solution">替代方案</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#webkit-displayName">WebKit的displayName</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#future-considerations">对未来的思考</a></li>
      <li><a href="http://justjavac.com/named-function-expressions-demystified.html#credits">致谢</a></li>
    </ol>
</div>


<script type="text/javascript">
  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-11003279-2']);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();
</script>

<script type="text/javascript">
$.fn.smartFloat=function(){var a=function(b){var c=b.position().top,d=b.css("position");$(window).scroll(function(){var e=$(this).scrollTop();if(e>c){if(window.XMLHttpRequest){b.css({position:"fixed",top:50})}else{b.css({top:e})}}else{b.css({position:"absolute",top:c})}})};return $(this).each(function(){a($(this))})};$("#menu_fly").smartFloat();
</script>

  <!-- UJian Button BEGIN -->
    <script type="text/javascript" src="http://v1.ujian.cc/code/ujian.js?type=slide&uid=1514075"></script>
    <a href="http://www.ujian.cc" rel="nofollow" style="border:0;"><img src="http://img.ujian.cc/pixel.png" alt="友荐云推荐" style="border:0;padding:0;margin:0;" /></a>
    <!-- UJian Button END -->

  </body>
</html>