摘要：反之亦然非嚴格合并嚴格看起來是非嚴格的。在普通的里面給一個拼寫錯誤的變量名賦值會使全局對象新增一個屬性并繼續(xù)工作盡管后面可能出錯在現(xiàn)在的中有可能。第三嚴格模式禁止刪除聲明變量。

文章整理自MSDN：https://developer.mozilla.org...

ECMAScript 5的嚴格模式是JavaScript中的一種限制性更強的變種方式。嚴格模式不是一個子集：它在語義上與正常代碼有著明顯的差異。不支持嚴格模式的瀏覽器與支持嚴格模式的瀏覽器行為上也不一樣， 所以不要在未經(jīng)嚴格模式特性測試情況下使用嚴格模式。嚴格模式可以與非嚴格模式共存，所以腳本可以逐漸的選擇性加入嚴格模式。
如果你想讓你的JavaScript代碼在嚴格模式下運行，可以參考轉(zhuǎn)換成嚴格模式。

嚴格模式在語義上與正常的JavaScript有一些不同：
首先，嚴格模式會將JavaScript陷阱直接變成明顯的錯誤。
其次，嚴格模式修正了一些引擎難以優(yōu)化的錯誤：同樣的代碼有些時候嚴格模式會比非嚴格模式下更快。 第三，嚴格模式禁用了一些有可能在未來版本中定義的語法。

嚴格模式可以應(yīng)用到整個script標簽或個別函數(shù)中。不要在封閉大括?。?{} ）內(nèi)這樣做;在這樣的上下文中這么做是沒有效果的。在eval 代碼，F(xiàn)unction 代碼，事件處理屬性，傳入 setTimeout方法的字符串和包含整個腳本的塊中開啟嚴格模式會如預期一樣工作。

（1）為某個script標簽開啟嚴格模式

為整個script標簽開啟嚴格模式, 需要在所有語句之前放一個特定語句 "use strict"; （或 "use strict";）

// 整個語句都開啟嚴格模式的語法
"use strict";
var v = "Hi!  I"m a strict mode script!";

這種語法存在陷阱，有一個大型網(wǎng)站已經(jīng)被它坑倒了：不能盲目的合并沖突代碼。試想合并一個嚴格模式的腳本和一個非嚴格模式的腳本：合并后的腳本代碼看起來是嚴格模式。反之亦然：非嚴格合并嚴格看起來是非嚴格的。合并均為嚴格模式的腳本或均為非嚴格模式的都沒問題，只有在合并嚴格模式與非嚴格模式有可能有問題。建議按一個個函數(shù)去開啟嚴格模式（至少在學習的過渡期要這樣做）.

您也可以將整個腳本的內(nèi)容用一個函數(shù)包括起來，然后在這個外部函數(shù)中使用嚴格模式。這樣做就可以消除合并的問題，但是這就意味著您必須要在函數(shù)作用域外聲明一個全局變量。

（2）為某個函數(shù)開啟嚴格模式

同樣的，要給某個函數(shù)開啟嚴格模式，得把 "use strict"; (或 "use strict"; )聲明一字不漏地放在函數(shù)體所有語句之前。

