javascript中的delete使用詳解

更新時間：2013年04月11日 11:05:40 作者：

在這篇文章中作者從《JavaScript面向?qū)ο缶幊讨改稀芬粫嘘P于 delete 的錯誤講起，詳細講述了關于 delete 操作的實現(xiàn)，局限以及在不同瀏覽器和插件（這里指 firebug）中的表現(xiàn)

在這篇文章中作者從《JavaScript面向?qū)ο缶幊讨改稀芬粫嘘P于 delete 的錯誤講起，詳細講述了關于 delete 操作的實現(xiàn)，局限以及在不同瀏覽器和插件（這里指 firebug）中的表現(xiàn)。

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

...書中聲稱

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

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

>>> var sum = function(a, b) {return a+b;};
>>> var add = sum;
>>> delete sum;
true
>>> typeof sum;
"undefined"

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

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

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

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

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

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

復制代碼代碼如下:

 
var x = { a: 1 }; 
delete x.a; // true 
x.a; // undefined 

但卻不能刪除一個變量：

復制代碼代碼如下:

 
var x = 1; 
delete x; // false; 
x; // 1 

也不能刪除一個函數(shù)：

復制代碼代碼如下:

 
function x() {}; 
delete x; // false; 
typeof x; // "function" 

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

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

1.1、代碼的類型 | Type of code

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

1.全局代碼 Global code
2.函數(shù)代碼 Function code
3.Eval code

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

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

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

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

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

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

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

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

復制代碼代碼如下:

var GLOBAL_OBJECT = this;
var foo = 1;
GLOBAL_OBJECT.foo; // 1
function bar() {};
typeof GLOBAL_OBJECT.bar; // "function"
GLOBAL_OBJECT.bar === bar; // true

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

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

復制代碼代碼如下:

(function(foo) {
    var bar = 2;
    function baz() {};
    /*
        在抽象的過程中，
        特殊的'arguments'對象變成了所在函數(shù)的活化對象的屬性：
        ACTIVATION_OBJECT.arguments = arguments;
        ...參數(shù)'foo‘也是一樣：
        ACTIVATION_OBJECT.foo; // 1
        ...變量'bar'也是一樣：
        ACTIVATION_OBJECT.bar; // 2
        ...函數(shù)'baz'也是一樣：
        typeof ACTIVATION_OBJECT.baz; // "function"
      */
}) (1);

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

復制代碼代碼如下:

var GLOBAL_OBJECT = this;
eval('var foo = 1');
GLOBAL_OBJECT.foo; // 1;

(function() {
eval('var bar = 2');

    /*
        在抽象過程中
        ACTIVATION_OBJECT.bar; // 2
    */
}) ();

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

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

復制代碼代碼如下:

var GLOBAL_OBJECT = this;

/* 'foo'是全局對象的一個屬性，
它通過變量聲明而生成，因此擁有內(nèi)部屬性DontDelete
這就是為什么它不能被刪除*/
var foo = 1;
delete foo; // false
typeof foo; // "number"

/* 'bar'是全局對象的一個屬性，
它通過變量聲明而生成，因此擁有DontDelete子
這就是為什么它同樣不能被刪除*/
function bar() {};
delete bar; // false
typeof bar; // "function"

/* 'baz'也是全局對象的一個屬性，
然而，它通過屬性賦值而生成，因此沒有DontDelete
這就是為什么它可以被刪除*/
GLOBAL_OBJECT.baz = "baz";
delete GLOBAL_OBJECT.baz; // true
typeof GLOBAL_OBJECT.baz; // "undefined"

1.5、內(nèi)建和DontDelete | Build-ins and DontDelete

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

復制代碼代碼如下:

(function() {
    //不能刪除'arguments'，因為有DontDelete
    delete arguments; // false;
    typeof arguments; // "object"

    //也不能刪除函數(shù)的length,因為有DontDelete
    function f() {};
    delete f.length; // false;
    typeof f.length; // "number"
}) ();

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

復制代碼代碼如下:

(function(foo,bar) {
delete foo; // false
foo; // 1

delete bar; // false
bar; // "bah"
}) (1,"bah");

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

復制代碼代碼如下:

