[總結貼] 十個 JavaScript 中易犯的小錯誤

時間 2019-12-04

原文原文鏈接

序言

在今天，JavaScript已經成爲了網頁編輯的核心。尤爲是過去的幾年，互聯網見證了在SPA開發、圖形處理、交互等方面大量JS庫的出現。javascript

若是初次打交道，不少人會以爲js很簡單。確實，對於不少有經驗的工程師，或者甚至是初學者而言，實現基本的js功能幾乎毫無障礙。可是JS的真實功能卻比不少人想象的要更加多樣、複雜。JavaScript的許多細節規定會讓你的網頁出現不少意想不到的bug，搞懂這些bug，對於成爲一位有經驗的JS開發者很重要。java

常見錯誤一：對於this關鍵詞的不正確引用

我曾經聽一位喜劇演員說過：程序員

「我從未在這裏，由於我不清楚這裏是哪裏，是除了那裏以外的地方嗎？」編程

這句話或多或少地暗喻了在js開發中開發者對於this關鍵字的使用誤區。This指代的是什麼？它和平常英語口語中的this是一個意思嗎？安全

隨着近些年js編程不斷地複雜化，功能多樣化，對於一個程序結構的內部指引、引用也逐漸變多起來閉包

下面讓咱們一塊兒來看這一段代碼：app

Game.prototype.restart = function () {   this.clearLocalStorage(); 

    this.timer = setTimeout(function(){     this.clearBoard();        }, 0);

 };

運行上面的代碼將會出現以下錯誤：編程語言

Uncaught TypeError: undefined is not a function

這是爲何？this的調用和它所在的環境密切相關。之因此會出現上面的錯誤，是由於當你在調用 setTimeout()函數的時候, 你實際調用的是window.setTimeout(). 所以，在 setTimeout() 定義的函數實際上是在window背景下定義的，而window中並無 clearBoard() 這個函數方法。函數

下面提供兩種解決方案。第一種比較簡單直接的方法即是，把this存儲到一個變量當中，這樣他就能夠在不一樣的環境背景中被繼承下來：this

Game.prototype.restart = function () {   this.clearLocalStorage();  

 var self = this;

this.timer = setTimeout(function(){     self.clearBoard();}, 0); };

第二種方法即是用bind()的方法，不過這個相比上一種要複雜一些，對於不熟悉bind()的同窗能夠在微軟官方查看它的使用方法：https://msdn.microsoft.com/zh-cn/library/ff841995

Game.prototype.restart = function () {   this.clearLocalStorage(); 

this.timer = setTimeout(this.reset.bind(this), 0); };      

Game.prototype.reset = function(){     this.clearBoard();};

上面的例子中，兩個this均指代的是Game.prototype。

常見錯誤二：傳統編程語言的生命週期誤區

另外一種易犯的錯誤，即是帶着其餘編程語言的思惟，認爲在JS中，也存在生命週期這麼一說。請看下面的代碼：

for (var i = 0; i < 10; i++) {   /* ... */ } console.log(i);

若是你認爲在運行console.log() 時確定會報出 undefined 錯誤，那麼你就大錯特錯了。我會告訴你其實它會返回 10嗎。

固然，在許多其餘語言當中，遇到這樣的代碼，確定會報錯。由於i明顯已經超越了它的生命週期。在for中定義的變量在循環結束後，它的生命也就結束了。可是在js中，i的生命還會繼續。這種現象叫作 variable hoisting。

而若是咱們想要實現和其餘語言同樣的在特定邏輯模塊中具備生命週期的變量，能夠用let關鍵字。

常見錯誤三：內存泄露

內存泄露在js變成中幾乎是一個沒法避免的問題。若是不是特別細心的話，在最後的檢查過程當中，確定會出現各類內存泄露問題。下面咱們就來舉例說明一下：

var theThing = null; 

var replaceThing = function () { 



    var priorThing = theThing; 

    var unused = function () { 

              if (priorThing) {       console.log("hi");     }   

   }; 

   theThing = {     longStr: new Array(1000000).join('*'),  // 

              someMethod: function () {       console.log(someMessage);     }   
   }; 
};   
setInterval(replaceThing, 1000);

若是運行上面的代碼，你會發現你已經形成了大量的內存泄露，每秒泄露1M的內存，顯然光靠GC（垃圾回收器）是沒法幫助你的了。由上面的代碼來看，彷佛是longstr在每次replaceThing調用的時候都沒有獲得回收。這是爲何呢？

