深入理解JavaScript闭包：作用域、防抖与内存管理

在网上看过很多前端帖子，都在问“闭包到底怎么理解”，也有不少新手朋友跟我说：面试背了不少概念，但一到看代码还是一脸懵，更别说闭包写进项目里了。说实话，闭包在JavaScript里确实是个特别容易绕晕的点，但它真没有传说中那么神。很多你天天在用的代码，其实早就悄悄用上了闭包，只是没人告诉你“这就是闭包”而已。

这篇文章会走一条跟教科书不太一样的路子：先从一个最小代码例子开始，让你真的看懂闭包长什么样；再解释它为什么能“记住”变量；最后给几个可以直接抄进项目的场景。目标只有一个：看完能用自己的话说清楚闭包，甚至能讲给旁边同事听。

1. 闭包的真实身份：从作用域聊起

1.1 先搞清楚JavaScript变量能去哪串门

理解闭包之前，得先把作用域这个前置知识点捋顺。JavaScript里，变量的可见范围是由函数边界决定的，这一点跟很多语言不太一样。一个变量定义在哪个函数内部，它就只能在那个函数内部以及更深层的函数里被访问，跑到函数外面就找不到了。

javascript复制function greet() {
  var word = 'hello';
  console.log(word); // 输出 hello
}

console.log(word); // 报错：word is not defined

看上面这段，word被关在greet的“房间”里了，外面代码想访问它直接报错，这种可见范围就叫作用域。JavaScript的作用域是词法作用域，说白了就是：函数能访问哪些变量，是在你写代码、定义函数的地方就决定好的，跟函数到底在哪里被调用没有关系。

这个“写在哪就决定能访问谁”的规则，是整个闭包概念的底层地基。你只要记住了这句话，后面理解闭包就是一个顺水推舟的事。

1.2 一个最简闭包：函数内部定义函数并返回

很多教材把闭包定义成“函数和它外部变量的组合”，这个说法没错，但太抽象。我更喜欢用一段能跑起来的代码来解释。

javascript复制function makeCounter() {
  let count = 0;
  return function () {
    count++;
    return count;
  };
}

const counter = makeCounter();
console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

这里发生了什么？makeCounter执行完之后，按一般理解，它内部的局部变量count应该被销毁才对，因为它所在函数已经执行完毕了。但是结果却显示count一直活着，每次调用counter()都能在原来基础上加一。

关键就在return function () { ... }这行：内部函数引用了外部函数的局部变量count，当这个内部函数作为返回值被扔到外面，并且被counter变量接住时，它就把count的“访问权”一起带出去了。哪怕makeCounter已经执行完，带着count的这个内部函数还在外面活着，count就会跟着这个函数继续存活。

这就是闭包的形成：函数 + 它创建时能访问到的外部变量。一个东西能把两层“房间”串起来，内外都能操作数据，这就是闭包。

为了加深印象，再看另一个容易被误解的小例子：

javascript复制function outer() {
  let x = 1;
  function inner() {
    console.log(x);
  }
  inner();
}
outer();

这段代码里inner也访问了x，但它是在outer内部被调用的，并没有把函数带到外部去。严格说，这里面存在闭包所需的结构，但由于内部函数与外部作用域的引用关系在函数执行期间就结束了，它通常不会被拿出来当作“闭包应用”来讨论。如果你在面试里说这也是闭包，也不能算错，但实际我们研究闭包，更多关注的是上面那种“函数被返回出去、变量生命周期被延长”的情况。

2. 闭包为什么能“记住”变量：底层原理不用啃源码也能懂

2.1 变量生命周期被“续命”的机制

平时我们写代码，函数执行结束，它内部的局部变量基本就会被当垃圾回收。毕竟没人再需要它们了，留着占内存干嘛呢？但闭包的出现改变了这个回收规则。

得先知道一个事实：JavaScript引擎并不傻，它不是看函数是不是执行完了来决定清不清变量，而是看这个变量还有没有被其他活着的东西引用着。前面的count，它的家原本在makeCounter的函数作用域里，但内部函数function () { count++ }的外部引用一直存在，这个内部函数被赋值给了全局的counter，只要程序还跑着，counter这个引用就不会死。

