在這篇文章中作者從《JavaScript面向對象編程指南》一書中關于 delete 的錯誤講起，詳細講述了關于 delete 操作的實現(xiàn)， 局限以及在不同瀏覽器和插件（這里指 firebug）中的表現(xiàn)。

下面翻譯其中的主要部分。

...書中聲稱

“函數就像一個普通的變量那樣——可以拷貝到不同變量，甚至被刪除”

并附上了下面的代碼片段作為說明：

你能發(fā)現(xiàn)片段中的問題嗎？ 這個問題就是——刪除 sum 變量的操作不應該成功； delete 的聲明不應該返回 true 而 typeof sum 也不應該返回為 undefined。 因為，javascript 中不能夠刪除變量，至少不能以這個方式聲明刪除。

那么這個例子發(fā)生了什么？ 是打印錯誤或者玩笑？ 應該不是。 這個片段是 firebug 控制臺中的一個實際輸出，而 Stoyan（上面所說書的作者）應該正是用它做的快速測試。 這仿佛說明了 firebug 有一些不同的刪除規(guī)則。 正是 firebug 誤導了 Stoyan！ 那么這里面究竟是怎么回事呢？

為了回答這個問題，我們需要了解 delete 運算符在 Javascript 中是如何工作的： 哪些可以被刪除，哪些不能刪除以及為什么。 下面我試著解釋一下這方面的細節(jié)。 我們將通過觀察 firebug 的“奇怪”的表現(xiàn)而認識到它實際上完全不“奇怪”； 我們將深入了解那些，當我們聲明變量、函數，賦值屬性和刪除它們時的，隱藏在背后的細節(jié)； 我們將看一下瀏覽器對此的實現(xiàn)和一些有名的 bug； 我們還會討論到 ECMAScript 版本 5 中的嚴格模式(strict mode)以及它如何改變 delete 運算符的行為。

我在下面交替使用的 Javascript 和 ECMPScript 一般都指 ECMAScript(除非當明確談到 Mozilla 的 JavaScript™ 實現(xiàn)時)。

意料之中的，網絡上目前對于 delete 的解釋非常少（筆者按：這篇文章寫于 2010 年 1 月）。 MDC(MDN]) 的資源大概是這其中最詳細的了，但不幸的是它遺漏了一些有趣的細節(jié)，這些細節(jié)中就包括了上述 firebug 的奇怪表現(xiàn)。MSDN 文檔幾乎沒什么用處。

一、理論 | Theory
那么，為什么我們能刪除一個對象的屬性：

但卻不能刪除一個變量：

也不能刪除一個函數：

注意：delete 只有當一個屬性無法被刪除時才返回 false。

為了理解這一點，我們需要首先把握一些概念： 變量實例化（variable instantiation）和屬性的內部屬性（property attributes） （譯者按：關于 property 和 attributes 的區(qū)別見參考文章，根據下面涉及到的內容，擬譯成內部屬性） ——這些很少在 javascript 書中被提到。 在下面幾段中我將試著簡短地回顧這些內容，要理解它們并不難。 如果你并不關注它們表現(xiàn)背后的原因，可以跳過這一章。

1.1、代碼的類型 | Type of code

ECMAScript 中有三類可執(zhí)行代碼：

1.全局代碼 Global code
2.函數代碼 Function code
3.Eval code

這幾類的含義大致就像它們命名的那樣，但還是快速地回顧一下：

1.當一個源文件被看做是一個程序，它在全局作用域(scope)內執(zhí)行，而這就被認為是一段全局代碼 Global code。 在瀏覽器環(huán)境下，SCRIPT 元素的內容通常都被解析為一個程序，因而作為全局代碼來執(zhí)行。

2.當然，任何在一段函數中直接執(zhí)行的代碼就被認為是一段函數代碼 Function code， 在瀏覽器環(huán)境下，事件屬性的內容（e.g. <a onclick="..."）通常都作為函數代碼來解析和執(zhí)行。

