一、缘起：一次“反直觉”的Vuex重构

几年前。我在维护一个多版本并行的SaaS项目时踩到了一个经典的坑：两个不同版本的页面共用同一个Vuex Store，导致修改A版本的数据，B版本也跟着“抽风”。

当时的我。根本不懂什么是闭包，只知道“两个页面不该共享同一份数据”。于是我凭着直觉写了一个“工厂函数”：

function createVersionStore { return { state: { data: {} },mutations: { ... } };}// 为每个版本创建独立的Store实例const storeV1 = new Vuex.Store);const storeV2 = new Vuex.Store);

当时只觉得“这样就能隔离数据了”，完全没想到。这个“灵光一闪”的操作，竟然暗合了闭包最精髓的设计模式——函数工厂。

直到今天当我彻底搞懂闭包后才恍然大悟：原来当年那个“瞎猫碰死耗子”的方法，正是闭包在工程化开发中的常用方法。

很多教程会把闭包讲得很玄乎，什么“函数套函数”“作用域链”“垃圾回收”…，但对我真正理解闭包，是从三个关键认知突破开始的：

认知突破1：闭包不是“刻意写的”。而是“自然形成的” 闭包的本质，是函数 + 函数被创建时的环境。只要一个函数能访问到它外部作用域的变量，闭包就自动形成了。

从最经典的例子来看，

function outer { let count = 0;return function inner { count++;说起来，console.log;}，}const counter = outer;counter，// 1 counter;// 2

这里inner函数“记住”了outer里的count变量，即使outer已经执行完毕。说起来，这就是闭包——函数带着它的“背包”去流浪。

认知突破2：闭包的“生死”由引用决定 闭包之所以能“长生不老”，是因为内部函数持有了外部变量的引用。只要内部函数还活着，外部变量就不会被垃圾回收。

但这也带来了内存泄漏的风险。比如的观点是，

function leak { let bigData = new Array.fill;return function { console.log; // 没用到bigData，但bigData仍被闭包持有 };}const fn = leak;// bigData永远无法被回收，除非fn = null

闭包的“销毁”很简单：断开所有对内部函数的引用垃圾回收器会自动清理。

认知突破3：闭包不是单例，每次调用都是“新实例” 这是我最容易混淆的点。很多人以为闭包是“全局共享”的，其实不然。话说回来，

每次调用外部函数。都会创建一套全新的闭包环境。就像工厂生产产品，每次createCounter都会生成一个独立的计数器：

const c1 = createCounter;const c2 = createCounter;c1，// 1 c2;// 1

这正是我当年Vuex方案的底层原理——用闭包实现数据隔离。

三、闭包的三大“陷阱”与之道

理解了原理，还要知道闭包在实际开发中的“坑”。

陷阱1：循环中的闭包

for { setTimeout => console.log,0);}// 输出：3,3,3

从原因来看。var 是函数作用域，所有定时器共享同一个i 。循环结束时i=3 所以都输出3。

说到方法。用let 或立即执行函数：

for {
setTimeout => console.log,);// 输出：,}

陷阱 ：React Hooks 的 “ 闭 包陷阱 ” 在 React 中。闭 包会 “记住 ” 组件渲染时 的 状态快照 ：

function Counter {
const = useState;useEffect => {
const timer = setInterval => {
console.log;// 是
setCount;},)，},);//依赖 为 空，只 执行 一次
}

原因 ： useEffect 只 在首次渲染 时 执行。闭 包捕获 的 是 count= . 的 快照。后续 状态 更新 不会重新 创建 闭 包。

方法 ： 用 函数式 更新 setCount . 或 把 count . 加 入依赖 数组。

陷阱 ：this指向丢失