在引擎内部，某个变量还被一个仍然可达的函数引用着，那这块内存就不能释放。所以makeCounter虽然退场了，但它的变量对象被内部函数牢牢抓着，这就是为什么你还能继续操作count。

如果你把counter这个引用释放掉呢？

javascript复制counter = null;

让counter不再指向那个内部函数，此时内部函数没人用了，它连带着count变量，才会一起进入可回收状态，内存才会被让出来。这在后面讲内存管理时很实用，先留个印象。

2.2 闭包捕获的是变量本身，不是那一刻的快照

新手理解闭包时最容易掉进去的坑，是以为闭包捕获的是外部变量“当时的值”，就像拍了一张照片。但真相是，闭包抓的是变量本身，它会实时反映外部变量的当前值。

javascript复制function prepareLogger() {
  let message = '初始值';
  function log() {
    console.log(message);
  }
  message = '被修改后的值';
  return log;
}

const logger = prepareLogger();
logger(); // 输出：被修改后的值

看到没，prepareLogger在执行完之前把message改成了'被修改后的值'，返回出去的log函数打印的依然是修改后的值。闭包没有帮助你保存旧值，它保存的是一个“活的通道”，这个通道指向变量本身的内存位置。

这个特性，既是闭包的好用之处（可以做缓存、修改私有状态），也是很多诡异问题的来源。比如循环里挂事件、定时器结果全部输出最后一个值，根源就在这里。第4章会专门展开说。

3. 闭包的三个实战场景：防抖、计数器、模块状态封装

3.1 防抖函数：面试与项目都高频的闭包应用

防抖是个很经典的场景。搜索框每输入一个字都触发一次接口请求，后端容易被刷爆；但你不能不监听输入事件，所以需要在事件触发后延迟执行请求，并且在用户还在连续输入时不断重置定时器。

用闭包实现直截了当，因为外部函数刚好可以帮内部函数保存timer这个状态：

javascript复制function debounce(fn, delay) {
  let timer = null;
  return function (...args) {
    if (timer) {
      clearTimeout(timer);
    }
    timer = setTimeout(() => {
      fn.apply(this, args);
      timer = null;
    }, delay);
  };
}

这样调用：

javascript复制const handleInput = debounce(function (query) {
  console.log('发起搜索请求：', query);
}, 300);

document.querySelector('#searchInput').addEventListener('input', (e) => {
  handleInput(e.target.value);
});

debounce本身只执行了一次，但返回的匿名函数每一次输入事件触发时都能访问同一个timer变量。用户一旦在300毫秒内继续输入，旧的定时器被清掉，重新起一个。只有用户停下来超过300毫秒，请求才真正发出。

这里如果没有闭包，timer就只能放在全局，然后每次调用都得手动管理，代码会变得很脏，还可能被别的地方误改。闭包帮你把一个局部的、不可被外部任意篡改的状态保存下来，这才是防抖设计的精妙所在。

3.2 一步步自增的计数器：状态封装的最小例子

你现在再回头看1.2节的计数器，会发现它不仅简单，还代表着一种通用模式：把某个状态锁在函数内部，只暴露受控的操作接口。

javascript复制function createIdGenerator(prefix) {
  let id = 0;
  return {
    next() {
      id++;
      return prefix + '-' + id;
    },
    reset() {
      id = 0;
    },
  };
}

const bookIdGen = createIdGenerator('book');
console.log(bookIdGen.next()); // book-1
console.log(bookIdGen.next()); // book-2
bookIdGen.reset();
console.log(bookIdGen.next()); // book-1

用同一个createIdGenerator可以创建多个完全独立的计数器，彼此之间互不影响。这个能力看起来简单，但如果你不用闭包，想要做一个“私有的、不会被页面其他脚本误改的计数器”就特别困难，总有人可能不小心把全局变量改了，或者多个功能之间串了值。

闭包在这个例子里的价值是：状态隔离。每个计数器实例有自己的id，外面只能通过暴露出来的方法操作它，不能直接把它改乱。

3.3 模块级状态封装：不用class也能写模块

过去很长一段时间里，前端还没有class或者ES Module普及，闭包承担了模块化的“带刀护卫”。即使到今天，闭包依然是实现私有变量的好手段。来看一个订单模块的例子：