3.最后，放入內建函數 eval 中的代碼就作為 Eval code 來解析。 我們將很快看到為什么這一類型是特殊的。

1.2、代碼執(zhí)行的上下文 | Execution Context
當 ECMAScript 代碼執(zhí)行時，它總是發(fā)生在一個確定的執(zhí)行上下文(context)中。 執(zhí)行作用域是一個抽象實體，它有助于理解作用域和變量實例化的工作原理。 上面三類可執(zhí)行代碼都有各自的執(zhí)行上下文。 當函數代碼執(zhí)行時，我們說控制端進入了函數代碼的執(zhí)行上下文； 當全局代碼執(zhí)行時，我們說控制端進入了全局代碼的執(zhí)行上下文，以此類推。

正如你所見，執(zhí)行上下文在邏輯上是一個棧（stack）。 首先可能有一段全局代碼，它擁有屬于自己的執(zhí)行上下文； 在這段代碼中可能調用一個函數，這個函數同樣擁有屬于自己的執(zhí)行上下文； 這個函數可能調用另一個函數，等等。 即使當函數遞歸調用自己時，在每一步調用中仍然進入了不同的執(zhí)行上下文。

1.3、活化對象和變量對象 | Activation object / Variable object
每一個執(zhí)行上下文都有一個與之相關聯(lián)的變量對象（Variable object）。 和它相似的，變量對象也是一個抽象實體，一種用來描述變量實例化的機制。 而有趣的是，在一段源代碼中聲明的變量和函數事實上被作為變量對象（Variable object）的屬性（properties）而添加到變量對象中。

當控制進入了全局代碼的執(zhí)行上下文時，一個全局對象被用作變量對象。 這恰恰是為什么全局聲明的變量和函數變成一個全局對象的屬性的原因：

Ok, 所以全局變量成了全局函數的屬性，那么局部變量——那些在函數代碼（Function code）中聲明的變量呢？ 事實上那很簡單：他們也成了變量對象的屬性。 唯一的區(qū)別是，在函數代碼中，變量對象不是一個全局對象， 而是一個我們稱之為活化對象（Activation object）。 每次進入函數代碼的執(zhí)行上下文時都會創(chuàng)建一個活化對象。

并非只有在函數代碼中聲明的變量和函數才成為活化對象的屬性： 函數的每一個實參（arguments，以各自相對應的形參的名字為屬性名）， 以及一個特殊的Arguments對象(以arguments為屬性名)同樣成為了活化對象的屬性。 需要注意的是，活化對象作為一個內部的機制事實上不能被程序代碼所訪問。

最后，Eval code 中聲明的變量成為了上下文的變量對象（context's Variable object）的屬性。 Eval code 簡單地使用在它調用中的執(zhí)行上下文的變量對象。

1.4、屬性的內部屬性 | Property attributes
就要接近主題了。 現(xiàn)在我們明確了變量發(fā)生了什么（它們成了屬性），剩下的需要理解的概念就是屬性的內部屬性（property attributes）。 每一個屬性擁有零至多個如內部屬性——*ReadOnly，DontEnum，DontDelete和Internal**。 你可以把它們想象為標簽——一個屬性可能擁有也可能沒有某個特殊的內部屬性。 在今天的討論中，我們所感興趣的是 DontDelete。

當聲明變量和函數時，它們成為了變量對象（Variable object）——要么是活化對象（在函數代碼中）， 要么是全局對象（在全局代碼中）——的屬性，這些屬性伴隨生成了內部屬性 DontDelete。 然而，任何顯式/隱式賦值的屬性不生成 DontDelete。 而這就是本質上為什么我們能刪除一些屬性而不能刪除其他的原因。

1.5、內建和DontDelete | Build-ins and DontDelete

所以這就是所有這一切發(fā)生的原因：屬性的一個特殊的內部屬性控制著該屬性是否可以被刪除。 注意：內建對象的一些屬性擁有內部屬性 DontDelete，因此不能被刪除； 特殊的 arguments 變量（如我們所知的，活化對象的屬性）擁有 DontDelete； 任何函數實例的 length (返回形參長度)屬性也擁有 DontDelete：

