JavaScript 里有個(gè)東西平時(shí)寫業(yè)務(wù)代碼可能一周都碰不到一次但一旦你翻開任何一本稍微有點(diǎn)年頭的技術(shù)書、或者去讀某個(gè)開源庫的源碼它幾乎無處不在。沒錯(cuò)就是那個(gè)看起來像“函數(shù)被一對(duì)括號(hào)包起來后面又跟了一對(duì)括號(hào)”的寫法——立即調(diào)用函數(shù)表達(dá)式英文縮寫 IIFEImmediately Invoked Function Expression。很多人第一次看到(function(){ ... })()這種寫法時(shí)腦子里冒出的第一個(gè)問題往往是這到底在干嘛為什么不能直接寫個(gè)函數(shù)然后調(diào)用它多包一層括號(hào)是圖什么而恰恰是這些疑問決定了你對(duì)它的理解深度也直接決定了你在實(shí)際項(xiàng)目里到底會(huì)不會(huì)用它、用得多不多。這篇文章就圍繞 IIFE 這個(gè)主題從它誕生的歷史背景、語法本質(zhì)、核心作用、實(shí)戰(zhàn)場景一路聊到常見誤區(qū)和排查技巧盡量把我知道的、踩過的坑都攤開來講清楚不管你是剛學(xué) JavaScript 不久的新手還是寫了幾年代碼但一直對(duì) IIFE 一知半解的老手應(yīng)該都能從中撈到點(diǎn)有用的東西。1. 為什么會(huì)有 IIFE 這個(gè)東西1.1 從“函數(shù)定義”和“函數(shù)表達(dá)式”的區(qū)別說起要理解 IIFE得先把一個(gè)更基礎(chǔ)的問題搞清楚JavaScript 里函數(shù)定義Function Declaration和函數(shù)表達(dá)式Function Expression到底有什么區(qū)別。很多人寫了好幾年 JS對(duì)這兩個(gè)概念依然是模糊的而這恰恰是理解 IIFE 的第一道門檻。函數(shù)定義長這樣function foo() { console.log(hello); }它的特點(diǎn)是以function關(guān)鍵字開頭后面緊跟函數(shù)名它是一個(gè)語句statement。而函數(shù)表達(dá)式長這樣var foo function() { console.log(hello); };這里function(){}是作為賦值表達(dá)式的一部分出現(xiàn)的它是一個(gè)表達(dá)式expression可以匿名也可以具名。這個(gè)區(qū)別看起來只是學(xué)術(shù)上的文字游戲但它帶來一個(gè)非常實(shí)際的后果函數(shù)定義會(huì)被提升hoisting而函數(shù)表達(dá)式不會(huì)。也就是說你可以在函數(shù)定義之前就調(diào)用它但函數(shù)表達(dá)式必須先賦值后調(diào)用。那這跟 IIFE 有什么關(guān)系關(guān)系大了。因?yàn)?IIFE 的本質(zhì)就是把一個(gè)函數(shù)表達(dá)式立刻執(zhí)行掉。注意關(guān)鍵詞是“函數(shù)表達(dá)式”不是“函數(shù)定義”。如果你寫function() { console.log(hello); }();這段代碼會(huì)直接報(bào)語法錯(cuò)誤。為什么因?yàn)?JavaScript 引擎在解析的時(shí)候看到行首是function關(guān)鍵字會(huì)默認(rèn)把它當(dāng)成函數(shù)定義來處理而函數(shù)定義是必須有名字的你這里沒名字引擎就懵了直接拋SyntaxError。所以問題的核心就變成了怎么讓引擎知道“我這里寫的是一個(gè)函數(shù)表達(dá)式不是函數(shù)定義”答案就是加一對(duì)圓括號(hào)把整個(gè)函數(shù)包起來(function() { console.log(hello); })();圓括號(hào)在 JavaScript 里是一個(gè)分組運(yùn)算符它會(huì)把里面的內(nèi)容當(dāng)成表達(dá)式來求值。一旦被當(dāng)成表達(dá)式function(){}就變成了一個(gè)函數(shù)表達(dá)式的值也就是一個(gè)函數(shù)對(duì)象然后后面緊跟的()就順理成章地把它調(diào)用執(zhí)行了。這就是 IIFE 最原始的形態(tài)。1.2 括號(hào)的位置為什么有兩種寫法都能跑你可能見過兩種 IIFE 的寫法// 寫法一調(diào)用括號(hào)在外面 (function() { console.log(a); })(); // 寫法二調(diào)用括號(hào)在里面 (function() { console.log(b); }());這兩種寫法在功能上完全等價(jià)都能正常執(zhí)行。區(qū)別只在于括號(hào)的歸屬感不同。寫法一是“先把函數(shù)表達(dá)式包起來然后調(diào)用它”寫法二是“把函數(shù)表達(dá)式和調(diào)用括號(hào)一起包起來”。從引擎解析的角度兩者最終都是先得到一個(gè)函數(shù)表達(dá)式的值再執(zhí)行調(diào)用。那到底用哪種這純粹是風(fēng)格問題。我個(gè)人的習(xí)慣是用寫法一因?yàn)橐曈X上更清晰先看到一整個(gè)被包裹的函數(shù)然后看到調(diào)用。不過在一些老代碼庫里寫法二也很常見尤其是某些風(fēng)格指南推薦寫法二理由是“整個(gè)調(diào)用過程都在括號(hào)內(nèi)語義更完整”。這個(gè)沒有對(duì)錯(cuò)團(tuán)隊(duì)統(tǒng)一就行。除了圓括號(hào)其實(shí)還有幾種方式也能讓引擎把函數(shù)當(dāng)成表達(dá)式// 用一元運(yùn)算符 !function() { console.log(a); }(); function() { console.log(b); }(); -function() { console.log(c); }(); ~function() { console.log(d); }(); // 用 void void function() { console.log(e); }(); // 用賦值 var x function() { console.log(f); }();這些寫法都能跑但可讀性一個(gè)比一個(gè)差。!function(){}()這種寫法在一些壓縮工具的輸出里偶爾能看到因?yàn)?比一對(duì)括號(hào)少一個(gè)字符壓縮后體積更小。但手寫代碼里我強(qiáng)烈建議老老實(shí)實(shí)用圓括號(hào)別為了省那幾個(gè)字符讓同事讀代碼時(shí)多花三秒鐘愣神。1.3 IIFE 誕生的歷史土壤模塊化的原始需求理解了語法層面還得理解 IIFE 為什么會(huì)在那個(gè)年代火起來。這就要說到 JavaScript 早期的“黑暗時(shí)代”。在 ES6 模塊化標(biāo)準(zhǔn)出現(xiàn)之前JavaScript 壓根沒有官方的模塊系統(tǒng)。你寫一個(gè)稍微大點(diǎn)的項(xiàng)目所有變量都掛在全局作用域上不同文件之間的變量互相污染命名沖突簡直是家常便飯。你定義了一個(gè)var count 0結(jié)果引入的某個(gè)第三方腳本里也有一個(gè)var count兩個(gè)一撞bug 就來了而且這種 bug 極難排查因?yàn)樽兞勘徽l改的完全看不出來。IIFE 就是在這個(gè)背景下被當(dāng)成“窮人版模塊系統(tǒng)”來用的。它的思路很樸素用一個(gè)函數(shù)把代碼包起來函數(shù)內(nèi)部的所有變量就都變成了局部變量不會(huì)污染全局。然后通過返回值或者參數(shù)把需要暴露給外界的東西“送出去”。var myModule (function() { var privateCount 0; // 外部訪問不到 function increment() { privateCount; } function getCount() { return privateCount; } return { increment: increment, getCount: getCount }; })(); myModule.increment(); console.log(myModule.getCount()); // 1 console.log(myModule.privateCount); // undefined這段代碼就是經(jīng)典的“模塊模式”Module Pattern它靠的就是 IIFE。privateCount被關(guān)在函數(shù)作用域里外界只能通過返回的對(duì)象上的方法來間接操作它實(shí)現(xiàn)了真正意義上的私有變量。在 ES6 的class和import/export普及之前這是無數(shù)前端庫組織代碼的標(biāo)準(zhǔn)姿勢。所以你看IIFE 不是一個(gè)“為了炫技而存在”的語法糖它是特定歷史階段解決特定問題的產(chǎn)物。理解了這一點(diǎn)你才能理解為什么它在老代碼里出鏡率那么高也才能判斷在新項(xiàng)目里到底還需不需要它。2. IIFE 的核心作用與原理拆解2.1 作用域隔離IIFE 最本質(zhì)的價(jià)值如果只能用一個(gè)詞概括 IIFE 的價(jià)值那就是“作用域隔離”。JavaScript 在 ES6 之前只有兩種作用域全局作用域和函數(shù)作用域。沒有塊級(jí)作用域let/const帶來的塊級(jí)作用域是 ES6 才有的。這意味著你在if塊或者for循環(huán)里用var聲明的變量其實(shí)是屬于外層函數(shù)的。這個(gè)特性帶來一個(gè)經(jīng)典問題循環(huán)里綁定事件所有回調(diào)拿到的都是同一個(gè)變量值。for (var i 0; i 3; i) { setTimeout(function() { console.log(i); // 輸出 3 3 3不是 0 1 2 }, 100); }為什么會(huì)輸出三個(gè) 3因?yàn)関ar i是函數(shù)作用域這里就是全局三個(gè)setTimeout的回調(diào)共享同一個(gè)i等回調(diào)執(zhí)行的時(shí)候循環(huán)早就跑完了i已經(jīng)變成 3。在 ES6 之前解決這個(gè)問題的標(biāo)準(zhǔn)方案就是用 IIFE 給每次循環(huán)創(chuàng)建一個(gè)獨(dú)立的作用域for (var i 0; i 3; i) { (function(j) { setTimeout(function() { console.log(j); // 輸出 0 1 2 }, 100); })(i); }這里 IIFE 接收i的當(dāng)前值作為參數(shù)j每次循環(huán)都創(chuàng)建一個(gè)新的函數(shù)作用域j就被“鎖”在了那個(gè)作用域里不受后續(xù)循環(huán)影響。這是 IIFE 最經(jīng)典的應(yīng)用場景之一也是很多面試題喜歡考的點(diǎn)?，F(xiàn)在有了let這個(gè)問題一行就解決了for (let i 0; i 3; i) { setTimeout(function() { console.log(i); // 輸出 0 1 2 }, 100); }let在每次循環(huán)迭代時(shí)都會(huì)創(chuàng)建一個(gè)新的綁定效果和 IIFE 一樣但寫法簡潔得多。所以在新代碼里這種“循環(huán) IIFE”的寫法基本可以退休了。但你必須理解它因?yàn)榇罅看媪看a里還在用而且面試官依然愛問。2.2 避免全局污染從“變量滿天飛”到“各掃門前雪”作用域隔離的另一個(gè)直接收益就是避免全局污染。在多人協(xié)作的項(xiàng)目里全局變量是最容易引發(fā)沖突的東西。你定義一個(gè)var utils同事也定義一個(gè)var utils后加載的覆蓋先加載的然后某個(gè)功能就莫名其妙掛了。IIFE 可以把一整塊邏輯封在一個(gè)獨(dú)立作用域里只暴露必要的接口(function(global) { var version 1.0.0; function log(msg) { console.log([ version ] msg); } global.myLogger { log: log }; })(window);這段代碼把version和log都藏在函數(shù)內(nèi)部只把myLogger掛到window上。外部只能通過window.myLogger.log()來用version完全不可見。這就是“最小暴露原則”的體現(xiàn)。這里有個(gè)細(xì)節(jié)值得說為什么要把window作為參數(shù)傳進(jìn)去而不是直接在函數(shù)里用window有兩個(gè)原因。第一函數(shù)內(nèi)部對(duì)window的訪問變成了局部變量訪問比全局查找稍微快一點(diǎn)點(diǎn)雖然現(xiàn)代引擎優(yōu)化后差距微乎其微。第二也是更重要的這樣做讓依賴關(guān)系變得顯式——你一眼就能看出這個(gè)模塊依賴全局對(duì)象而且如果將來要在一個(gè)非瀏覽器環(huán)境比如某些服務(wù)端環(huán)境里跑只需要傳入不同的全局對(duì)象即可代碼本身不用改。這種“依賴注入”的思路在 jQuery 插件、各種 UMD 包裝里非常常見。2.3 閉包與私有變量IIFE 和閉包的化學(xué)反應(yīng)IIFE 和閉包經(jīng)常被放在一起講因?yàn)樗鼈兇_實(shí)經(jīng)常配合使用。IIFE 執(zhí)行完它的作用域理論上應(yīng)該被銷毀但如果內(nèi)部有函數(shù)引用了這個(gè)作用域里的變量并且這個(gè)內(nèi)部函數(shù)被“送”到了外部那么這些變量就不會(huì)被回收而是被閉包“記住”了。var counter (function() { var count 0; return { increment: function() { count; }, decrement: function() { count--; }, getCount: function() { return count; } }; })(); counter.increment(); counter.increment(); console.log(counter.getCount()); // 2count這個(gè)變量在 IIFE 執(zhí)行完之后從外部看是“消失”了但它并沒有被垃圾回收因?yàn)閕ncrement、decrement、getCount這三個(gè)函數(shù)都引用了它。這三個(gè)函數(shù)被返回出去形成了一個(gè)閉包把count保護(hù)了起來。外界無法直接修改count只能通過暴露的方法來操作這就是“私有變量”的實(shí)現(xiàn)原理。這個(gè)模式在 ES6 之前被廣泛用于實(shí)現(xiàn)“類”和“實(shí)例”的概念。比如你要寫一個(gè)計(jì)數(shù)器類就可以用 IIFE 來封裝私有狀態(tài)。現(xiàn)在有了class語法和#private字段這種寫法用得少了但理解它對(duì)讀懂老代碼依然至關(guān)重要。注意閉包會(huì)阻止變量被回收如果 IIFE 里引用了很大的對(duì)象并且返回的函數(shù)長期存活就可能造成內(nèi)存占用偏高。在寫長期駐留的模塊時(shí)要留意這一點(diǎn)。2.4 一次性初始化用完即走的執(zhí)行環(huán)境IIFE 的另一個(gè)常見用途是“一次性初始化”。有些代碼你只想讓它執(zhí)行一次執(zhí)行完就完事不需要保留任何引用。這時(shí)候 IIFE 就是最自然的選擇。(function() { // 初始化配置 var config { apiBase: /api, timeout: 5000 }; // 檢測環(huán)境 if (typeof window ! undefined) { window.__APP_CONFIG__ config; } // 綁定一些全局事件 document.addEventListener(DOMContentLoaded, function() { console.log(DOM ready); }); })();這段代碼執(zhí)行完config就完成了它的使命被掛到了全局對(duì)象上供其他模塊使用而 IIFE 本身不留下任何痕跡。這種“自執(zhí)行、自銷毀”的特性讓它非常適合做啟動(dòng)腳本、環(huán)境檢測、polyfill 注入這類工作。很多 polyfill 庫比如給老瀏覽器補(bǔ)上新 API 的腳本就是用 IIFE 寫的。它們檢測某個(gè) API 是否存在不存在就補(bǔ)上然后整個(gè)邏輯封在 IIFE 里不污染全局。3. 實(shí)戰(zhàn)場景IIFE 到底在哪些地方出鏡3.1 老項(xiàng)目的模塊封裝讀懂那些“括號(hào)套括號(hào)”的代碼如果你接手過一個(gè) 2015 年之前的前端項(xiàng)目大概率會(huì)看到這樣的代碼結(jié)構(gòu)var App (function() { var modules {}; function define(name, factory) { modules[name] factory(); } function require(name) { return modules[name]; } return { define: define, require: require }; })(); App.define(utils, function() { return { trim: function(str) { return str.replace(/^\s|\s$/g, ); } }; });這是一個(gè)極簡的模塊加載器整個(gè)框架的核心就靠 IIFE 封裝。modules這個(gè)對(duì)象是私有的外部只能通過App.define和App.require來操作。這種模式在 RequireJS、SeaJS 那個(gè)年代非常流行是前端模塊化的早期探索。讀這類代碼的關(guān)鍵是找到 IIFE 的“入口”和“出口”入口是它接收的參數(shù)通常是全局對(duì)象或依賴出口是它返回的值通常是暴露的 API。把這兩頭抓住中間的邏輯就是普通的函數(shù)邏輯不難理解。3.2 庫和框架源碼里的 IIFEUMD 包裝的秘密如果你打開 jQuery、Lodash 這類庫的源碼尤其是 dist 目錄下的構(gòu)建產(chǎn)物會(huì)看到文件開頭和結(jié)尾是這樣的(function(global, factory) { if (typeof module object typeof module.exports object) { // CommonJS 環(huán)境 module.exports factory(global); } else if (typeof define function define.amd) { // AMD 環(huán)境 define(myLib, [exports], factory); } else { // 瀏覽器全局環(huán)境 global.myLib factory(global); } })(typeof window ! undefined ? window : this, function(global) { // 庫的實(shí)際代碼 var myLib {}; // ... return myLib; });這就是大名鼎鼎的 UMDUniversal Module Definition模式。它的核心思路是用一個(gè) IIFE 包住整個(gè)庫在 IIFE 內(nèi)部檢測當(dāng)前運(yùn)行環(huán)境支持哪種模塊規(guī)范然后分別處理。這樣一份代碼就能同時(shí)跑在 CommonJS、AMD 和瀏覽器全局三種環(huán)境下。這個(gè)模式里IIFE 接收兩個(gè)參數(shù)一個(gè)是全局對(duì)象瀏覽器里是window其他環(huán)境里可能是this或其他另一個(gè)是工廠函數(shù)factory。工廠函數(shù)里才是庫的真正實(shí)現(xiàn)最后返回庫的 API。這種“環(huán)境檢測 工廠函數(shù)”的組合是 IIFE 在工程化領(lǐng)域最經(jīng)典的應(yīng)用之一。理解了這個(gè)模式你再看任何庫的源碼都能快速定位到“真正的實(shí)現(xiàn)”在哪里——就在那個(gè) factory 函數(shù)里。3.3 事件綁定與循環(huán)陷阱那個(gè)繞不開的經(jīng)典問題前面提到過循環(huán)綁定事件的問題這里再展開說一下因?yàn)檫@是 IIFE 在面試和實(shí)際開發(fā)中出現(xiàn)頻率最高的場景之一。假設(shè)你要給三個(gè)按鈕綁定點(diǎn)擊事件點(diǎn)擊時(shí)彈出對(duì)應(yīng)的索引button按鈕1/button button按鈕2/button button按鈕3/button用var直接寫var buttons document.querySelectorAll(button); for (var i 0; i buttons.length; i) { buttons[i].addEventListener(click, function() { alert(你點(diǎn)擊了第 (i 1) 個(gè)按鈕); }); }不管你點(diǎn)哪個(gè)按鈕彈出來的都是“你點(diǎn)擊了第 4 個(gè)按鈕”因?yàn)檠h(huán)結(jié)束后i是 3加 1 就是 4。原因前面說過所有回調(diào)共享同一個(gè)i。用 IIFE 修復(fù)var buttons document.querySelectorAll(button); for (var i 0; i buttons.length; i) { (function(index) { buttons[index].addEventListener(click, function() { alert(你點(diǎn)擊了第 (index 1) 個(gè)按鈕); }); })(i); }每次循環(huán)都創(chuàng)建一個(gè)新的 IIFE把當(dāng)前的i作為index傳進(jìn)去index就成了那個(gè) IIFE 作用域里的局部變量被回調(diào)函數(shù)通過閉包記住。這樣每個(gè)按鈕的回調(diào)都綁定到了正確的索引。用let的話一行搞定for (let i 0; i buttons.length; i) { buttons[i].addEventListener(click, function() { alert(你點(diǎn)擊了第 (i 1) 個(gè)按鈕); }); }所以在新項(xiàng)目里我基本不會(huì)再用 IIFE 來解決這個(gè)問題了。但如果你維護(hù)的是老代碼或者面試時(shí)被問到這個(gè)知識(shí)點(diǎn)必須爛熟于心。3.4 單例模式與命名空間用 IIFE 組織大型應(yīng)用在大型應(yīng)用里命名空間是避免全局沖突的重要手段。IIFE 可以配合命名空間把相關(guān)功能組織在一起var MyApp MyApp || {}; (function(ns) { ns.utils { formatDate: function(date) { // ... }, parseQuery: function(str) { // ... } }; ns.api { fetchUser: function(id) { // ... } }; })(MyApp);這種寫法在模塊化標(biāo)準(zhǔn)出現(xiàn)之前非常普遍。它把MyApp作為參數(shù)傳進(jìn) IIFE然后在內(nèi)部往這個(gè)命名空間上掛東西。好處是如果MyApp已經(jīng)存在就復(fù)用它如果不存在就創(chuàng)建一個(gè)空對(duì)象。這樣多個(gè)文件可以各自往同一個(gè)命名空間上添加功能互不干擾。單例模式也經(jīng)常用 IIFE 實(shí)現(xiàn)var Singleton (function() { var instance; function createInstance() { return { name: 我是唯一的實(shí)例, doSomething: function() { console.log(doing something); } }; } return { getInstance: function() { if (!instance) { instance createInstance(); } return instance; } }; })(); var a Singleton.getInstance(); var b Singleton.getInstance(); console.log(a b); // trueinstance被藏在 IIFE 里外部只能通過getInstance獲取而且永遠(yuǎn)拿到同一個(gè)實(shí)例。這是單例模式在 JavaScript 里最經(jīng)典的實(shí)現(xiàn)方式之一。4. 常見問題與排查技巧實(shí)錄4.1 語法錯(cuò)誤排查為什么我的 IIFE 報(bào)錯(cuò)了寫 IIFE 時(shí)最常見的錯(cuò)誤就是忘記用括號(hào)把函數(shù)包起來或者括號(hào)位置寫錯(cuò)。下面這張表整理了幾種典型情況和對(duì)應(yīng)的報(bào)錯(cuò)寫法是否合法報(bào)錯(cuò)信息原因function(){ console.log(1); }()否SyntaxError: Function statements require a function name行首是 function被當(dāng)成函數(shù)定義缺少函數(shù)名function foo(){ console.log(1); }()否SyntaxError: Unexpected token (函數(shù)定義后面直接跟調(diào)用括號(hào)不合法(function(){ console.log(1); })()是無圓括號(hào)讓函數(shù)變成表達(dá)式(function(){ console.log(1); }())是無調(diào)用括號(hào)在內(nèi)部同樣合法(function(){ console.log(1); }否SyntaxError: Unexpected end of input括號(hào)不匹配缺少閉合排查這類問題的技巧很簡單看行首是不是function關(guān)鍵字。如果是并且后面沒有函數(shù)名那基本就是這個(gè)問題。解決辦法就是加一對(duì)圓括號(hào)把整個(gè)函數(shù)包起來。還有一種容易忽略的情況在 IIFE 前面一行沒有加分號(hào)導(dǎo)致和上一行代碼連在一起解析。比如var a 1 (function() { console.log(hello); })();這段代碼會(huì)報(bào)錯(cuò)因?yàn)?JavaScript 的自動(dòng)分號(hào)插入ASI機(jī)制不會(huì)在var a 1后面自動(dòng)加分號(hào)引擎會(huì)把1和后面的(function...)連起來解析變成1(function(){...})()也就是把1當(dāng)成函數(shù)來調(diào)用自然報(bào)錯(cuò)。解決辦法是在 IIFE 前面加一個(gè)分號(hào)var a 1; (function() { console.log(hello); })();或者養(yǎng)成習(xí)慣在 IIFE 開頭加一個(gè)分號(hào)var a 1 ;(function() { console.log(hello); })();這種“前置分號(hào)”的寫法在一些風(fēng)格指南里被推薦就是為了防止和上一行代碼粘連。我個(gè)人習(xí)慣是每行都老老實(shí)實(shí)寫分號(hào)這樣最省心。4.2 返回值與 this 指向兩個(gè)容易踩的坑IIFE 的返回值經(jīng)常被忽略。很多人以為 IIFE 就是“執(zhí)行一下”不關(guān)心它返回什么。但實(shí)際上IIFE 是可以有返回值的而且這個(gè)返回值經(jīng)常被用來賦值var result (function() { return { name: test, value: 42 }; })(); console.log(result.name); // test這里 IIFE 返回了一個(gè)對(duì)象賦值給了result。這是模塊模式的基礎(chǔ)。如果你在 IIFE 里忘了寫return那result就是undefined后續(xù)訪問result.name就會(huì)報(bào)錯(cuò)。這是新手常犯的錯(cuò)誤之一。另一個(gè)坑是this的指向。IIFE 內(nèi)部的this取決于它是怎么被調(diào)用的。在非嚴(yán)格模式下直接調(diào)用 IIFEthis指向全局對(duì)象瀏覽器里是window在嚴(yán)格模式下this是undefined。(function() { console.log(this window); // 非嚴(yán)格模式下 true })(); (function() { use strict; console.log(this); // undefined })();如果你在 IIFE 里需要用到外層的this標(biāo)準(zhǔn)的做法是先把this存到一個(gè)變量里var obj { name: myObj, init: function() { var self this; (function() { console.log(self.name); // myObj })(); } }; obj.init();或者用.call()/.apply()顯式綁定(function() { console.log(this.name); }).call({ name: bound }); // bound這個(gè)技巧在事件回調(diào)和異步操作里非常常用因?yàn)榛卣{(diào)函數(shù)里的this往往不是你想要的那個(gè)。4.3 現(xiàn)代 JavaScript 里還需要 IIFE 嗎這是很多人關(guān)心的問題。ES6 之后let/const提供了塊級(jí)作用域class提供了類語法import/export提供了模塊系統(tǒng)箭頭函數(shù)提供了更簡潔的函數(shù)寫法。那 IIFE 還有存在的必要嗎我的看法是在業(yè)務(wù)代碼里IIFE 的使用頻率確實(shí)大幅下降了但在某些特定場景下它依然是最優(yōu)解。第一個(gè)場景是“需要立即執(zhí)行的異步邏輯”。比如你想在模塊頂層用await但又不想把整個(gè)文件變成異步模塊可以用 IIFE 包一個(gè)異步函數(shù)(async function() { const data await fetch(/api/data); console.log(data); })();這種寫法在需要“頂層 await”但環(huán)境不支持的時(shí)候非常實(shí)用。第二個(gè)場景是“需要獨(dú)立作用域的初始化代碼”。比如你在寫一個(gè)腳本需要在加載時(shí)執(zhí)行一些初始化邏輯但又不想污染全局IIFE 依然是最直接的選擇。第三個(gè)場景是“壓縮后的代碼”。壓縮工具經(jīng)常用!function(){}()這種形式來減少字符數(shù)所以你在閱讀壓縮代碼時(shí)還是會(huì)遇到它。第四個(gè)場景是“需要兼容老環(huán)境”。如果你的代碼要跑在一些不支持 ES6 的老瀏覽器上IIFE 依然是組織代碼的可靠方式。所以結(jié)論是IIFE 沒有過時(shí)只是從“日常必備”變成了“特定場景的工具”。理解它能讓你在需要的時(shí)候多一個(gè)選擇也能讓你讀懂大量存量代碼。4.4 常見問題速查表下面這張表整理了 IIFE 使用中最常見的問題和解決辦法方便快速查閱問題現(xiàn)象可能原因解決辦法SyntaxError: Function statements require a function name行首是 function被當(dāng)成函數(shù)定義用圓括號(hào)把函數(shù)包起來SyntaxError: Unexpected token (函數(shù)定義后面直接跟調(diào)用括號(hào)改成函數(shù)表達(dá)式形式循環(huán)綁定事件所有回調(diào)拿到同一個(gè)值var 是函數(shù)作用域共享變量用 IIFE 創(chuàng)建獨(dú)立作用域或改用 letIIFE 返回值是 undefined忘記寫 return在 IIFE 內(nèi)部加上 return 語句IIFE 內(nèi)部 this 指向不對(duì)直接調(diào)用時(shí) this 指向全局或 undefined用 var self this 保存或用 call/apply 綁定IIFE 和上一行代碼粘連報(bào)錯(cuò)上一行沒寫分號(hào)ASI 失效在 IIFE 前加分號(hào)或每行都寫分號(hào)閉包導(dǎo)致內(nèi)存占用高IIFE 內(nèi)的大對(duì)象被閉包引用檢查返回的函數(shù)是否真的需要引用大對(duì)象必要時(shí)手動(dòng)置 null提示排查 IIFE 相關(guān)問題時(shí)第一步永遠(yuǎn)是看控制臺(tái)報(bào)的什么錯(cuò)。語法錯(cuò)誤通常在解析階段就會(huì)拋出錯(cuò)誤信息里會(huì)指明行號(hào)順著行號(hào)看那一行的括號(hào)是否匹配、行首是不是 function基本就能定位。5. 一些個(gè)人經(jīng)驗(yàn)和收尾寫了這么多年 JavaScript我對(duì) IIFE 的感情挺復(fù)雜的。剛開始學(xué)的時(shí)候覺得它很神秘一對(duì)括號(hào)套一對(duì)括號(hào)像是某種咒語。后來理解了它的原理又覺得它有點(diǎn)啰嗦尤其是和let、箭頭函數(shù)比起來。再后來讀了很多老庫的源碼又開始佩服它——在沒有模塊系統(tǒng)的年代前輩們就是用這么樸素的方式硬生生搭出了一套模塊化的方案。如果你現(xiàn)在還在寫業(yè)務(wù)代碼我的建議是新代碼里優(yōu)先用 ES6 的模塊和塊級(jí)作用域IIFE 留給那些它真正擅長的場景。但一定要理解它因?yàn)樗?JavaScript 發(fā)展史上的一個(gè)重要節(jié)點(diǎn)也是讀懂大量存量代碼的鑰匙。最后分享一個(gè)小技巧如果你在瀏覽器控制臺(tái)里想臨時(shí)執(zhí)行一段代碼又不想污染全局變量可以直接用 IIFE 包起來。比如(function() { var temp 臨時(shí)的; console.log(temp); })();執(zhí)行完temp就消失了不會(huì)留在全局。這個(gè)習(xí)慣我在調(diào)試的時(shí)候經(jīng)常用比隨手定義全局變量干凈得多。IIFE 這個(gè)東西說簡單也簡單就是“定義完立刻調(diào)用”說復(fù)雜也復(fù)雜它牽扯到函數(shù)表達(dá)式、作用域、閉包、this 指向、模塊化歷史等一大堆知識(shí)點(diǎn)。你對(duì)它的理解有多深決定了你在什么場景下會(huì)想起它、用它。希望這篇內(nèi)容能幫你把這塊知識(shí)補(bǔ)完整下次再看到(function(){})()的時(shí)候不再是“這啥玩意兒”而是“哦這里需要一個(gè)獨(dú)立作用域”。