javascript复制const orderManager = (function () {
  let orders = [];

  function addOrder(item) {
    orders.push({
      item,
      time: new Date(),
    });
  }

  function getOrders() {
    return orders.length;
  }

  return {
    addOrder,
    getOrders,
  };
})();

orderManager.addOrder('前端课程');
orderManager.addOrder('后端课程');
console.log(orderManager.getOrders()); // 2

这个模式叫IIFE，立即执行函数。IIFE执行后返回一个新对象，新对象里的函数通过闭包引入了内部的orders、addOrder、getOrders。从外面看，orderManager暴露的只有addOrder和getOrders两个方法，没法直接操作orders数组。如果你想在控制台敲orders，得到的会是is not defined。

这种模式的意义在于，内部的私有数据不会污染全局，也不会被任何外部代码意外修改。函数式编程的设计思路和闭包的结合，至今在很多项目里依然很常见。

4. 经典坑解密：for循环里的var和let到底差在哪

4.1 新手翻车现象

我不知道多少人遇到这个场景：想给三个按钮分别绑定点击事件，点击第一个按钮输出0，点击第二个输出1，点击第三个输出2，结果网页打开后发现，点哪个按钮数字都输出3。

代码长这样：

javascript复制var buttons = document.querySelectorAll('button');
for (var i = 0; i < buttons.length; i++) {
  buttons[i].addEventListener('click', function () {
    console.log(i);
  });
}

如果没有按钮，用setTimeout复现也是一样的：

javascript复制for (var i = 0; i < 3; i++) {
  setTimeout(function () {
    console.log(i);
  }, 100);
}
// 输出 3 3 3

4.2 var循环变量被所有回调函数共享

现在你已经知道闭包的机制了，完全可以倒推出原因：用var声明的i，作用域是整个函数，不存在“每次迭代一个独立变量”这件事。循环跑了三遍，自始至终只有同一个i变量，它的值先变成0，再变成1，再变成2，最后变成3。循环结束后，那三个匿名函数被依次执行，它们捕获的i引用是同一个，指向的当然是最终值3。

不是JavaScript说“我要给你输出3”，而是定时器里的函数在定义的瞬间根本没有执行，等到100毫秒之后它们才执行，那时候i早已经是3了。这正是闭包“捕获变量引用而不是值”的体现。

4.3 两套标准修复方案

修复方案共有两种常见写法。

javascript复制// 方案一：把 var 改成 let
for (let i = 0; i < 3; i++) {
  setTimeout(function () {
    console.log(i);
  }, 100);
}
// 输出 0 1 2

用let时，每次迭代都会创建一个新的词法环境，i不再是循环外共享的一个变量，而是每一轮都会出现的独立绑定。第一个定时器里的函数拿到的是第0轮的那个i，第二轮拿到的是第1轮的i。这三个函数即使稍后执行，看到的值也彼此独立，所以输出结果是0、1、2。

javascript复制// 方案二：用传入参数的方式把值冻结在实参里
for (var i = 0; i < 3; i++) {
  (function (num) {
    setTimeout(function () {
      console.log(num);
    }, 100);
  })(i);
}
// 输出 0 1 2

这个方案在很多老项目里见得多。IIFE的形参num在每次调用时都会接收当时的i值，setTimeout里的函数捕获的是这个形参num。而每次调用IIFE时会产生一个新的函数作用域、一个新的num绑定，于是三次回调各自记住了0、1、2。

理解这里的关键后，就不需要死记答案了。只要记住：闭包不会帮你存旧值，它存的是引用。如果你希望每个回调拿到某一轮的“快照”，要么用let制造独立作用域，要么手动把值作为参数传进去。

5. 闭包与内存：什么时候该担心，什么时候不用慌

5.1 闭包可能带来内存泄漏吗

很多文章一提到闭包就把它跟内存泄漏绑在一起，仿佛用了闭包内存就一定会爆炸。这是个很大的误解。真相是：JavaScript本身就是垃圾回收的语言，该清的内存引擎一定会清，闭包并不会凭空产生无法释放的内存。它只是破坏了“函数执行完就直接回收局部变量”这个默认行为，让某些变量因为还被引用而继续存活。

那什么时候确实该担心？两个条件同时满足时：

• 这个包含闭包的函数被赋给了某个全局变量，或者被长期挂在事件监听、定时器上；
• 内部引用的外部数据非常大，比如一个很大的数组、一个很长的字符串、一个DOM节点。

