闭包是 JavaScript 中最核心也最容易被误解的概念之一。面试中被问到，工作中不经意间用到，出问题时又常常被归咎于它。本文不谈学院派定义，而是从执行机制出发，结合真实场景，帮你彻底理解闭包，并学会在生产环境中安全地使用它。
闭包的本质：词法作用域的“记忆”
一句话概括：闭包是函数与其定义时所处词法作用域的组合。当函数在定义它的作用域之外被调用时，它依然能访问那个作用域中的变量。
function createCounter() {
let count = 0; // 被闭包“捕获”的变量
return function () {
count += 1;
return count;
};
}
const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2
createCounter 执行完毕后，按常理其局部变量 count 应该被回收。但由于返回的匿名函数持有对 count 的引用，这个变量被保留了下来。这就是闭包的核心机制：变量的生命周期由引用关系决定，而非函数调用栈。
理解闭包，关键要区分两个概念：
- 词法作用域：函数在哪里定义，决定了它能访问哪些变量，而不是在哪里调用。
- 执行上下文：每次函数调用会创建新的执行上下文，但闭包捕获的是定义时的词法环境，不是调用时的。
经典应用场景
1. 数据私有化与模块模式
在 ES Module 普及之前，IIFE + 闭包是实现私有变量的标准方案：
const userModule = (function () {
let users = []; // 外部无法直接访问
return {
add(name) { users.push(name); },
list() { return [...users]; } // 返回副本，保护内部数据
};
})();
即使现在有了 #private 字段和模块作用域，闭包依然是实现工厂函数、状态封装的基础手段。
2. 函数柯里化与偏应用
function multiply(a) {
return function (b) {
return a * b;
};
}
const double = multiply(2);
const triple = multiply(3);
console.log(double(5)); // 10
console.log(triple(5)); // 15
闭包让 a 的值被“固化”在返回的函数中，这是函数式编程中柯里化、组合、管道等模式的基础。
3. 事件处理与回调中的状态保持
function setupButtons() {
for (let i = 0; i < 3; i++) {
document.getElementById(`btn-${i}`)
.addEventListener('click', () => {
console.log(`按钮 ${i} 被点击`);
});
}
}
这里 let 的块级作用域为每次迭代创建了独立的绑定，每个回调捕获各自的 i。如果用 var，三个回调会共享同一个 i，全部输出 3——这是经典的闭包陷阱，也是面试高频考点。
4. 防抖与节流
function debounce(fn, delay) {
let timer = null; // 闭包保存定时器引用
return function (...args) {
clearTimeout(timer);
timer = setTimeout(() => fn.apply(this, args), delay);
};
}
timer 变量在 debounce 返回后依然存活，每次调用共享同一个定时器引用，从而实现“取消上一次”的逻辑。没有闭包，这个模式无法实现。
内存泄漏：闭包什么时候会“出事”
闭包本身不是内存泄漏的原因。真正的问题是：闭包持有的变量如果不再需要，却因为引用链未断开而无法被回收。
场景一：DOM 引用未释放
function attachHandler() {
const hugeData = new Array(1e6).fill('x');
const el = document.getElementById('target');
el.addEventListener('click', () => {
console.log(hugeData.length); // 闭包持有了 hugeData
});
}
即使 el 从 DOM 中移除，只要事件监听器没被移除，闭包就继续持有 hugeData，导致大数组无法回收。
解决：移除 DOM 时同步移除监听器，或使用 AbortController：
const controller = new AbortController();
el.addEventListener('click', handler, { signal: controller.signal });
// 需要清理时：
controller.abort();
场景二：定时器中未清理的引用
function startPolling() {
const cache = new Map();
setInterval(() => {
fetchData().then(data => cache.set(Date.now(), data));
}, 5000);
}
setInterval 的回调永远持有 cache，且定时器本身不会被回收。如果这个函数被多次调用，会累积多个永不停止的定时器和各自的内存数据。
解决：保存 timer ID，在适当时机 clearInterval；或用 WeakRef / FinalizationRegistry（现代环境）做弱引用缓存。
场景三：意外的全局引用
function processData() {
const bigResult = computeExpensiveResult();
// 不小心挂到了全局
window.__lastResult = bigResult;
return function () {
return bigResult.summary;
};
}
闭包 + 全局变量双重持有，内存永远无法释放。
防范原则
- 最小捕获：闭包中只引用真正需要的变量，不要把整个大对象塞进去。
- 及时解绑：事件监听器、定时器、观察者在组件销毁时务必清理。React 的
useEffect返回清理函数就是这个道理。 - 用
let/const替代var：避免循环中的共享绑定问题，减少意外捕获。 - 弱引用优先：缓存场景考虑
WeakMap/WeakSet，让键对象可被回收。 - DevTools 验证：用 Chrome Memory 面板拍堆快照，搜索闭包变量名，确认是否被意外保留。
小结
闭包不是需要“避免”的特性，而是 JavaScript 表达力的重要来源。理解它的本质——函数记住定义时的词法环境——就能在模块封装、回调、函数式编程中自如运用。至于内存问题，根源往往不在闭包本身，而在于引用关系没有被正确断开。把清理逻辑当作功能的一部分来写，闭包就不会成为隐患。
未经允许不得转载：任鹏个人博客 » JavaScript 闭包实战：原理、应用场景与内存泄漏防范