var GLOBAL_OBJECT = this;

/* 通過變量聲明生成全局對象的屬性，擁有DontDelete */
var foo = 1;

/* 通過未聲明的變量賦值生成全局對象的屬性，沒有DontDelete */
bar = 2;

delete foo; // false
delete bar; // true
注意：內(nèi)部屬性是在屬性生成時確定的，之后的賦值過程不會改變已有的屬性的內(nèi)部屬性。理解這一區(qū)別是重要的。

/* 'foo'創(chuàng)建的同時生成DontDelete */
function foo() {};

/* 之后的賦值過程不改變已有屬性的內(nèi)部屬性，DontDelete仍然存在 */
foo = 1;
delete foo; // false;
typeof foo; // "number"

/* 但賦值一個不存在的屬性時，創(chuàng)建了一個沒有內(nèi)部屬性的屬性，因此沒有DontDelete */
this.bar = 1;
delete bar; // true;
typeof bar; // "undefined"

二、Firebug 的混亂 | Firebug confusion

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

復制代碼代碼如下:

eval('var foo = 1;');
foo; // 1
delete foo; // true
typeof foo; // "undefined"

在函數(shù)代碼中也是一樣：

復制代碼代碼如下:

(function() {
    eval('var foo = 1;');
    foo; // 1
    delete foo; // true
    typeof foo; // "undefined"
}) ();

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

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

復制代碼代碼如下:

function x() { };
var x;
typeof x; // “function”

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

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

復制代碼代碼如下:

var x = 1;
function x() { };
typeof x; // "number"

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

復制代碼代碼如下:

var x = 1;
/*不能刪除，‘x'擁有DontDelete*/
delete x; // false
typeof x; // "number"

eval('function x() { }');
/* 屬性'x'現(xiàn)在指向函數(shù)，并且應該沒有DontDelete */
typeof x; // "function"
delete x; // 應該是‘true';
typeof x; // 應該是"undefined"

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

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

復制代碼代碼如下:

/*  第一個 alert 返回 “undefined”，因為賦值過程在聲明過程和eval執(zhí)行過程之后；
    第二個alert返回 “false”, 因為盡管x聲明的位置在eval之后，
    但是eval的執(zhí)行卻在變量聲明之后，因此已無法刪除 */
eval(' alert( x ); alert(delete x) ');
var x = 1;

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

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

我寫了一個簡單的測試單元來檢查全局代碼、函數(shù)代碼和Eval代碼的遵守情況。測試單元同時檢測了 delete 操作的返回值和屬性是否像預期那樣被刪除。 delete 的返回值并不像它的實際結(jié)果那樣重要，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 在刪除函數(shù) arguments 時存在問題，似乎這些屬性在創(chuàng)建時不帶 DontDelete，因此可以被刪除。 Safari 2.x 還有其他問題——刪除無引用時（例如delete 1）拋出錯誤（譯者按：IE 同樣有）；函數(shù)聲明生成了可刪除的屬性（奇怪的是變量聲明則正常）； eval 中的變量聲明變成不可刪除（而 eval 中的函數(shù)聲明則正常）。

與 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，即使該屬性通過變量或函數(shù)聲明而生成。

復制代碼代碼如下:

function foo() { };
delete foo; // false;
typeof foo; // "function"

this.foo = 1;
delete foo; // true
typeof foo; // "undefined"

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

四、IE bugs

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

復制代碼代碼如下:

this.x = 1;
delete x; // TypeError: Object doesn't support this action

而下面則是另一個：

復制代碼代碼如下:

var x =1;
delete this.x; // TypeError: Cannot delete 'this.x'
// 譯者按：在IE8下拋出此異常，在IE6,7下拋出的是和上面一樣的異常

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

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

復制代碼代碼如下:

this.x = 1;
delete this.x; // TypeError: Object doesn't support this action
delete x; // TypeError: Object doesn't support this action

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

復制代碼代碼如下:

x = 1;
delete x; // true

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

復制代碼代碼如下:

x = 1;
delete this.x; //TypeError: Cannot 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 (函數(shù)聲明的基礎)則與 this 引用的不同。

復制代碼代碼如下:

function getBase() { return this; };

