闭包是JavaScript执行模型的自然结果：内层函数定义在外层函数内部、实际访问外层局部变量、且在外层执行完后仍被调用，三者缺一不可；它用于封装私有状态、保存异步上下文、实现函数工厂，但也易致内存泄漏和变量共享问题。
闭包就是函数“带着出生地的户口本”在外地干活
它不是语法糖，也不是高级技巧——而是 JavaScript 执行模型的自然结果：只要一个函数定义时能访问某个变量，且这个函数后来被带到别处执行（比如被返回、传给 setTimeout 或事件监听器），而它又真用了那个变量，那这个变量就被“锁住”，和函数一起形成闭包。
关键判断标准就三条，缺一不可：
-
inner函数必须写在outer函数内部 -
inner要实际读/写outer的局部变量（不是参数，也不是全局变量） -
inner被返回、赋值给变量、或作为回调传出去，导致它在outer执行完后还能被调用
为什么你会在真实代码里反复撞上闭包？
不是因为面试要考，而是它在解决几个高频现实问题时几乎不可替代：
-
封装私有状态：比如
createCounter()返回的对象里，count变量对外不可见，只能通过increment()操作——没有闭包，就得靠命名约定（如_count）硬扛，毫无保护力 -
保存异步上下文：循环中绑
click事件，用var i = 0会全变成最后一个值；但用闭包（如 IIFE 或let声明）就能让每个回调记住自己的i -
函数工厂：像
createAdder(5)返回一个“加 5 函数”，createAdder(10)返回“加 10 函数”，逻辑复用干净利落
闭包最常踩的坑：内存不回收 + 变量共享错觉
你以为只是“多记了个变量”，其实 JS 引擎得为整个外层词法环境续命。典型症状：
立即学习“Java免费学习笔记（深入）”；
- DOM 元素删了，但绑定的事件处理函数还拿着父作用域里的大对象（如
dataList），导致内存泄漏 - 在循环里用
var创建闭包，所有回调共享同一个变量绑定，输出全是10（ES5 经典陷阱） - 过度嵌套闭包（比如五层函数套娃），每次访问变量都要沿作用域链向上查，性能肉眼可感变慢
规避方法很简单：let 替代 var 解决循环问题；不用时手动把闭包引用设为 null；避免在闭包里捕获巨型对象或 DOM 节点。
现代 JS 里闭包还在幕后扛活吗？
当然在。React 的 useState 和 useEffect 依赖闭包保存 hook state 和依赖数组；Webpack 打包后的模块包裹函数（(function(){...})()）本质就是靠闭包隔离作用域；甚至 async/await 编译成 Promise 链后，每个 then 回调都靠闭包维持上一步的局部变量。
真正容易被忽略的是：闭包不是你要“主动创建”的东西，而是你写嵌套函数 + 外部调用 + 访问外部变量时，JS 自动给你打包好的“环境快照”。你控制不了它的存在，只能控制它捕获什么、留多久、传给谁。