每個theThing結構都含有一個longstr結構列表。每一秒當咱們調用 replaceThing, 它就會把當前的指向傳遞給 priorThing. 可是到這裏咱們也會看到並無什麼問題，由於 priorThing 每回也是先解開上次函數的指向纔會接受新的賦值。而且全部的這一切都是發生在 replaceThing 函數體當中，按常理來講當函數體結束以後，函數中的本地變量也將會被GC回收，也就不會出現內存泄露的問題了，可是爲何會出現上面的錯誤呢？

這是由於longstr的定義是在一個閉包中進行的，而它又被其餘的閉包所引用，js規定，在閉包中引入閉包外部的變量時，當閉包結束時此對象沒法被垃圾回收（GC）。關於在JS中的內存泄露問題能夠查看http://javascript.info/tutorial/memory-leaks#memory-management-in-java...

常見錯誤四:比較運算符

JavaScript中一個比較便捷的地方，即是它能夠給每個在比較運算的結果變量強行轉化成布爾類型。可是從另外一方面來考慮，有時候它也會爲咱們帶來不少不便，下面的這些例子即是一些一直困擾不少程序員的代碼實例：

console.log(false == '0'); 

console.log(null == undefined); 

console.log(" \t\r\n" == 0); 

console.log('' == 0);  // And these do too! 

if ({}) // ... 

if ([]) // ...

最後兩行的代碼雖然條件判斷爲空（常常會被人誤認爲轉化爲false），可是其實不論是{ }仍是[ ]都是一個實體類，而任何的類其實都會轉化爲true。就像這些例子所展現的那樣，其實有些類型強制轉化很是模糊。所以不少時候咱們更願意用 === 和 !== 來替代== 和 !=，以此來避免發生強制類型轉化。. ===和!== 的用法和以前的== 和 != 同樣，只不過他們不會發生類型強制轉換。另外須要注意的一點是，當任何值與 NaN 比較的時候，甚至包括他本身，結果都是false。所以咱們不能用簡單的比較字符來決定一個值是否爲 NaN 。咱們能夠用內置的 isNaN() 函數來辨別:

console.log(NaN == NaN);    // false 

console.log(NaN === NaN);   // false 

console.log(isNaN(NaN));    // true

常見錯誤五：低效的DOM操做

js中的DOM基本操做很是簡單，可是如何能有效地進行這些操做一直是一個難題。這其中最典型的問題即是批量增長DOM元素。增長一個DOM元素是一步花費很大的操做。而批量增長對系統的花銷更是不菲。一個比較好的批量增長的辦法即是使用 document fragments ：

var div = document.getElementsByTagName("my_div");  

var fragment = document.createDocumentFragment(); 

 for (var e = 0; e < elems.length; e++) { fragment.appendChild(elems[e]); } div.appendChild(fragment.cloneNode(true));

直接添加DOM元素是一個很是昂貴的操做。可是若是是先把要添加的元素所有建立出來，再把它們所有添加上去就會高效不少。

常見錯誤六：在for循環中的不正確函數調用

請你們看如下代碼：

var elements = document.getElementsByTagName('input');

var n = elements.length; 

for (var i = 0; i < n; i++) {     

elements[i].onclick = function() {         

console.log("This is element #" + i);     }; }

運行以上代碼，若是頁面上有10個按鈕的話，點擊每個按鈕都會彈出「This is element #10」! 。這和咱們原先預期的並不同。這是由於當點擊事件被觸發的時候，for循環早已執行完畢，i的值也已經從0變成了。

咱們能夠經過下面這段代碼來實現真正正確的效果：

var elements = document.getElementsByTagName('input'); 

var n = elements.length; 

var makeHandler = function(num) {  // outer function

      return function() { 

console.log("This is element #" + num);      }; }; 

for (var i = 0; i < n; i++) 

{     elements[i].onclick = makeHandler(i+1); }

在這個版本的代碼中， makeHandler 在每回循環的時候都會被當即執行，把i＋1傳遞給變量num。外面的函數返回裏面的函數，而點擊事件函數便被設置爲裏面的函數。這樣每一個觸發函數就都可以是用正確的i值了。

常見錯誤七：原型繼承問題

很大一部分的js開發者都不能徹底掌握原型的繼承問題。下面具一個例子來講明：

BaseObject = function(name) {     

if(typeof name !== "undefined") 

{         this.name = name;     } 

else 

{         this.name = 'default'     } };

這段代碼看起來很簡單。若是你有name值，則使用它。若是沒有，則使用 ‘default’:

var firstObj = new BaseObject(); 

var secondObj = new BaseObject('unique');  

console.log(firstObj.name);  // -> 結果是'default' 

