闭包变量查找性能成本源于作用域链逐级遍历，而非执行栈；作用域链在函数定义时静态确定，长度决定查找步数，闭包主要带来内存压力而非运行时查找开销。
函数执行栈和作用域链是两个不同但紧密关联的机制，闭包查找变量时的性能成本，主要来自作用域链的逐级遍历，而非执行栈本身。执行栈只负责管理函数调用顺序（后进先出），不参与变量查找；真正影响查找速度的是作用域链的长度和结构。
作用域链决定变量查找路径
每次访问一个变量，JavaScript 引擎会从当前函数的词法环境开始，沿着 [[Environment]] 链向上查找，直到全局环境。这个链就是作用域链，它在函数定义时就已静态确定，与调用位置无关。
- 链越长（嵌套层级越深），查找所需步数越多，最坏情况需遍历全部父级作用域
- 变量名冲突或重复声明不会加速查找，反而可能增加比对开销
- 使用 let/const 声明的变量会创建块级词法环境，可能使作用域链更细碎，但现代引擎（如 V8）已做优化，实际影响有限
闭包让变量“驻留”在堆中，不等于持续查找
闭包本身不带来运行时查找开销，它的代价发生在创建阶段：内部函数会隐式持有对外部词法环境的引用，导致这些变量无法被垃圾回收。真正有成本的是后续每次访问该变量时，引擎仍需沿作用域链定位——但这个过程和普通嵌套函数访问并无区别。
- 闭包不会让查找变慢，但它让本该销毁的变量长期存活，间接增加内存压力
- 如果闭包内频繁读写外部变量（如计数器、缓存对象），V8 可能将其优化为快速属性访问，前提是变量未被动态删除或重新赋值为不同类型
- 避免在循环中无节制地创建闭包（如
for (let i = 0; i i; }），这会生成大量独立词法环境实例
执行栈不参与变量查找，但影响作用域链构建时机
执行栈记录的是函数调用的实时状态，而作用域链在函数创建（即定义）时就已固化。当函数被调用，引擎基于其 [[Environment]] 创建新的执行上下文，并把当前词法环境链设为作用域链——这个动作是瞬时的，不随栈深度线性增长。
- 10 层递归调用，和 10 层嵌套定义的函数，对变量查找性能的影响完全不同：前者栈深但作用域链可能很短；后者链长但栈可能只有 1 层
- 常见误区：认为“栈越深 → 查找越慢”。其实栈深只影响调用开销和内存占用，变量查找快慢只看作用域链节点数
- 可通过 Chrome DevTools 的 Performance 面板录制脚本，观察
Function Call和Script Evaluation阶段耗时，辅助判断是否真由作用域链引起瓶颈
不复杂但容易忽略：多数场景下，作用域链查找的性能差异微乎其微；真正值得警惕的是因闭包导致的内存泄漏或意外的变量保留。