function strict(){
  // 函數(shù)級別嚴格模式語法
  "use strict";
  function nested() { return "And so am I!"; }
  return "Hi!  I"m a strict mode function!  " + nested();
}
function notStrict() { return "I"m not strict."; }

嚴格模式同時改變了語法及運行時行為。

變化通常分為這幾類：

（1）將問題直接轉(zhuǎn)化為錯誤（如語法錯誤或運行時錯誤）
（2）簡化了如何為給定名稱的特定變量計算
（3）簡化了 eval 以及 arguments
（4）將寫"安全JavaScript"的步驟變得更簡單
（5）以及改變了預測未來ECMAScript行為的方式

在嚴格模式下, 先前被接受的拼寫錯誤將會被認為是異常. JavaScript被設(shè)計為能使新人開發(fā)者更易于上手, 所以有時候會給本來錯誤操作賦予新的不報錯誤的語義(non-error semantics). 有時候這可以解決當前的問題, 但有時候卻會給以后留下更大的問題. 嚴格模式則把這些失誤當成錯誤, 以便可以發(fā)現(xiàn)并立即將其改正.

首先，嚴格模式下無法再意外創(chuàng)建全局變量。在普通的JavaScript里面給一個拼寫錯誤的變量名賦值會使全局對象新增一個屬性并繼續(xù)“工作”（盡管后面可能出錯：在現(xiàn)在的JavaScript中有可能）。嚴格模式中意外創(chuàng)建全局變量被拋出錯誤替代：

"use strict";
                       // 假如有一個全局變量叫做mistypedVariable
mistypedVaraible = 17; // 因為變量名拼寫錯誤（省略了var變量聲明）
                       // 這一行代碼就會拋出 ReferenceError

其次, 嚴格模式會使引起靜默失敗(silently fail,注:不報錯也沒有任何效果)的賦值操拋出異常. 例如, NaN 是一個不可寫的全局變量. 在正常模式下, 給 NaN 賦值不會產(chǎn)生任何作用; 開發(fā)者也不會受到任何錯誤反饋. 但在嚴格模式下, 給 NaN 賦值會拋出一個異常. 任何在正常模式下引起靜默失敗的賦值操作 (給不可寫屬性賦值, 給只讀屬性(getter-only)賦值賦值, 給不可擴展對象(non-extensible object)的新屬性賦值) 都會拋出異常:

"use strict";

// 給不可寫屬性賦值
var obj1 = {};
Object.defineProperty(obj1, "x", { value: 42, writable: false });
obj1.x = 9; // 拋出TypeError錯誤

// 給只讀屬性賦值
var obj2 = { get x() { return 17; } };
obj2.x = 5; // 拋出TypeError錯誤

// 給不可擴展對象的新屬性賦值
var fixed = {};
Object.preventExtensions(fixed);
fixed.newProp = "ohai"; // 拋出TypeError錯誤

第三, 在嚴格模式下, 試圖刪除不可刪除的屬性時會拋出異常(之前這種操作不會產(chǎn)生任何效果):

"use strict";
delete Object.prototype; // 拋出TypeError錯誤

第四，在Gecko版本34之前，嚴格模式要求一個對象內(nèi)的所有屬性名在對象內(nèi)必須唯一。正常模式下重名屬性是允許的，最后一個重名的屬性決定其屬性值。因為只有最后一個屬性起作用，當代碼是要改變屬性值而卻不是修改的最后一個重名屬性的時候，復制這個對象就產(chǎn)生一連串的bug。在嚴格模式下，重名屬性被認為是語法錯誤：

這個問題在ECMAScript6中已經(jīng)不復存在(bug 1041128)。

"use strict";
var o = { p: 1, p: 2 }; // !!! 語法錯誤

第五, 嚴格模式要求函數(shù)的參數(shù)名唯一. 在正常模式下, 最后一個重名參數(shù)名會掩蓋之前的重名參數(shù). 之前的參數(shù)仍然可以通過 arguments[i] 來訪問, 還不是完全無法訪問. 然而, 這種隱藏毫無意義而且可能是意料之外的 (比如它可能本來是打錯了), 所以在嚴格模式下重名參數(shù)被認為是語法錯誤:

function sum(a, a, c){ // !!! 語法錯誤
  "use strict";
  return a + b + c; // 代碼運行到這里會出錯
}

第六, 嚴格模式禁止八進制數(shù)字語法. ECMAScript并不包含八進制語法, 但所有的瀏覽器都支持這種以零(0)開頭的八進制語法: 0644 === 420 還有 "045" === "%".在ECMAScript 6中支持為一個數(shù)字加"0o"的前綴來表示八進制數(shù).

var a = 0o10; // ES6: 八進制

有些新手開發(fā)者認為數(shù)字的前導零沒有語法意義, 所以他們會用作對齊措施 — 但其實這會改變數(shù)字的意義! 八進制語法很少有用并且可能會錯誤使用, 所以嚴格模式下八進制語法會引起語法錯誤:

"use strict";
var sum = 015 + // !!! 語法錯誤
          197 +
          142;

第七，ECMAScript 6中的嚴格模式禁止設(shè)置primitive值的屬性.不采用嚴格模式,設(shè)置屬性將會簡單忽略(no-op),采用嚴格模式,將拋出TypeError錯誤

(function() {
"use strict";

false.true = "";              //TypeError
(14).sailing = "home";        //TypeError
"with".you = "far away";      //TypeError

})();

嚴格模式簡化了代碼中變量名字映射到變量定義的方式. 很多編譯器的優(yōu)化是依賴存儲變量X位置的能力：這對全面優(yōu)化JavaScript代碼至關(guān)重要. JavaScript有些情況會使得代碼中名字到變量定義的基本映射只在運行時才產(chǎn)生. 嚴格模式移除了大多數(shù)這種情況的發(fā)生, 所以編譯器可以更好的優(yōu)化嚴格模式的代碼.

首先, 嚴格模式禁用 with. with 所引起的問題是塊內(nèi)的任何名稱可以映射(map)到with傳進來的對象的屬性, 也可以映射到包圍這個塊的作用域內(nèi)的變量(甚至是全局變量), 這一切都是在運行時決定的: 在代碼運行之前是無法得知的. 嚴格模式下, 使用 with 會引起語法錯誤, 所以就不會存在 with 塊內(nèi)的變量在運行是才決定引用到哪里的情況了:

"use strict";
var x = 17;
with (obj) // !!! 語法錯誤
{
  // 如果沒有開啟嚴格模式，with中的這個x會指向with上面的那個x，還是obj.x？
  // 如果不運行代碼，我們無法知道，因此，這種代碼讓引擎無法進行優(yōu)化，速度也就會變慢。
  x;
}

一種取代 with 的簡單方法是，將目標對象賦給一個短命名變量，然后訪問這個變量上的相應(yīng)屬性.

第二, 嚴格模式下的 eval 不在為上層范圍(surrounding scope,注:包圍eval代碼塊的范圍)引入新變量. 在正常模式下, 代碼 eval("var x;") 會給上層函數(shù)(surrounding function)或者全局引入一個新的變量 x . 這意味著, 一般情況下, 在一個包含 eval 調(diào)用的函數(shù)內(nèi)所有沒有引用到參數(shù)或者局部變量的名稱都必須在運行時才能被映射到特定的定義 (因為 eval 可能引入的新變量會覆蓋它的外層變量). 在嚴格模式下 eval 僅僅為被運行的代碼創(chuàng)建變量, 所以 eval 不會影響到名稱映射到外部變量或者其他局部變量:

var x = 17;
var evalX = eval(""use strict"; var x = 42; x");
console.assert(x === 17);
console.assert(evalX === 42);

相應(yīng)的, 如果函數(shù) eval 被在被嚴格模式下的eval(...)以表達式的形式調(diào)用時, 其代碼會被當做嚴格模式下的代碼執(zhí)行. 當然也可以在代碼中顯式開啟嚴格模式, 但這樣做并不是必須的.

function strict1(str){
  "use strict";
  return eval(str); // str中的代碼在嚴格模式下運行
}
function strict2(f, str){
  "use strict";
  return f(str); // 沒有直接調(diào)用eval(...): 當且僅當str中的代碼開啟了嚴格模式時
                 // 才會在嚴格模式下運行
}
function nonstrict(str){
  return eval(str); // 當且僅當str中的代碼開啟了"use strict"，str中的代碼才會在嚴格模式下運行
}

strict1(""Strict mode code!"");
strict1(""use strict"; "Strict mode code!"");
strict2(eval, ""Non-strict code."");
strict2(eval, ""use strict"; "Strict mode code!"");
nonstrict(""Non-strict code."");
nonstrict(""use strict"; "Strict mode code!"");

因此在嚴格模式下eval執(zhí)行的內(nèi)容跟在非嚴格模式下eval執(zhí)行的內(nèi)容的結(jié)果是等同的。

第三, 嚴格模式禁止刪除聲明變量。delete name 在嚴格模式下會引起語法錯誤：

"use strict";

var x;
delete x; // !!! 語法錯誤

eval("var y; delete y;"); // !!! 語法錯誤

嚴格模式讓arguments和eval少了一些奇怪的行為。兩者在通常的代碼中都包含了很多奇怪的行為： eval會添加刪除綁定，改變綁定好的值，還會通過用它索引過的屬性給形參取別名的方式修改形參. 雖然在未來的ECMAScript版本解決這個問題之前，是不會有補丁來完全修復這個問題，但嚴格模式下將eval和arguments作為關(guān)鍵字對于此問題的解決是很有幫助的。

首先, 名稱 eval 和 arguments 不能通過程序語法被綁定(be bound)或賦值. 以下的所有嘗試將引起語法錯誤:

"use strict";
eval = 17;
arguments++;
++eval;
var obj = { set p(arguments) { } };
var eval;
try { } catch (arguments) { }
function x(eval) { }
function arguments() { }
var y = function eval() { };
var f = new Function("arguments", ""use strict"; return 17;");

第二，嚴格模式下，參數(shù)的值不會隨 arguments 對象的值的改變而變化。在正常模式下，對于第一個參數(shù)是 arg 的函數(shù)，對 arg 賦值時會同時賦值給 arguments[0]，反之亦然（除非沒有參數(shù)，或者 arguments[0] 被刪除）。嚴格模式下，函數(shù)的 arguments 對象會保存函數(shù)被調(diào)用時的原始參數(shù)。arguments[i] 的值不會隨與之相應(yīng)的參數(shù)的值的改變而變化，同名參數(shù)的值也不會隨與之相應(yīng)的 arguments[i] 的值的改變而變化。

function f(a){
  "use strict";
  a = 42;
  return [a, arguments[0]];
}
var pair = f(17);
console.assert(pair[0] === 42);
console.assert(pair[1] === 17);

第三，不再支持 arguments.callee。正常模式下，arguments.callee 指向當前正在執(zhí)行的函數(shù)。這個作用很?。褐苯咏o執(zhí)行函數(shù)命名就可以了！此外，arguments.callee 十分不利于優(yōu)化，例如內(nèi)聯(lián)函數(shù)，因為 arguments.callee 會依賴對非內(nèi)聯(lián)函數(shù)的引用。在嚴格模式下，arguments.callee 是一個不可刪除屬性，而且賦值和讀取時都會拋出異常：

"use strict";
var f = function() { return arguments.callee; };
f(); // 拋出類型錯誤

嚴格模式下更容易寫出“安全”的JavaScript。現(xiàn)在有些網(wǎng)站提供了方式給用戶編寫能夠被網(wǎng)站其他用戶執(zhí)行的JavaScript代碼。在瀏覽器環(huán)境下，JavaScript能夠獲取用戶的隱私信息，因此這類Javascript必須在運行前部分被轉(zhuǎn)換成需要申請訪問禁用功能的權(quán)限。沒有很多的執(zhí)行時檢查的情況，Javascript的靈活性讓它無法有效率地做這件事。一些語言中的函數(shù)普遍出現(xiàn)，以至于執(zhí)行時檢查他們會引起嚴重的性能損耗。做一些在嚴格模式下發(fā)生的小改動，要求用戶提交的JavaScript開啟嚴格模式并且用特定的方式調(diào)用，就會大大減少在執(zhí)行時進行檢查的必要。

第一，在嚴格模式下通過this傳遞給一個函數(shù)的值不會被強制轉(zhuǎn)換為一個對象。對一個普通的函數(shù)來說，this總會是一個對象：不管調(diào)用時this它本來就是一個對象；還是用布爾值，字符串或者數(shù)字調(diào)用函數(shù)時函數(shù)里面被封裝成對象的this；還是使用undefined或者null調(diào)用函數(shù)式this代表的全局對象（使用call, apply或者bind方法來指定一個確定的this）。這種自動轉(zhuǎn)化為對象的過程不僅是一種性能上的損耗，同時在瀏覽器中暴露出全局對象也會成為安全隱患，因為全局對象提供了訪問那些所謂安全的JavaScript環(huán)境必須限制的功能的途徑。所以對于一個開啟嚴格模式的函數(shù)，指定的this不再被封裝為對象，而且如果沒有指定this的話它值是undefined：

"use strict";
function fun() { return this; }
console.assert(fun() === undefined);
console.assert(fun.call(2) === 2);
console.assert(fun.apply(null) === null);
console.assert(fun.call(undefined) === undefined);
console.assert(fun.bind(true)() === true);

第二，在嚴格模式中再也不能通過廣泛實現(xiàn)的ECMAScript擴展“游走于”JavaScript的棧中。在普通模式下用這些擴展的話，當一個叫fun的函數(shù)正在被調(diào)用的時候，fun.caller是最后一個調(diào)用fun的函數(shù)，而且fun.arguments包含調(diào)用fun時用的形參。這兩個擴展接口對于“安全”JavaScript而言都是有問題的，因為他們允許“安全的”代碼訪問"專有"函數(shù)和他們的（通常是沒有經(jīng)過保護的）形參。如果fun在嚴格模式下，那么fun.caller和fun.arguments都是不可刪除的屬性而且在存值、取值時都會報錯：

function restricted()
{
  "use strict";
  restricted.caller;    // 拋出類型錯誤
  restricted.arguments; // 拋出類型錯誤
}
function privilegedInvoker()
{
  return restricted();
}
privilegedInvoker();

第三，嚴格模式下的arguments不會再提供訪問與調(diào)用這個函數(shù)相關(guān)的變量的途徑。在一些舊時的ECMAScript實現(xiàn)中arguments.caller曾經(jīng)是一個對象，里面存儲的屬性指向那個函數(shù)的變量。這是一個安全隱患，因為它通過函數(shù)抽象打破了本來被隱藏起來的保留值；它同時也是引起大量優(yōu)化工作的原因。出于這些原因，現(xiàn)在的瀏覽器沒有實現(xiàn)它。但是因為它這種歷史遺留的功能，arguments.caller在嚴格模式下同樣是一個不可被刪除的屬性，在賦值或者取值時會報錯：

"use strict";
function fun(a, b)
{
  "use strict";
  var v = 12;
  return arguments.caller; // 拋出類型錯誤
}
fun(1, 2); // 不會暴露v（或者a，或者b）

未來版本的ECMAScript很有可能會引入新語法，ECMAScript5中的嚴格模式就提早設(shè)置了一些限制來減輕之后版本改變產(chǎn)生的影響。如果提早使用了嚴格模式中的保護機制，那么做出改變就會變得更容易。

首先，在嚴格模式中一部分字符變成了保留的關(guān)鍵字。這些字符包括implements, interface, let, package, private, protected, public, static和yield。在嚴格模式下，你不能再用這些名字作為變量名或者形參名。

function package(protected){ // !!!
  "use strict";
  var implements; // !!!

  interface: // !!!
  while (true)
  {
    break interface; // !!!
  }

  function private() { } // !!!
}
function fun(static) { "use strict"; } // !!!

兩個針對Mozilla開發(fā)的警告：第一，如果你的JavaScript版本在1.7及以上（你的chrome代碼或者你正確使用了加載的代碼，let或者yield都不會作為關(guān)鍵字起作用；第二，盡管ES5無條件的保留了class, enum, export, extends, import和super關(guān)鍵字，在Firefox 5之前，Mozilla僅僅在嚴格模式中保留了它們。

其次，嚴格模式禁止了不在腳本或者函數(shù)層面上的函數(shù)聲明。在瀏覽器的普通代碼中，在“所有地方”的函數(shù)聲明都是合法的。這并不在ES5規(guī)范中（甚至是ES3）！這是一種針對不同瀏覽器中不同語義的一種延伸。未來的ECMAScript版本很有希望制定一個新的，針對不在腳本或者函數(shù)層面進行函數(shù)聲明的語法。在嚴格模式下禁止這樣的函數(shù)聲明對于將來ECMAScript版本的推出掃清了障礙：

"use strict";
if (true){
  function f() { } // !!! 語法錯誤
  f();
}

for (var i = 0; i < 5; i++){
  function f2() { } // !!! 語法錯誤
  f2();
}

function baz() { // 合法
  function eit() { } // 同樣合法
}

這種禁止放到嚴格模式中并不是很合適，因為這樣的函數(shù)聲明方式從ES5中延伸出來的。但這是ECMAScript委員會推薦的做法，瀏覽器就實現(xiàn)了這一點。

主流瀏覽器現(xiàn)在實現(xiàn)了嚴格模式。但是不要盲目的依賴它，因為市場上仍然有大量的瀏覽器版本只部分支持嚴格模式或者根本就不支持（比如IE10之前的版本）。嚴格模式改變了語義。依賴這些改變可能會導致沒有實現(xiàn)嚴格模式的瀏覽器中出現(xiàn)問題或者錯誤。謹慎地使用嚴格模式，通過檢測相關(guān)代碼的功能保證嚴格模式不出問題。最后，記得在支持或者不支持嚴格模式的瀏覽器中測試你的代碼。如果你只在不支持嚴格模式的瀏覽器中測試，那么在支持的瀏覽器中就很有可能出問題，反之亦然。