JavaScript闭包从原理到实战：作用域链、内存泄漏与经典面试题全解析

做了这么多年前端，面试别人的时候几乎必问闭包，被问的时候也几乎每次都得组织一下语言。这玩意说简单也简单，说复杂它能延伸出作用域链、垃圾回收、内存泄漏、柯里化、模块化一大堆东西。很多初学者卡在闭包这儿，不是因为概念多晦涩，而是没找到一个能把“闭包到底是什么”讲清楚的切入点。

我尽量用一篇完整的、能直接“抄作业”的思路，把闭包从底层原理到实际应用，再到面试常考的坑，一次讲明白。

1. 别背定义，先搞清楚闭包为什么存在

闭包的英文是Closure，中文翻译成“闭包”确实挺绕的。我第一次学的时候，教材上写的是“函数和其周围状态的引用组合”，背了好多遍也没啥感觉。后来看得多了，踩的坑多了，才慢慢理解：闭包本质上就是“函数 + 它出生时所在作用域里的变量”打包在一起的东西。

1.1 作用域链是理解闭包的第一块基石

要理解闭包，必须先理解 JavaScript 的作用域机制。JavaScript 的函数在创建的时候，会形成一条作用域链。这条链上挂着从当前函数内部到全局环境的每一层变量对象。

var a = 1; // 全局变量 function outer() { var b = 2; // 外部函数的局部变量 function inner() { var c = 3; // 内部函数的局部变量 console.log(a + b + c); // 能访问到所有层级的变量 } inner(); } outer();

当inner函数执行到console.log(a + b + c)的时候，JavaScript 引擎会先在inner自己的作用域里找a、b、c。找不到b，就往上一层找，在outer的作用域里找到了。找不到a，再往上找到全局。这就是作用域链的查找规则：从内到外，一层一层往外找。

很多人以为闭包是“内层函数返回出去”才产生的，其实不是。只要一个函数引用了外部作用域的变量，闭包就已经形成了。只不过当这个函数还在外层函数内部执行的时候，你看不出它有什么特别的，一旦内层函数被“传递”到了外层函数外面去执行，闭包的价值就体现出来了。

1.2 一个生活化的类比：出差的同事给你留了台电脑

想象一下这个场景：你在公司工位上工作，电脑里存着项目资料。现在你要出差了，你跟同事说：“我工位电脑上的文件夹里有一份资料，你随时可以去取来用。” 同事去你工位用那台电脑，不仅能拿到资料，还能调用里面的工具。

在这个类比里，你工位上的电脑就是outer函数的环境，同事就是inner函数。就算你这台电脑平时没人用、看起来好像“没人管了”，但只要同事还知道它的路径，他就能随时去访问里面的资料。闭包就是让一个函数“记住”它出生时的那个环境，即使这个环境已经执行完毕了，变量也不会被销毁。

注意：这个类比有一个关键点——同事去访问电脑里的资料，不是复制一份带走，而是直接访问原电脑里的数据。所以如果你在同事那边修改了资料，你原来电脑里的数据也会变。这正好对应了闭包引用的特性：内层函数操作的是外层函数作用域里的同一个变量，不是副本。

2. 闭包的核心机制：执行上下文与垃圾回收

很多教程讲闭包只讲“函数返回函数”这个形态，没讲底层的关键——为什么外层函数执行完了，它的变量还能被访问。这就涉及到 JavaScript 引擎的两个核心机制：执行上下文的创建和垃圾回收策略。

2.1 函数的出生记录，比执行结果更持久

在 JavaScript 里，每次函数执行都会创建一个执行上下文。这个上下文包含了函数声明、参数、变量、this指向等信息，存在内存里。

关键在于：当函数执行完毕后，它的执行上下文按理说应该被销毁，里面的变量会被垃圾回收器当作“垃圾”清理掉。但如果这个函数的某个内部函数被返回到了外部，并且这个内部函数还在引用着外层函数的变量，那么垃圾回收器就不会回收这些变量，因为它们在“可达对象”的引用链上仍然存在。