比如这样：

javascript复制const heavyHandler = (function () {
  const bigData = new Array(1000000).fill('数据');
  return function () {
    console.log('处理一下数据');
  };
})();

heavyHandler在全局引用着返回的匿名函数，而这个匿名函数背着bigData这个大包袱。哪怕你的业务逻辑根本用不到全部数据，只要heavyHandler一直存在，这100万个元素的内存就不会被释放，这在大型项目里是实打实的隐患。

但严谨地说，这不算“泄漏”，因为变量依然可达，引擎认为“它还在被使用”。只是你可能没想到，一个处理逻辑的小函数，竟然把这么大一个数据块也拖住了，变相造成了本可用内存的浪费。

5.2 到底怎么安全释放

如果确实遇到闭包拖着大对象不放的情况，处理方式很直接：当这个闭包函数不再需要时，把引用停掉。

javascript复制heavyHandler = null;

引用一断，整个闭包链都会被引擎标记为不可达，紧接着下一次垃圾回收就会把这块内存收回去。

另外，在写闭包时也应该保持一个习惯：不要在一处闭包里堆入全宇宙的数据。你只要让闭包访问它真正需要的那几个变量就行，不要顺手把所有父级作用域的变量都引进来。很多人写代码时，因为闭包函数在外层作用域里可以访问到某些变量，就不管三七二十一把它们全部放进了逻辑里。

这种写法短期看能跑通，长期看会造成两个问题：一个是内存占用偏高，另一个是变量之间的依赖变得难以梳理。谁改动了外层变量，你内层的闭包行为就可能被意外影响，调试起来非常酸爽。

所以我的经验是：闭包能细就细，别做一个粗粒度的“巨型闭包”。如果一段数据只需要在某个短暂操作里使用，那不如直接把数据作为参数传进去，而不是留一个大闭包引用。

6. 用闭包优化代码的几个“手感”建议

6.1 判断一段代码是不是闭包

面试和Code Review时，判断一段代码是不是闭包，可以快速问自己三个问题：

• 一个函数是否定义在另一个函数内部？
• 内部函数是否引用了外部函数作用域中的变量？
• 内部函数是否有机会在外部函数执行完之后继续被调用？

如果三个都是肯定的，那闭包基本跑不了。如果第三个是否定的，虽然结构上存在闭包条件，但实际对生命周期的影响很小，很多时候也不会被同等看待。

6.2 我写闭包时遵循的安全习惯

有几点属于花过学费换来的经验：

• 只需要一个对象的状态时，优先用闭包封装，而不是把一堆状态铺成全局变量，全局变量越多程序越难预测；
• 访问外部变量时要思考这个变量后续会不会变化，如果希望固定成某个瞬间的值，用参数传值进去更安全；
• 不要轻易让返回的函数去访问一个特别庞大的外层数据对象，先问自己能不能只取其中一个字段；
• 遇到内存明显上涨的场景，优先排查是不是有闭包长期保存了大数组或DOM引用。

6.3 给前端面试的临场建议

闭包在面试里几乎属于必考。被问到时不用急着背定义，可以从代码入手讲流程，也可以从场景入手反推为什么需要闭包。

举个例子，你可以这样说：“闭包，就是函数在定义的时候记住了自己所在的词法作用域，所以即使函数被拿到别处执行，也能通过这个作用域链访问到外部的变量。最常见的场景是防抖，因为防抖函数内部需要保存定时器编号，如果不用闭包就得把定时器编号挂在全局，容易污染。”

这个回答把定义、关键机制、实际场景串到了一起，比单纯背书的效果好很多。如果考官继续追问“闭包有什么缺点”，你就可以说：变量生命周期变长，使用不当可能导致内存没法自动回收；另外如果对外层变量的引用处理不当，可能会产生一些意料之外的共享状态，比如循环绑定事件全部播放最后一个序号。

把这些讲清楚，闭包这关基本就过了。回到项目本身，再看一遍自己手写的防抖、计数器和模块封装，你会发现“神技”早已在身边。越是深入写JavaScript，越会感受到闭包不是需要背的面试题，而是一种与函数作用域共生的思维方式，一旦想通，很多代码逻辑都会变得清晰起来。