闭包会延长作用域链，导致跨作用域变量访问变慢；每层嵌套增加查找开销，高频访问时形成性能瓶颈；应缓存外部变量、拆分嵌套逻辑、主动清理引用以优化。
闭包本身不会让作用域查找变慢，但会延长作用域链长度，而变量在作用域链中位置越深，访问就越慢。
作用域链变长直接影响查找速度
每个闭包函数在创建时，其内部的 [[Scope]] 属性会完整保存外部函数的作用域对象（包括变量对象、外层作用域等）。当闭包执行时，运行期上下文的作用域链就基于这个 [[Scope]] 初始化。这意味着：如果闭包嵌套多层（比如三层函数嵌套），每次访问一个未声明在当前函数内的变量，引擎就要逐级向上搜索——先查当前局部作用域，再查外层函数作用域，再查更外层，最后才到全局。
这种“逐层跳转”的开销虽小，但在高频调用或循环中反复访问跨作用域变量时，会明显累积成性能瓶颈。
变量不在当前作用域时，访问成本显著上升
JavaScript 引擎对变量的读取效率排序通常是：
立即学习“Java免费学习笔记（深入）”；
- 局部变量（最快）：直接从当前激活对象（AO）或词法环境记录中读取
- 参数/函数名：同属当前作用域，开销接近局部变量
- 闭包捕获的外部变量：需沿作用域链向上查找，可能跨多个环境记录
- 全局变量（最慢）：总在作用域链末端，必须遍历全部中间层级
例如，在一个深度为 3 的闭包中读取最外层的 config 变量，引擎平均要检查 3 个作用域对象才能命中，而换成局部缓存后，就是单次直接访问。
避免隐式长链：不是所有闭包都“轻量”
闭包保留的是整个词法环境，而非仅被引用的变量。即使内部函数只用了 id，它仍会持有对外部函数全部局部变量（如 data、cacheMap、logger）的引用，导致这些变量无法被垃圾回收，也使作用域链维持冗长结构。
常见高风险写法：
- 在 for 循环中为每个迭代项生成闭包（如绑定事件处理器），且闭包引用了大数组或 DOM 节点
- 返回的闭包持续存在（如长期驻留的计时器回调），却未清理无关引用
- 模块工厂函数返回多个方法，每个方法都独立捕获同一组大型外部变量
优化方向：缓存 + 解耦 + 清理
核心思路是缩短实际参与查找的链路，并减少不必要的环境绑定：
- 提前缓存跨层变量：把频繁访问的外部值赋给局部变量，后续全部使用该局部变量
- 拆分逻辑，避免深层嵌套：将本可提取为独立函数的闭包内操作移出，改用参数传入必要数据
-
主动解除引用：闭包不再需要某大型对象时，手动设为
null，帮助 GC 回收对应作用域对象 - 用 WeakMap 管理私有状态：替代闭包持有时，既保持封装性，又不阻止目标对象被回收