與函數 arguments 相關聯(lián)的屬性也擁有 DontDelete，同樣不能被刪除

1.6、未聲明的變量賦值 | Undeclared assignments
你可能記得，未聲明的變量賦值會成為全局對象的屬性，除非這一屬性在作用域鏈內的其他地方被找到。 而現(xiàn)在我們了解了屬性賦值和變量聲明的區(qū)別——后者生成 DontDelete 而前者不生成——這也就是為什么未聲明的變量賦值可以被刪除的原因了。

二、Firebug 的混亂 | Firebug confusion

那么， firebug 中發(fā)生了什么？ 為什么在控制臺中聲明的變量能夠被刪除，而不是想我們之前討論的那樣？ 我之前說過，Eval code 在它處理變量聲明時有一個特殊的行為： 在 Eval code 中聲明的變量事實上生成一個沒有 DontDelete 的屬性。

在函數代碼中也是一樣：

而這就是 Firebug 中異常行為的原因了。 所有在控制臺中的調試文本似乎是以 Eval code 來編譯和執(zhí)行的，而不是在全局或函數代碼中執(zhí)行。 顯然，其中的變量聲明最終都生成了不帶 DontDelete 的屬性，所以可以被刪除。 所以要小心普通的全局代碼和 Firebug 控制臺中代碼的區(qū)別。

2.1、通過eval刪除變量 | Delete variables via eval
這個有趣的 eval 行為，結合 ECMAScript 的另一個方面可以在技術上允許我們刪除那些原本不能刪除的屬性。 這個方面是關于函數聲明——在相同的執(zhí)行上下文中它們能覆蓋同名的變量：

那么為什么函數聲明擁有優(yōu)先權而能覆蓋同名變量（或者換句話說，變量對象(Variable object)的相同屬性）呢？ 這是因為函數聲明的實例化過程在變量聲明之后，因此可以覆蓋它們。

（譯者按：函數聲明只能覆蓋聲明而未賦值的同名變量，如果在聲明時賦值了值（e.g. var x = 1）則賦值值的過程在函數初始化之后，函數聲明反而被變量賦值所覆蓋，如下：）

函數聲明不止替換了屬性的值，同時也替換了它的內部屬性。 如果我們通過 eval 來聲明函數，這一函數也將用它自己的內部屬性來替換之前的。 而由于在 eval 中聲明的變量生成的屬性沒有 DontDelete， 實例化這個函數將在“理論上”移除原屬性已有的 DontDelete 內部屬性， 而使得這一屬性可以刪除（當然，同時也將值指向了新生成的函數）。

不幸的是，這種欺騙技術在我嘗試的各個瀏覽器中都沒有成功。 這里我可能錯過了什么，或者這個行為太隱蔽而以至于各個瀏覽器沒有注意到它。

（譯者按：這里的問題可能在于：函數聲明和變量聲明之間的覆蓋只是值指向的改變， 而內部屬性 DontDelete 則在最初聲明處確定而不再改變，而 eval 中聲明的變量和函數，也只是在其外部上下文中未聲明過的那部分才能被刪除。 關于執(zhí)行順序，由于 eval 作為函數，它的調用永遠在其外部上下文中其他變量和函數聲明之后， 因此相關的內部屬性也已確定，覆蓋的只是值的指向。如下：）

三、瀏覽器的遵守情況 | Browsers compliance

了解事物的工作原理是重要的，但實際的實現(xiàn)情況更重要。 瀏覽器在創(chuàng)建和刪除變量/屬性時都遵守這些標準嗎？ 對于大部分來說，是的。

我寫了一個簡單的測試單元來檢查全局代碼、函數代碼和Eval代碼的遵守情況。 測試單元同時檢測了 delete 操作的返回值和屬性是否像預期那樣被刪除。 delete 的返回值并不像它的實際結果那樣重要，delete 操作返回 true 或 false 并不重要， 重要的是擁有/沒有 DontDelete 的屬性是否被刪除。

