闭包是函数与其词法作用域的组合，执行上下文是运行时环境容器；闭包依赖变量引用而非上下文存活，其存在不以执行上下文销毁为终止，关键在词法作用域与引用保持。
闭包和执行上下文常被混为一谈，但它们本质不同：闭包是函数与其词法作用域的组合，而执行上下文是代码运行时的环境容器。真正容易出错的地方，不是“闭包怎么形成”，而是误以为闭包能脱离执行上下文独立存在，或混淆了变量生命周期与上下文销毁的关系。
误区一：认为闭包能“保存”已销毁的执行上下文
执行上下文（尤其是函数执行上下文）在函数返回后通常被销毁，但闭包保留的是对**词法作用域中变量的引用**，不是对上下文对象本身的持有。JS引擎通过垃圾回收机制判断变量是否可达——只要闭包还引用着某个变量，该变量就不会被回收，哪怕创建它的执行上下文早已退出。
- 函数返回后，其执行上下文被弹出调用栈，但其中的词法环境（LexicalEnvironment）若被外部函数闭包引用，其绑定的对象（如 AO/VO）仍保留在内存中
- 常见误判：看到 console.log 输出旧值，就以为“上下文还在”，其实是变量仍在内存中被引用
- 验证方式：在闭包内修改变量，再在外部检查，能反映同一内存地址——说明不是拷贝，而是引用
误区二：把闭包等同于“内部函数”，忽略词法作用域的静态性
闭包的关键不在“函数嵌套”，而在函数定义时所处的词法作用域是否被外部保留。即使内部函数被赋值给全局变量、传入 setTimeout 或作为回调返回，只要它访问了外层函数的变量，就构成闭包。
- 以下不是闭包：内部函数未引用任何外层变量（即使嵌套）
- 以下仍是闭包：函数在定义后被移出原作用域（如 return 出去、挂到 window），但依然访问外层变量
- 陷阱示例：循环中用 var 声明 i，setTimeout 里访问 i —— 所有回调共享同一个 i 变量，不是因为“闭包失效”，而是因为闭包捕获的是变量本身，而非每次迭代的值
误区三：认为“执行上下文销毁 = 闭包失效”
执行上下文销毁不等于闭包失效。闭包的生命取决于**是否还有活跃引用**。只要闭包函数本身还存活（比如被赋值给某个变量、在事件监听器中、在定时器回调队列里），它所捕获的变量就会持续存在。
立即学习“Java免费学习笔记（深入）”；
- 典型反例：为 DOM 元素绑定事件处理函数，该函数是闭包，即使创建它的函数早已执行完毕，只要元素没被移除、监听器没被 removeEventListener，闭包就一直有效
- 内存泄漏风险正源于此：意外保留闭包（如全局变量引用、未清理的事件监听器），导致本应释放的外层变量长期驻留
- 调试建议：用 Chrome DevTools 的 Memory 面板录制堆快照，筛选 Closure 类型对象，查看哪些变量被意外持有
误区四：混淆 this 绑定与闭包作用域
this 是运行时动态绑定的，属于执行上下文的一部分；而闭包捕获的是词法作用域中的标识符（如 let/const/var 声明的变量）。两者无直接关系，但在箭头函数中容易产生错觉——箭头函数没有自己的 this，会沿词法作用域向上找，看起来像“闭包式继承”，实则是 this 绑定规则使然。
- 普通函数中：this 指向由调用方式决定，与闭包无关
- 箭头函数中：没有 this，所以访问的是外层函数的 this，这属于词法绑定，不是闭包“捕获 this”
- 错误写法示例：用 bind(this) 包裹一个闭包函数，以为在加固闭包——其实只是固定了 this，对变量捕获毫无影响
理解闭包，核心是盯住“词法作用域 + 引用保持”；理解执行上下文，关键是分清“调用时的环境容器”和“定义时的作用域链”。二者协同工作，但不可互相替代或覆盖。不复杂但容易忽略。
