闭包是函数记住并访问其定义时词法环境的能力：函数被返回或外部引用后仍可使用定义时的变量，这些变量因被“关闭”引用而不被垃圾回收；关键在于词法作用域而非调用位置。
闭包是什么：函数记住了它诞生时的词法环境
闭包不是特殊语法，而是 JavaScript 中函数天然具备的行为：当一个函数被返回（或以其他方式在定义它的作用域外部被引用）时，它仍能访问自己定义时所在作用域中的变量。这些变量不会被垃圾回收，因为该函数“关闭”了对它们的引用。
关键点在于「词法作用域」——变量查找取决于函数写在哪，而不是在哪调用。比如：
function makeCounter() {
let count = 0;
return function() {
count++;
return count;
};
}
const counter = makeCounter();
console.log(counter()); // <code>1</code>
console.log(counter()); // <code>2</code>
count 在 makeCounter 执行完后本该消失，但它被内部返回的函数持续持有，这就构成了闭包。
为什么闭包在 JS 中不可替代
JavaScript 没有私有字段（ES6 class 的 #field 是后来加的，且不解决状态封装问题），也没有块级静态变量，闭包是实现数据封装与状态持久化的最直接机制。
立即学习“Java免费学习笔记（深入）”；
- 模块模式：用立即执行函数 + 闭包模拟私有变量和方法
- 事件处理器中保存上下文：避免
this或循环索引丢失（比如for (let i = 0; i console.log(i), 0); }能正常输出0、1、2，靠的就是每次迭代中let绑定的新词法环境，本质仍是闭包） - 柯里化与偏函数：预设部分参数，返回新函数保留原始参数上下文
- 防抖/节流函数：需要记住上一次触发时间或定时器 ID，这些状态必须隔离在每次调用生成的闭包中
常见闭包误用与内存泄漏风险
闭包本身不导致内存泄漏，但不当持有大对象或 DOM 引用会阻止垃圾回收。
典型陷阱：
- 在全局或长生命周期对象（如
window、单例类实例）上挂载闭包，而闭包又引用了大型数组、缓存对象或 DOM 节点 - 为每个 DOM 元素绑定闭包处理器，但忘记在元素销毁时解绑，且闭包内又引用了该元素自身（形成循环引用，在旧版 IE 中尤其危险）
- 滥用闭包模拟“私有属性”，却把整个对象塞进闭包，结果比用
WeakMap或私有字段更难调试和序列化
验证是否真需要闭包？先问：这个变量是否必须跨多次调用保持状态？能否用参数传入代替？能否用 WeakMap 关联实例而不延长生命周期？
闭包与 let/var 在循环中的表现差异
这是最容易混淆的实际场景。区别根源不在闭包本身，而在变量声明方式如何影响词法环境的创建次数。
var 声明提升且函数作用域，整个循环共享一个 i；let 是块级作用域，每次迭代都新建绑定 —— 所以闭包捕获的是不同绑定，而非“修复了闭包”。
for (var i = 0; i < 3; i++) {
setTimeout(() => console.log(i), 0); // 全部输出 <code>3</code>
}
for (let i = 0; i < 3; i++) {
setTimeout(() => console.log(i), 0); // 输出 <code>0</code>, <code>1</code>, <code>2</code>
}
如果必须用 var，可显式创建闭包来隔离：for (var i = 0; i console.log(i), 0); })(i); }。但更推荐直接用 let —— 它让闭包行为更符合直觉，也减少了手动封包的出错机会。
真正难的从来不是写出闭包，而是判断某个状态是否值得用闭包长期持有，以及当它开始拖慢页面或让内存占用居高不下时，能否快速定位到是哪个闭包在悄悄留着不该留的东西。