現(xiàn)代瀏覽器總的來說還是遵守刪除規(guī)則的，以下瀏覽器全部通過測試： Opera 7.54+, Firefox 1.0+, Safari 3.1.2+, Chrome 4+。

Safari 2.x 和 3.0.4 在刪除函數 arguments 時存在問題，似乎這些屬性在創(chuàng)建時不帶 DontDelete，因此可以被刪除。 Safari 2.x 還有其他問題——刪除無引用時（例如delete 1）拋出錯誤（譯者按：IE 同樣有）； 函數聲明生成了可刪除的屬性（奇怪的是變量聲明則正常）； eval 中的變量聲明變成不可刪除（而 eval 中的函數聲明則正常）。

與 Safari 類似，Konqueror（3.5，而非4.3）在 delete 無引用和刪除 arguments 是也存在同樣問題。

3.1、Gecko DontDelete bug
Gecko 1.8.x 瀏覽器—— Firefox 2.x, Camino 1.x, Seamonkey 1.x, etc. ——存在一個有趣的 bug：顯式賦值值給一個屬性能移除它的 DontDelete，即使該屬性通過變量或函數聲明而生成。

令人驚訝的是，IE5.5-8 也通過了絕大部分測試，除了刪除非引用拋出錯誤（e.g. delete 1，就像舊的 Safari）。 但是，雖然不能馬上發(fā)現(xiàn)，事實上 IE 存在更嚴重的 bug，這些 bug 是關于全局對象。

四、IE bugs

在 IE 中（至少在 IE6-8 中），下面的表達式拋出異常（在全局代碼中）：

而下面則是另一個：

這似乎說明，在 IE 中在全局代碼中的變量聲明并沒有生成全局對象的同名屬性。 通過賦值創(chuàng)建的屬性（this.x = 1）然后通過 delete x 刪除時拋出異常； 通過變量聲明（var x = 1）創(chuàng)建的屬性然后通過 delete this.x 刪除時拋出另一個（譯者按：在 IE6,7 下錯誤信息與上面的相同）。

但不只是這樣，事實上通過顯式賦值創(chuàng)建的屬性在刪除時總是拋出異常。 這不只是一個錯誤，而是創(chuàng)建的屬性看上去擁有了 DontDelete 內部屬性，而按規(guī)則應該是沒有的：

另一方面，未聲明的變量賦值（那些同樣生成全局對象的屬性）又確實在IE下能夠正常刪除：

但如果你試圖通過 this 關鍵字來進行刪除（delete this.x），那么上面的異常又將拋出：

如果歸納一下，我們將發(fā)現(xiàn)在全局代碼中‘delete this.x'永遠不會成功。 當通過顯式賦值來生成屬性（this.x = 1）時拋出一個異常； 當通過聲明/非聲明變量的方式（var x = 1 or x = 1）生成屬性時拋出另一個異常。 而另一方面，delete x 只有在顯示賦值生成屬性(this.x = 1)時才拋出異常。

在 9 月我討論了這個問題，其中 Garrett Smith 認為在 IE 中全局變量對象（Global variable object）實現(xiàn)為一個 JScript 對象，而全局對象則由宿主對象實現(xiàn)。

我們能通過幾個測試來在某種程度上確認這一理論。 注意，this 和 window 似乎引用同一個對象（如果 ‘==='運算符可以信任的話）， 而變量對象 Variable object (函數聲明的基礎)則與 this 引用的不同。

五、誤解 | Misconceptions

我們不能低估理解事物工作原理的重要性。 我看過網絡上一些關于 delete 操作的誤解。 例如，Stackoverflow 上的一個答案（而且等級還很高），里面解釋說“delete is supposed to be no-op when target isn't an object property”。 現(xiàn)在我們了解了 delete 操作的核心，也就清楚了這個答案是不正確的。 delete 不區(qū)分變量和屬性（事實上在 delete 操作中這些都是引用），而只關心 DontDelete（以及屬性是否已經存在）。

