有時你可以在舊的程式碼中發現將undefined傳遞給函式的情況。為什麼呢？

我是在觀看著名的Paul Irish關於jQuery源碼的視頻時發現這個小技巧的。

那個視頻來自不同的時代，在撰寫本文時已經9年了，而且jQuery源碼也有所改變，所以你無法在其中看到這個東西，但我還是覺得這是一個有趣的發現。

此外，JavaScript也有所改變。這種技巧只適用於ES5之前的JavaScript。

在2009年發布的ES5之前，這幾乎是必須的一步。

注意：ES5及更新的代碼庫不再需要添加這個，因為現在undefined是一個只讀值。

有時在我們的代碼中，我們確認變量是否為undefined的方式如下：

if (car !== undefined) {

}

如果這是我們的代碼，運行在我們自己控制的服務器上，這應該沒問題。但是想象一下，一個像jQuery這樣的庫需要經受考驗，能夠在每個可能的網站上工作。

如果有人用一個簡單的方式覆蓋了undefined

undefined = '🤔' // 你喜歡的任何值

那麼上面的if語句會失敗，將car與🤔進行比較。

這在ES5之後已經修復了，但在此之前是可能的。

如果car實際上是undefined，則現在無法找到這個結果。

除非使用這種技巧：我們將所有的代碼包裹在IIFE（立即呼叫的函式表達式）中，並在函式定義中傳遞一個參數，在呼叫階段不將它添加進去。

(function() {
   /*我們的函式代碼*/
})()

(function(undefined) {
   /*我們的函式代碼*/
})()

可以看到，undefined被當作參數傳遞，但在我們調用函式時不作為參數傳遞。因此，在函式內部，變量undefined的值(保證)是undefined的原始值。無論頁面上的其他腳本對其做了什麼，它都是隔離的。

現在，我最喜歡解決這個問題的方法是使用這種技巧來檢查是否存在undefined的值：

if (typeof car !== 'undefined') {

}

typeof運算符返回一個包含變量類型的字符串。我們可以將其與字符串'undefined'進行比較，這樣就不會有上面的問題了。

但是，了解某些你所讀取的其他人編寫的代碼的原因總是很好的，尤其是當它是需要在各個地方運行的庫級代碼時。