getBase() === this.getBase(); // false
this.getBase() === this.getBase(); // true
window.getBase() === this.getBase(); // true
window.getBase() === getBase(); // false

五、誤解 | Misconceptions

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

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

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

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

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

復制代碼代碼如下:

/* 'alert'是'window‘的一個直接屬性（如果我們能夠相信'hasOwnProperty'） */
window.hasOwnProperty('alert'); // true

delete window.alert; // true
typeof window.alert; // "function"

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

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

七、ES5 嚴格模式 | ES5 strict mode

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

復制代碼代碼如下:

(function(foo) {
"use strict"; //在函數(shù)中開啟嚴格模式

    var bar;
    function baz;
    delete foo; // SyntaxError，當刪除函數(shù)參數(shù)時
    delete bar; // SyntaxError，當刪除變量時
    delete baz; // SyntaxError，當刪除由函數(shù)聲明創(chuàng)建的變量時

/* function實例的length擁有[[Configurable]] : false */
delete (function() {}).length; // TypeError
}) ();

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

復制代碼代碼如下:

"use strict";
delete i_dont_exist; // SyntaxError
i_dont_exist_either = 1; // ReferenceError

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

八、總結(jié) | Summary

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

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

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

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

您可能感興趣的文章:

JavaScript使用AOP編程思想實現(xiàn)監(jiān)聽HTTP請求
這篇文章主要為大家詳細介紹了如何在JavaScript使用AOP編程思想實現(xiàn)監(jiān)聽HTTP請求,文中的示例代碼講解詳細,感興趣的小伙伴可以跟隨小編一起學習一下
2024-02-02
js鼠標滑過彈出層的定位IE6bug解決辦法
大家在寫div+css的時候經(jīng)常會用到彈出層，由于IE6的bug，所以當使用多個標簽重復寫彈出層的時候會遇到后面的層壓在了彈出層的上面;用Jquery給彈出層的z軸依次增加高度可解決.代碼很簡單，效果很顯著,需要了解的朋友可以參考下
2012-12-12
JavaScript模板引擎應用場景及實現(xiàn)原理詳解
這篇文章主要介紹了JavaScript模板引擎應用場景及實現(xiàn)原理,結(jié)合實例形式詳細分析了javascript模版引擎的具體應用場景、實現(xiàn)原理、相關操作技巧與注意事項,需要的朋友可以參考下
2018-12-12
教你如何寫出可維護的JS代碼
在平時工作開發(fā)中，大部分開發(fā)人員都花費大量的時間在維護其他人員的代碼。很難從頭開始開發(fā)新代碼，很多情況下都是以他人成果為基礎的，或者新增修改需求，自己寫的代碼也會被其他開發(fā)人員調(diào)用，所以寫好一份高質(zhì)量可維護的代碼就顯得十分重要。
2021-05-05
js獲取窗口相對于屏幕左邊和上邊的位置坐標
這篇文章主要介紹了js如何獲取窗口相對于屏幕左邊和上邊的位置,需要的朋友可以參考下
2014-05-05
javascript實現(xiàn)根據(jù)時間段顯示問候語的方法
這篇文章主要介紹了javascript實現(xiàn)根據(jù)時間段顯示問候語的方法,涉及javascript時間與字符串的相關操作技巧,需要的朋友可以參考下
2015-06-06
javascript 打印內(nèi)容方法小結(jié)
關于JS打印問題！網(wǎng)上收集+自己總結(jié) ，需要的朋友可以參考下。
2009-11-11
純JavaScript代碼實現(xiàn)文本比較工具
之前項目需求需要寫一個純js文本比較工具，在此小編把代碼分享在腳本之家平臺供大家參考
2016-02-02
webpack-dev-server核心概念案例詳解
這篇文章主要介紹了webpack-dev-server核心概念案例詳解,本篇文章通過簡要的案例,講解了該項技術的了解與使用,以下就是詳細內(nèi)容,需要的朋友可以參考下
2021-09-09
分享javascript計算時間差的示例代碼
這篇文章主要為大家介紹了javascript計算時間差的示例代碼，，一般來說都是計算當前時間和一個指定時間點之間的差距，感興趣的小伙伴們可以參考一下
2016-01-01