六、'delete'和宿主對象 | 'delete‘ and host object

一個 delete 的算法大致像這樣：

1. 如果運算元(operand)不是引用，返回 true
2. 如果對象沒有同名的**直接屬性**，返回 true (如我們所知，對象可以是全局對象也可以是活化對象)
3. 如果屬性已經存在但有 DontDelete，返回 false
4. 否則，刪除移除屬性并返回 true
然而，對于宿主對象（host object）的 delete 操作的行為卻可能是不可預料的。 而事實上這并沒有錯：宿主對象（通過一定規(guī)則）允許實現(xiàn)任何操作， 例如讀（內部[[Get]]方法）、寫（內部[[Write]]方法）、刪除（內部[[Delete]]方法），等等。 這種允許自定義[[Delete]]行為導致了宿主對象的混亂。

我們已經看到了在IE中的一些問題：當刪除某些對象（那些實現(xiàn)為了宿主對象）屬性時拋出異常。 一些版本的 firefox 當試圖刪除 window.location 時拋出異常（譯者按：IE 同樣拋出）。 同樣，在一些宿主對象中你也不能相信 delete 的返回值， 例如下面發(fā)生在 firefox 中的(譯者按：chrome 中同樣結果；IE 中拋出異常；opera 和 safari 允許刪除，并且刪除后無法調用，姑且算'正常‘，盡管，從下面的討論來看似乎卻是不正常的，它們事實上刪除了不能刪除的屬性，而前面的瀏覽器沒有)：

delete window.alert 返回 true，盡管這個屬性沒有任何條件可能產生這個結果（按照上面的算法）： 它解析為一個引用，因此不能在第一步返回 true； 它是 window 對象的直接屬性，因此不能在第二步返回 true； 唯一能返回 true 的是當算法達到最后一步同時確實刪除這個屬性，而事實上它并沒有被刪除。 （譯者按：不，在 opera 和 safari 中確實被刪除了...）。

所以這個故事告訴我們永遠不要相信宿主對象。

七、ES5 嚴格模式 | ES5 strict mode

那么 ECMAScript 第 5 版中的嚴格模式將帶來什么？ 目前介紹了其中的一些限制。 當刪除操作指向一個變量/函數參數/函數聲明的直接引用時拋出 SyntaxError。 此外，如果屬性擁有內部屬性[[Configurable]] == false，將拋出 TypeError：

而且，在嚴格模式下，刪除未聲明的變量（換句話說，未解析的引用），同樣拋出 SyntaxError； 與它類似的，相同模式下未聲明的賦值也將拋出異常（ReferenceError）

看了之前給出的變量、函數聲明和參數的例子，相信現(xiàn)在你也理解了，所有這些限制都是有其意義的。 嚴格模式采取了更積極的和描述性的措施，而不只是忽略這些問題。

八、總結 | Summary

由于這篇文章已經很長了，因此我就不再討論另一些內容（e.g.通過 delete 刪除數組項及其影響）。 你可以翻閱 MDC/MDN 上的文章或閱讀規(guī)范然后自己測試。

下面是關于 Javascript 中 delete 如何工作的一個簡單的總結：

•變量和函數聲明都是活化(Activation)全局(Global)對象的屬性。
•屬性擁有內部屬性，其中一個—— DontDelete 負責確定一個屬性是否能夠被刪除。
•全局代碼或函數代碼中的變量、函數聲明都生成擁有 DontDelete 的屬性。
•函數參數同樣是活化對象的屬性，也擁有 DontDelete。
•Eval代碼中的變量和函數聲明都生成沒有 DontDelete 的屬性。
•新的未聲明的屬性在生成時帶空的內部屬性，因此也沒有 DontDelete。
•宿主對象允許以任何它們期望的方式來響應刪除過程。

原文：Understanding delete譯文：javascript 中的 delete譯者：justjavac