console.log(secondObj.name); // -> 結果是 'unique'

可是若是咱們執行delete語句呢:

delete secondObj.name;

咱們會獲得:

console.log(secondObj.name); // -> 結果是 'undefined'

可是若是可以從新回到 ‘default’狀態不是更好麼? 其實要想達到這樣的效果很簡單，若是咱們可以使用原型繼承的話:

BaseObject = function (name) 

{     if(typeof name !== "undefined") 

{         this.name = name;     } };  

BaseObject.prototype.name = 'default';

在這個版本中, BaseObject 繼承了原型中的name 屬性, 被設置爲了 'default'.。這時，若是構造函數被調用時沒有參數，則會自動設置爲 default。相同地，若是name 屬性被從BaseObject移出，系統將會自動尋找原型鏈，而且得到 'default'值：

var thirdObj = new BaseObject('unique'); 

 console.log(thirdObj.name);  

 delete thirdObj.name;

 console.log(thirdObj.name);  // -> 結果是 'default'

常見錯誤八：爲實例方法建立錯誤的指引

咱們來看下面一段代碼:

var MyObject = function() {} 

 MyObject.prototype.whoAmI = function() {     

console.log(this === window ? "window" : "MyObj"); }; 

 var obj = new MyObject();

如今爲了方便起見，咱們新建一個變量來指引 whoAmI 方法, 所以咱們能夠直接用 whoAmI() 而不是更長的obj.whoAmI():

var whoAmI = obj.whoAmI;

接下來爲了確保一切都如咱們所預測的進行，咱們能夠將 whoAmI 打印出來:

console.log(whoAmI);

結果是：

function () {     console.log(this === window ? "window" : "MyObj"); }

沒有錯誤！

可是如今咱們來查看一下兩種引用的方法：

obj.whoAmI();  // 輸出 "MyObj" (as expected) 

whoAmI();      // 輸出 "window" (uh-oh!)

哪裏出錯了呢？

原理其實和上面的第二個常見錯誤同樣，當咱們執行 var whoAmI = obj.whoAmI;的時候，新的變量 whoAmI 是在全局環境下定義的。所以它的this 是指window, 而不是obj！

正確的編碼方式應該是：

var MyObject = function() {}  

MyObject.prototype.whoAmI = function() {     

      console.log(this === window ? "window" : "MyObj"); }; 

var obj = new MyObject(); 

obj.w = obj.whoAmI;   // still in the obj namespace  obj.whoAmI();  // 輸出 "MyObj" (as expected) 

obj.w();       // 輸出 "MyObj" (as expected)

常見錯誤九：用字符串做爲setTimeout 或者 setInterval的第一個參數

首先咱們要聲明，用字符串做爲這兩個函數的第一個參數並無什麼語法上的錯誤。可是其實這是一個很是低效的作法。由於從系統的角度來講，當你用字符串的時候，它會被傳進構造函數，而且從新調用另外一個函數。這樣會拖慢程序的進度。

setInterval("logTime()", 1000); 

setTimeout("logMessage('" + msgValue + "')", 1000);

另外一種方法是直接將函數做爲參數傳遞進去：

setInterval(logTime, 1000);   

setTimeout(function() { 

logMessage(msgValue); }, 1000);

常見錯誤十：忽略「strict mode」的做用

「strict mode」是一種更加嚴格的代碼檢查機制，而且會讓你的代碼更加安全。固然，不選擇這個模式並不意味着是一個錯誤，可是使用這個模式能夠確保你的代碼更加準確無誤。

下面咱們總結幾條「strict mode」的優點：

讓Debug更加容易：在正常模式下不少錯誤都會被忽視掉，「strict mode」模式會讓Debug極致更加嚴謹。
防止默認的全局變量：在正常模式下，給一個爲通過聲明的變量命名將會將這個變量自動設置爲全局變量。在strict模式下，咱們取消了這個默認機制。
取消this的默認轉換：在正常模式下，給this關鍵字指引到null或者undefined會讓它自動轉換爲全局。在strict模式下，咱們取消了這個默認機制。
防止重複的變量聲明和參數聲明：在strict模式下進行重複的變量聲明會被抱錯，如 (e.g., var object = {foo: "bar", foo: "baz"};) 同時，在函數聲明中重複使用同一個參數名稱也會報錯，如 (e.g., function foo(val1, val2, val1){}),
讓eval()函數更加安全。
當遇到無效的delete指令的過後報錯：delete指令不能對類中未有的屬性執行，在正常狀況下這種狀況只是默默地忽視掉，而在strict模式是會報錯的。