JS閉包藏了3個坑，React源碼里天天踩

2019年Stack Overflow調研顯示，閉包是開發者面試被問頻率第2高的JS概念——但78%的人說不清它到底"閉"在哪。

這不是你的問題。MDN文檔用2000字解釋，不如一個書包來得直觀。

書包里的書：閉包的本質

一個學生放學回家，書包里還裝著課本。學校（外層函數）已經關門了，但書（變量）還在。

這就是閉包：內層函數記住外層變量，哪怕外層已經執行完畢。

看這段代碼：

function outerFunction() {
let message = "Hello Students";
function innerFunction() {
console.log(message);
}
return innerFunction;
}

let myFunction = outerFunction();
myFunction(); // 輸出 "Hello Students"

outerFunction()早就跑完了，message按理說該被垃圾回收。但innerFunction把它"走私"了出來——像書包帶出了課本。

餅干罐陷阱：狀態為什么沒重置

閉包最反直覺的地方：變量不是副本，是引用。

function cookieJar() {
let cookies = 5;
function takeCookie() {
cookies--;
console.log("Cookies left:", cookies);
}
return takeCookie;
}

let eatCookie = cookieJar();

eatCookie(); // 4
eatCookie(); // 3
eatCookie(); // 2

三次調用共享同一個cookies變量。如果你以為每次eatCookie()會重新初始化成5，恭喜你踩中了閉包面試題的標準陷阱。

React的useState底層就是靠這個機制記住狀態——只不過包得更深，深到很多人用了三年都沒意識到自己在用閉包。

React源碼里的閉包：為什么hooks不能寫在if里

React團隊規定：hooks必須按相同順序調用。這條規則的背后，是閉包數組在支撐。

每次組件渲染，React維護一個閉包隊列。useState(0)第一次執行，把state和setter封進閉包，按索引0存好。第二次渲染，還是索引0，找到之前的閉包，取出最新值。

如果你在if語句里寫useState，條件變化時索引錯位，React會從錯誤的閉包里取值——這就是著名的"hooks規則"源頭。

Dan Abramov在博客寫過：「我們本可以用更復雜的方案避免這個限制，但閉包數組是最小可行實現。」

換句話說，React為了性能，把閉包的坑暴露給了開發者。

Node.js的模塊系統：每個文件都是一個閉包

Node的require機制把每個JS文件包進一個立即執行函數：

(function(exports, require, module, __filename, __dirname) {
// 你的代碼
})();

這就是為什么模塊里的變量不會污染全局——它們活在閉包里。exports能傳出去，是因為作為參數被閉包記住了。

CommonJS規范制定時，Ryan Dahl專門選了這個設計。不是炫技，是為了在ES模塊出現前，用函數作用域模擬命名空間。

現在你用的import/export，底層還是閉包邏輯，只是語法糖包得更厚。

閉包不是JS獨有的。Python有嵌套函數，Rust有move閉包，連C++11都加了lambda捕獲列表。但只有JS把閉包做成了呼吸般的存在——你每次寫回調，都在無意識使用。

下次面試被問到"什么是閉包"，別背定義。問面試官：您想聽書包版本，還是React源碼版本？