function createCounter() { var count = 0; // 这个 count 按理说在 createCounter 执行完后就该销毁了 return function () { count++; // 但这个匿名函数引用了 count return count; }; } var counter = createCounter(); console.log(counter()); // 1 console.log(counter()); // 2 console.log(counter()); // 3

这段代码里，createCounter执行完以后，count变量为什么没有被销毁？因为createCounter返回的匿名函数还在“惦记”着它。这个匿名函数被赋值给了全局变量counter，只要counter还在，它引用的count就永远活着。

这就是闭包的本质：一个函数在创建时捕获了外部作用域的变量，形成了持久的引用关系。

2.2 闭包不等于内存泄漏，但使用不当会

“闭包会导致内存泄漏”这句话快被说烂了，但严格来说，闭包本身不是内存泄漏，它只是让变量存活时间变长了。真正的问题是：这个变量你明明不需要了，但引用它的人还存在。

我见过的最典型问题，是全局变量不小心捕获了大对象：

var bigData = null; function process() { var largeObj = { a: new Array(1000000).fill('a') }; bigData = function () { console.log(largeObj); // 这个函数引用了 largeObj }; } process();

process执行完后，largeObj本应该被销毁，但由于全局变量bigData还引用着那个匿名函数，而这个函数又引用着largeObj，这1百万个字符串就永远留在内存里了。更麻烦的是，你在bigData不再需要的时候忘了置空，内存就一直被占着。

解决办法很简单：用完了就断开引用。

// 用完后 bigData = null;

这样匿名函数被释放，它引用的largeObj也就能被回收了。

实操心得：我写代码的时候有一条习惯——如果某个闭包是被全局变量或长生命周期对象持有的，一定要在合适的时机手动置空。现代浏览器的垃圾回收已经很智能了，但“引用断开”这件事还得程序员自己来。

3. 闭包的经典实战场景：从数据私有化到柯里化

理解了原理，接下来看几个真正在业务中高频使用闭包的场景。这些场景不是面试造火箭，而是日常开发里天天在用的东西。

3.1 数据私有化：防抖节流的底层逻辑

先看一个最简单的模块化计数器：

var module = (function () { var count = 0; // 外部无法直接访问 return { increment: function () { count++; return count; }, decrement: function () { count--; return count; }, getCount: function () { return count; } }; })(); console.log(module.getCount()); // 0 module.increment(); module.increment(); console.log(module.getCount()); // 2

这里count在 IIFE 的作用域里，外部只能通过module.increment/module.decrement/module.getCount操作它，没法直接赋值。这就是利用闭包实现了真正的“私有变量”。在原生 JavaScript 里，没有private关键字的年代，这是实现数据封装的主要手段。

防抖和节流是闭包最典型的应用场景。它们依赖的核心就是“闭包保存变量状态”：

function debounce(fn, delay) { var timer = null; // 这个 timer 在多次调用之间一直存在 return function () { var context = this; var args = arguments; if (timer) { clearTimeout(timer); } timer = setTimeout(function () { fn.apply(context, args); timer = null; }, delay); }; }

每次调用返回的这个匿名函数，都能访问到上一次调用时保存在timer里的值。如果没有闭包，timer在函数执行完就被销毁了，防抖逻辑根本没法写。可以说，没有闭包就没有现代前端框架里的很多优化机制。

3.2 柯里化：函数式编程的基石

柯里化（Currying）指的是把一个接收多个参数的函数，转换成一系列接收单一参数的函数。闭包在这里的作用是“记住中间结果”。

先看一个最简单的加法柯里化：

function add(a) { return function (b) { return function (c) { return a + b + c; }; }; } console.log(add(1)(2)(3)); // 6

这看着像花架子，但在实际项目中柯里化能极大提升代码复用性。比如现在要写几个不同的请求函数，它们共享同一个baseURL：

function createRequest(baseURL) { return function (path, params) { // 这里可以在这个闭包里访问到 baseURL fetch(baseURL + path, { method: 'GET', params: params }); }; } var request = createRequest('https://api.example.com'); // 之后只需要传路径和参数，baseURL 已经被闭包记住了 request('/user', { id: 1 }); request('/post', { id: 2 });

这种写法的好处是：baseURL只需要配置一次，后续每个请求函数都“记住”了它。如果以后要改接口域名，只需要改createRequest('新的域名')那一处。

3.3 setTimeout 循环陷阱：闭包底下的经典翻车现场

这是闭包最经典的面试题，也是很多新手实际写代码时踩过的坑。先看错误写法：

for (var i = 0; i < 5; i++) { setTimeout(function () { console.log(i); // 输出什么？ }, 100); }

答案是输出 5 个 5。很多初学者第一次跑这段代码都懵了。

原因在于：for循环用var声明的i是一个全局变量，循环过程中的 5 个setTimeout回调函数虽然各自的代码看起来一样，但它们引用的其实是同一个i。等100毫秒后回头执行的时候，i早已经被加到了 5，于是回调打印的全是 5。

解决办法有很多种，最经典的是用闭包“捕获”每次循环时的i值：

for (var i = 0; i < 5; i++) { (function (j) { setTimeout(function () { console.log(j); // 输出 0, 1, 2, 3, 4 }, 100); })(i); }

这里把每次循环的i作为参数j传给 IIFE。j是 IIFE 的局部变量，每次循环都会创建一个新的作用域，每个setTimeout回调捕获的都是当时传入的j，互不干扰。

ECMAScript 6 提供了let关键字，它引入了块级作用域，本质上也是一个“隐式闭包”：

for (let i = 0; i < 5; i++) { setTimeout(function () { console.log(i); // 输出 0, 1, 2, 3, 4 }, 100); }

注意：let解决的思路和 IIFE 不一样，它是在语言层面让每次循环的i都是一个独立的绑定。但底层实现的逻辑依然依赖作用域捕获，理解 IIFE 写法能让你更清楚生态演化背后的原因。

4. 闭包和内存回收的纠葛：什么时候该断开引用

上面已经聊了闭包和垃圾回收的关系，这个环节再深入一些，因为这是实际项目里最容易出现性能问题的部分。

4.1 JavaScript 垃圾回收机制中的可达性分析

现代 JavaScript 引擎（V8、SpiderMonkey 等）都使用“标记-清除”算法来回收内存。简单来说，垃圾回收器会从一组根对象（如全局对象、当前执行上下文中的局部变量）出发，递归地遍历所有被引用的对象。能够到达的对象会被标记为“存活”，无法到达的对象就会被回收。

闭包中的变量是否被回收，完全取决于这个“引用是否可达”。看下面这个例子：

function makeClosure() { var hugeData = new Array(1000000).fill('x'); return function () { // 这里没引用 hugeData console.log('hello'); }; } var fn = makeClosure();

在这个例子里，makeClosure返回的函数并没有引用hugeData，但在旧版引擎里，hugeData依然会被保留，因为引擎无法精确分析闭包引用了哪些变量，只能把整个环境都保留下来。不过在 V8 较新的版本中，引擎优化后，这部分已经做了细化处理。

而在实际项目中，我们应该主动避免“非必要的大对象进闭包”：

// 不推荐：闭包可能会长期持有大数组 function loopAndSet() { var items = new Array(1000000); return function () { document.getElementById('btn').addEventListener('click', function () { // 业务逻辑并不需要 items }); }; } // 推荐：把大对象隔离在闭包外面 function loopAndSet() { var items = new Array(1000000); // 只返回业务函数，避免把 items 暴露到事件监听器 return function () { // 不需要引用 items }; }

4.2 事件监听器和闭包的内存陷阱

最常见的内存泄漏场景之一，是在循环里给 DOM 元素绑定事件监听器，闭包又引用了 DOM 元素自身，形成循环引用。

var buttons = document.querySelectorAll('.btn'); for (var i = 0; i < buttons.length; i++) { buttons[i].addEventListener('click', function () { console.log('按钮被点击了 ' + i + ' 次'); }); }

更隐蔽的问题在于：事件监听器存放在 DOM 元素内部，而 DOM 元素又被闭包引用，形成了一条从 DOM 到闭包又回到 DOM 的引用环。在老版本 IE 里这是内存泄漏的经典源头，现代浏览器已经能处理这种情况了，但如果你长期持有 DOM 的引用，问题依然存在。

一个自查经验：如果需要列表有很多按钮，绑定事件时尽量使用事件委托，用一个处理器管理所有按钮，而不是每个按钮单独绑定闭包。闭包本身不是问题，太多长生命周期的闭包才是问题。

4.3 怎么在不影响功能的前提下减少闭包滥用

闭包是个利器，但不是越多越好。我给自己定过几个规矩，分享给大家参考：

• 局部函数优先：如果一个函数不需要跨作用域访问外部变量，就不要把它定义在另一个函数内部。否则每次外部函数执行都会创建一个新的函数对象，内存消耗和 GC 压力都会增大。
• 及时清理大对象引用：闭包引用的外部变量如果是大型数据（如数组、DOM 集合、图表实例），用完要主动置空。
• 善用模块模式而不是到处定义闭包：能通过模块封装少量函数解决的问题，不要创建几十个独立的闭包。

5. 实战训练：用闭包写一个带缓存的数据请求模块

原理和坑都讲完了，用一个完整的实战例子来把闭包串起来。这个例子是日常开发中非常常见的需求：封装一个带缓存的数据请求函数，同一个参数在短时间内重复请求时，直接返回缓存结果，避免重复发送网络请求。

5.1 需求拆解和方案设计

场景是这样的：页面里多个模块需要请求用户信息，如果用户信息已经请求过，就直接用缓存的结果，不用每次刷新都重新请求。

用闭包来实现这个思路：

function createRequestWithCache(cacheTime) { var cache = {}; // 缓存对象，所有通过 createRequestWithCache 返回的函数共享 var lastRequestTime = {}; return function (url, params) { var key = JSON.stringify({ url: url, params: params }); var now = Date.now(); // 有缓存且没超过缓存时间，直接返回 if (cache[key] && now - lastRequestTime[key] < cacheTime) { return Promise.resolve(cache[key]); } // 没有缓存或缓存过期，发起请求 return fetch(url, { method: 'GET', params: params }).then(function (res) { return res.json(); }).then(function (data) { cache[key] = data; lastRequestTime[key] = now; return data; }); }; } // 创建一个缓存时间为 5 分钟的请求函数 var requestWithCache = createRequestWithCache(5 * 60 * 1000); requestWithCache('https://api.example.com/user', { id: 1 }).then(function (data) { console.log('第一次请求', data); }); requestWithCache('https://api.example.com/user', { id: 1 }).then(function (data) { console.log('第二次请求，命中缓存', data); });

这个模块的核心价值在于：

1. cache和lastRequestTime被闭包保存，外部完全没法直接访问，只能通过requestWithCache返回的函数间接操作，数据安全性好。
2. 所有通过createRequestWithCache创建的函数共享同一个缓存池，不会因为多次调用同一个接口而重复请求。
3. 缓存时间统一配置，灵活可调。

5.2 进一步优化：支持手动清缓存和并发请求合并

上面的例子已经能解决重复请求问题了，但在高并发场景下还有一个问题：如果同一个请求同时发出去了很多次，而第一次请求还没返回，后面全部都会发起重复请求。可以在闭包里存一个 Promise，实现请求合并：

function createSmartRequest(cacheTime) { var cache = {}; var pending = {}; // 存放正在进行的 Promise return function (url, params) { var key = JSON.stringify({ url: url, params: params }); if (cache[key]) { return Promise.resolve(cache[key]); } // 如果同样的请求已经在进行中，直接复用那个 Promise if (pending[key]) { return pending[key]; } var promise = fetch(url, { method: 'GET', params: params }) .then(function (res) { return res.json(); }) .then(function (data) { cache[key] = data; delete pending[key]; // 请求完成后移除 pending 标记 // 定时清除缓存 setTimeout(function () { delete cache[key]; }, cacheTime); return data; }) .catch(function (err) { delete pending[key]; // 失败也要移除 pending，否则下次请求永远不会发出去 throw err; }); pending[key] = promise; return pending[key]; }; }

这里的pending对象就是靠闭包在多个请求之间共享状态。没有闭包，这种跨调用共享内存的逻辑写起来会非常别扭。

5.3 完整的代码走读和注意点

这段代码里有几个细节值得注意：

• pending[key]存的是整个 Promise，而不是null。这样如果第一个请求还没完成，第二个请求直接返回同一个 Promise，相当于两个调用共享同一个网络请求的结果。如果你把它存成“是否在请求中”的布尔值，第二个请求不会拿到第一个请求的结果，还得自己再等一遍。
• .catch里必须delete pending[key]。如果请求失败不清理，后续所有同样参数的请求都会永远返回同一个失败的 Promise，永远不会再发真实请求。
• 定时清缓存用了setTimeout，而不是一个全局的定时器轮询。这样每个接口缓存过期时间是独立的，互不干扰。

实操心得：这个“带缓存 + 请求合并”的函数模板我用了很多年，几乎每个前后端项目都能用上。它展示了闭包最实用的价值——把状态“关”在函数里面，只暴露你需要的操作接口。如果你能把这段代码讲清楚，面试基本就能过。

6. 闭包的进阶拓展：模块化、函数式编程与 JS 引擎优化

闭包不只是面试题，它在工程上还有更深层次的应用，而且和现代 JavaScript 的发展密切相关。

6.1 闭包如何驱动了模块化模式

在没有 ES Module 和 CommonJS 的时代，闭包是前端实现模块化的核心手段。通过 IIFE 加上闭包，可以模拟命名空间和数据私有化：

var MyModule = (function () { var privateVariable = '我是私有的'; function privateMethod() { console.log('我是私有方法'); } return { publicMethod: function () { console.log(privateVariable); privateMethod(); } }; })(); MyModule.publicMethod(); // 我是私有的 / 我是私有方法 MyModule.privateVariable; // undefined，访问不到

这种模式就是“揭示模块模式”，后来被大量前端框架继承和改造。现代 ES Module 虽然提供了语言层面的模块化能力，但底层依然是依赖“作用域 + 导入导出引用”的机制。理解闭包，能让你在使用 ES Module 的时候明白为什么import进来的变量可以被共享、为什么模块内部export的变量能被外部实时访问。

6.2 函数式编程里的偏函数和组合

闭包在函数式编程里的应用更深入。偏函数（Partial Application）指的是固定一个函数的部分参数，产生一个参数更少的函数，本质就是利用闭包保存已经传入的参数。

function createLogger(level) { return function (message) { console.log('[' + level + '] ' + message); }; } var info = createLogger('INFO'); var error = createLogger('ERROR'); info('用户登录成功'); // [INFO] 用户登录成功 error('数据库连接失败'); // [ERROR] 数据库连接失败

这里的level就是被闭包捕获的配置项。在实际工程里，这种模式可以用来做日志分级、API 封装、事件处理函数的预配置等。

还有一个常见的方向是“记忆化”（Memoization），缓存纯函数的计算结果。本质上同样是闭包保存缓存状态：

function memoize(fn) { var cache = {}; return function (arg) { if (cache[arg] !== undefined) { return cache[arg]; } var result = fn(arg); cache[arg] = result; return result; }; } function expensiveCalculation(n) { console.log('正在计算', n); return n * 2; } var memoized = memoize(expensiveCalculation); console.log(memoized(5)); // 正在计算 5 / 10 console.log(memoized(5)); // 10，不需要重新计算 console.log(memoized(10)); // 正在计算 10 / 20

这种“用内存换时间”的思路，在后端、前端都有大量应用场景。

6.3 V8 引擎对闭包的内部处理

最后聊点底层的。V8 引擎在编译 JavaScript 时会做各种各样的优化，闭包相关的优化是其中一块比较有意思的领域。

V8 的“上下文”（Context）指的是函数内部对作用域链中变量的收集。JavaScript 的每个函数执行时，都会创建自己的执行上下文，其中对外层作用域的变量引用，会打包成“上下文上下文”。V8 会尝试把这种上下文中需要长期存在的变量放到堆上，并尽量复用对象空间，减少内存分配。

但 V8 的优化是有条件的：如果一个函数中的变量被闭包引用，那么 V8 就可能无法对它进行“栈上分配”（栈上分配更快），只能放到堆上，导致一定的性能损失。所以在高性能场景（比如循环里创建大量函数）中，闭包的创建成本确实比普通函数要高。

这又回到了我前面提到的建议：不要滥用闭包，尤其是在高频执行的代码里。当一个函数需要被创建并执行成千上万次（比如在循环里），每多一个闭包，就多一次堆分配。虽然现代引擎已经优化得很好了，但在追求极致性能的代码路径上，还是要小心。

7. 面试中闭包必问的几个变体和自检清单

因为闭包是面试高频考点，我把常见的一些面试角度整理一下。这不仅是应付面试，也是检验自己理解深度的一种方式。

7.1 高频问法一：运行结果输出题

题目：

for (var i = 0; i < 3; i++) { setTimeout(function () { console.log(i); }, 0); }

这里不光讲了闭包，还捎带考察了事件循环和var的作用域。深入一点的追问往往就是：为什么是 3 个 3？怎么改成输出 0、1、2？有哪些改法（IIFE、let、bind）？各有什么差异？

7.2 高频问法二：闭包是什么？它有哪些实际应用？

这个问题看似送分，实际上很多候选人答不好。如果只背定义，一下子就空了。我的建议是把问题拆成三层：

• 概念层：函数 + 词法作用域 = 闭包，本质是函数记住创建时的环境。
• 原理层：作用域链、执行上下文、垃圾回收的可达性判定。
• 应用层：数据私有化、防抖节流、柯里化、缓存、模块化。

7.3 高频问法三：闭包一定会造成内存泄漏吗？

这个问题要一分为二地答。先说结论：闭包本身不是内存泄漏，它只是让变量引用持续存在。真正的问题是程序员使用不当导致长生命周期对象长期持有不再需要的引用。然后给出实际案例和解决办法。

7.4 高频问法四：模拟私有变量

直接手写一个 IIFE + 闭包的模块，展示count只能通过暴露的操作函数修改，不能让外部直接module.count = 100绕过。这道题能同时考察闭包、IIFE、对象封装、JavaScript 的访问控制机制。

7.5 自检清单：你对闭包的掌握到哪一层

如果这些项多数都不确定，建议对照文章里的例子手打几遍，一边打一边观察变量的变化，比只看不练强很多。

8. 聊点实际的：闭包在真实项目里的几个使用心得

最后分享一些我这么多年写下来的真实感受，不一定都是教科书里能学到的。

我第一次真正意识到闭包的重要性，是接手一个老项目中混乱的全局变量时。那时候根本没有什么模块化规范，所有函数共享着一堆全局状态，一个变量在十几个地方被修改，排查 bug 简直是在大海捞针。后来我用 IIFE + 闭包把相关功能封装起来，每个模块只暴露最小的操作接口，代码的 bug 率肉眼可见地降下来了。

还有一个心得：闭包的代码往往在没有注释的情况下很难读懂，因为函数和外部变量的关系藏在作用域链里，不像对象或类那样有显式的属性关系。所以我建议在写闭包的地方，尤其是在返回函数的地方，都写上注释，说明这个闭包捕获了哪些外部变量、生命周期是多久、在哪里可以被释放。这在团队协作时能省下大量互相沟通的成本。

最后，我用闭包最多的地方其实是“延迟初始化”和“单例模式”。比如某些工具类只需要初始化一次，就把初始化后的实例存在闭包里，后续调用直接返回：

var getConfig = (function () { var config = null; return function () { if (!config) { config = loadConfigFromServer(); // 只在第一次调用时执行 } return config; }; })();

这种模式的优雅之处在于：调用方不需要关心初始化逻辑，只要知道“调用 getConfig 就能拿到配置”，不需要知道内部有没有缓存、什么时候初始化。闭包把复杂性封装得干干净净，这正是我认为的工程美学的体现。

我建议你学闭包的时候，别急着背概念，先把文中的例子敲一遍，再自己写一个“用闭包缓存计算结果”的函数，最后尝试把一段用全局变量的代码重构成闭包封装。等你真正把闭包“用顺手”了，再回头看那种“函数 + 词法作用域”的定义，会有一种“原来如此”的顿悟感。