1、JScript的Bug
IE的ECMAScript實現JScript嚴重混淆了命名函數表達式，搞得現很多人都出來反對命名函數表達式，而且即便是現在還一直在用的一版（IE8中使用的5.8版）仍然存在下列問題。
下面我們就來看看IE在實現中究竟犯了那些錯誤，俗話說知已知彼，才能百戰不殆。我們來看看如下幾個例子：
例1：函數表達式的標示符洩露到外部作用域
var f = function g(){};
typeof g; // "function"
前面我們說過，命名函數表達式的標示符在外部作用域是無效的，但JScript明顯是違反了這一規范，上面例子中的標示符g被解析成函數對象，這就亂了套了，很多難以發現的bug都是因為這個原因導致的。
注：IE9以後貌似已經修復了這個問題
例2：將命名函數表達式同時當作函數聲明和函數表達式
typeof g; // "function"
var f = function g(){};
特性環境下，函數聲明會優先於任何表達式被解析，上面的例子展示的是JScript實際上是把命名函數表達式當成函數聲明了，因為它在實際聲明之前就解析了g。
這個例子引出了下一個例子。
例3：命名函數表達式會創建兩個截然不同的函數對象！
var f = function g(){};
f === g; // false
f.expando = 'foo';
g.expando; // undefined
看到這裡，大家會覺得問題嚴重了，因為修改任何一個對象，另外一個沒有什麼改變，這太惡了。通過這個例子可以發現，創建2個不同的對象，也就是說如果你想修改f的屬性中保存某個信息，然後想當然地通過引用相同對象的g的同名屬性來使用，那問題就大了，因為根本就不可能。
再來看一個稍微復雜的例子：
例4：僅僅順序解析函數聲明而忽略條件語句塊
var f = function g() {
return 1;
};
if (false) {
f = function g(){
return 2;
};
}
g(); // 2
這個bug查找就難多了，但導致bug的原因卻非常簡單。首先，g被當作函數聲明解析，由於JScript中的函數聲明不受條件代碼塊約束，所以在這個很惡的if分支中，g被當作另一個函數function g(){ return 2 }，也就是又被聲明了一次。然後，所有“常規的”表達式被求值，而此時f被賦予了另一個新創建的對象的引用。由於在對表達式求值的時候，永遠不會進入“這個可惡if分支，因此f就會繼續引用第一個函數function g(){ return 1 }。分析到這裡，問題就很清楚了：假如你不夠細心，在f中調用了g，那麼將會調用一個毫不相干的g函數對象。
你可能會問，將不同的對象和arguments.callee相比較時，有什麼樣的區別呢？我們來看看：
var f = function g(){
return [
arguments.callee == f,
arguments.callee == g
];
};
f(); // [true, false]
g(); // [false, true]
可以看到，arguments.callee的引用一直是被調用的函數，實際上這也是好事，稍後會解釋。
還有一個有趣的例子，那就是在不包含聲明的賦值語句中使用命名函數表達式：
(function(){
f = function f(){};
})();
按照代碼的分析，我們原本是想創建一個全局屬性f（注意不要和一般的匿名函數混淆了，裡面用的是帶名字的聲明），JScript在這裡搗亂了一把，首先他把表達式當成函數聲明解析了，所以左邊的f被聲明為局部變量了（和一般的匿名函數裡的聲明一樣），然後在函數執行的時候，f已經是定義過的了，右邊的function f(){}則直接就賦值給局部變量f了，所以f根本就不是全局屬性。
了解了JScript這麼變態以後，我們就要及時預防這些問題了，首先防范標識符洩漏帶外部作用域，其次，應該永遠不引用被用作函數名稱的標識符；還記得前面例子中那個討人厭的標識符g嗎？——如果我們能夠當g不存在，可以避免多少不必要的麻煩哪。因此，關鍵就在於始終要通過f或者arguments.callee來引用函數。如果你使用了命名函數表達式，那麼應該只在調試的時候利用那個名字。最後，還要記住一點，一定要把命名函數表達式聲明期間錯誤創建的函數清理干淨。
2、JScript的內存管理
知道了這些不符合規范的代碼解析bug以後，我們如果用它的話，就會發現內存方面其實是有問題的，來看一個例子：
var f = (function(){
if (true) {
return function g(){};
}
return function g(){};
})();
我們知道，這個匿名函數調用返回的函數（帶有標識符g的函數），然後賦值給了外部的f。我們也知道，命名函數表達式會導致產生多余的函數對象，而該對象與返回的函數對象不是一回事。所以這個多余的g函數就死在了返回函數的閉包中了，因此內存問題就出現了。這是因為if語句內部的函數與g是在同一個作用域中被聲明的。這種情況下 ，除非我們顯式斷開對g函數的引用，否則它一直占著內存不放。
var f = (function(){
var f, g;
if (true) {
f = function g(){};
}
else {
f = function g(){};
}
// 設置g為null以後它就不會再占內存了
g = null;
return f;
})();
通過設置g為null，垃圾回收器就把g引用的那個隱式函數給回收掉了，為了驗證我們的代碼，我們來做一些測試，以確保我們的內存被回收了。
測試
測試很簡單，就是命名函數表達式創建10000個函數，然後把它們保存在一個數組中。等一會兒以後再看這些函數到底占用了多少內存。然後，再斷開這些引用並重復這一過程。下面是測試代碼：
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 < 10000; i++) {
arr[i] = createFn();
}
通過運行在Windows XP SP2中的任務管理器可以看到如下結果：
IE7: without `null`: 7.6K -> 20.3K with `null`: 7.6K -> 18K IE8: without `null`: 14K -> 29.7K with `null`: 14K -> 27K
如我們所料，顯示斷開引用可以釋放內存，但是釋放的內存不是很多，10000個函數對象才釋放大約3M的內存，這對一些小型腳本不算什麼，但對於大型程序，或者長時間運行在低內存的設備裡的時候，這是非常有必要的。
以上就是關於JScript的Bug與內存管理的全部介紹，希望對大家的學習有所幫助。