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

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

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

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

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

（1）為某個(gè)script標(biāo)簽開啟嚴(yán)格模式

為整個(gè)script標(biāo)簽開啟嚴(yán)格模式, 需要在所有語句之前放一個(gè)特定語句 "use strict"; （或 "use strict";）

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

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

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

（2）為某個(gè)函數(shù)開啟嚴(yán)格模式

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

function strict(){
  // 函數(shù)級別嚴(yán)格模式語法
  "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."; }

嚴(yán)格模式同時(shí)改變了語法及運(yùn)行時(shí)行為。

變化通常分為這幾類：

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

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

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

"use strict";
                       // 假如有一個(gè)全局變量叫做mistypedVariable
mistypedVaraible = 17; // 因?yàn)樽兞棵磳戝e(cuò)誤（省略了var變量聲明）
                       // 這一行代碼就會拋出 ReferenceError

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

"use strict";

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

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

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

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

"use strict";
delete Object.prototype; // 拋出TypeError錯(cuò)誤

第四，在Gecko版本34之前，嚴(yán)格模式要求一個(gè)對象內(nèi)的所有屬性名在對象內(nèi)必須唯一。正常模式下重名屬性是允許的，最后一個(gè)重名的屬性決定其屬性值。因?yàn)橹挥凶詈笠粋€(gè)屬性起作用，當(dāng)代碼是要改變屬性值而卻不是修改的最后一個(gè)重名屬性的時(shí)候，復(fù)制這個(gè)對象就產(chǎn)生一連串的bug。在嚴(yán)格模式下，重名屬性被認(rèn)為是語法錯(cuò)誤：

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

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

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

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

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

var a = 0o10; // ES6: 八進(jìn)制

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

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

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

(function() {
"use strict";

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

})();

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

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

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

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

第二, 嚴(yán)格模式下的 eval 不在為上層范圍(surrounding scope,注:包圍eval代碼塊的范圍)引入新變量. 在正常模式下, 代碼 eval("var x;") 會給上層函數(shù)(surrounding function)或者全局引入一個(gè)新的變量 x . 這意味著, 一般情況下, 在一個(gè)包含 eval 調(diào)用的函數(shù)內(nèi)所有沒有引用到參數(shù)或者局部變量的名稱都必須在運(yùn)行時(shí)才能被映射到特定的定義 (因?yàn)?eval 可能引入的新變量會覆蓋它的外層變量). 在嚴(yán)格模式下 eval 僅僅為被運(yùn)行的代碼創(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 被在被嚴(yán)格模式下的eval(...)以表達(dá)式的形式調(diào)用時(shí), 其代碼會被當(dāng)做嚴(yán)格模式下的代碼執(zhí)行. 當(dāng)然也可以在代碼中顯式開啟嚴(yán)格模式, 但這樣做并不是必須的.

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

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!"");

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

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

"use strict";

var x;
delete x; // !!! 語法錯(cuò)誤

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

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

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

"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;");

第二，嚴(yán)格模式下，參數(shù)的值不會隨 arguments 對象的值的改變而變化。在正常模式下，對于第一個(gè)參數(shù)是 arg 的函數(shù)，對 arg 賦值時(shí)會同時(shí)賦值給 arguments[0]，反之亦然（除非沒有參數(shù)，或者 arguments[0] 被刪除）。嚴(yán)格模式下，函數(shù)的 arguments 對象會保存函數(shù)被調(diào)用時(shí)的原始參數(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 指向當(dāng)前正在執(zhí)行的函數(shù)。這個(gè)作用很?。褐苯咏o執(zhí)行函數(shù)命名就可以了！此外，arguments.callee 十分不利于優(yōu)化，例如內(nèi)聯(lián)函數(shù)，因?yàn)?arguments.callee 會依賴對非內(nèi)聯(lián)函數(shù)的引用。在嚴(yán)格模式下，arguments.callee 是一個(gè)不可刪除屬性，而且賦值和讀取時(shí)都會拋出異常：

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

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

第一，在嚴(yán)格模式下通過this傳遞給一個(gè)函數(shù)的值不會被強(qiáng)制轉(zhuǎn)換為一個(gè)對象。對一個(gè)普通的函數(shù)來說，this總會是一個(gè)對象：不管調(diào)用時(shí)this它本來就是一個(gè)對象；還是用布爾值，字符串或者數(shù)字調(diào)用函數(shù)時(shí)函數(shù)里面被封裝成對象的this；還是使用undefined或者null調(diào)用函數(shù)式this代表的全局對象（使用call, apply或者bind方法來指定一個(gè)確定的this）。這種自動轉(zhuǎn)化為對象的過程不僅是一種性能上的損耗，同時(shí)在瀏覽器中暴露出全局對象也會成為安全隱患，因?yàn)槿謱ο筇峁┝嗽L問那些所謂安全的JavaScript環(huán)境必須限制的功能的途徑。所以對于一個(gè)開啟嚴(yá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);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

主流瀏覽器現(xiàn)在實(shí)現(xiàn)了嚴(yán)格模式。但是不要盲目的依賴它，因?yàn)槭袌錾先匀挥写罅康臑g覽器版本只部分支持嚴(yán)格模式或者根本就不支持（比如IE10之前的版本）。嚴(yán)格模式改變了語義。依賴這些改變可能會導(dǎo)致沒有實(shí)現(xiàn)嚴(yán)格模式的瀏覽器中出現(xiàn)問題或者錯(cuò)誤。謹(jǐn)慎地使用嚴(yán)格模式，通過檢測相關(guān)代碼的功能保證嚴(yán)格模式不出問題。最后，記得在支持或者不支持嚴(yán)格模式的瀏覽器中測試你的代碼。如果你只在不支持嚴(yán)格模式的瀏覽器中測試，那么在支持的瀏覽器中就很有可能出問題，反之亦然。