闭包是JavaScript作用域机制的自然结果，需同时满足：外部函数执行完毕、内部函数被持有、内部函数访问外部变量；它用于模拟私有变量、修复循环事件绑定bug、实现函数工厂，但滥用易致内存泄漏或变量共享问题。
闭包不是语法糖，而是 JavaScript 作用域机制的自然结果——只要内部函数引用了外部函数的变量，并被返回或传出，闭包就自动形成了。
怎么一眼识别闭包？看三个硬条件
闭包不是“写出来的”，是“跑出来的”。满足以下三点，JavaScript 引擎就会为你保留词法环境：
- 外部函数已执行完毕（比如
outer()调用结束） - 内部函数仍被某个变量持有（比如
const fn = outer();） - 该内部函数体内访问了外部函数的局部变量（比如读/写
count）
缺一不可。只定义不返回、返回但没引用外部变量、引用了但外部函数还没退出——都不算真正形成闭包。
为什么不用闭包，很多事根本做不了
闭包解决的是 JavaScript 缺失原生私有机制带来的实际问题，不是炫技：
-
模拟私有变量：比如
createCounter()返回的对象里，privateCount只能通过increment()和getCount()访问，外部连counter.privateCount都不存在 -
修复循环绑定事件的 bug：for 循环中用
var i绑定 click 回调，最后全输出 10；用闭包（如 IIFE 或let块级作用域）就能让每个回调记住自己的i -
函数工厂：比如
makeAdder(5)返回一个“加 5 函数”，makeAdder(10)返回“加 10 函数”，它们各自封闭着不同的base值
闭包最常踩的两个坑
闭包本身没问题，滥用或误用才出事：
- 内存泄漏风险：闭包会阻止垃圾回收器释放它捕获的所有变量。如果一个闭包长期存活（比如挂到全局对象、DOM 元素上），而它又意外持有了大数组、DOM 节点或整个对象树，内存就悄悄涨起来了
- 变量被意外共享：多个闭包如果共用同一个外部变量（比如在循环中没正确隔离），修改一个会影响所有——典型表现是“所有按钮点击都触发最后一个 ID”
规避方法很简单：不用时主动解除引用（fn = null），循环中优先用 let 或显式传参封装，避免依赖外部函数作用域里的可变状态。
真正难的不是写出闭包，而是判断“这个变量值，到底该由谁负责生命周期”。一旦搞错，bug 就藏得深、复现难、排查久。
