JavaScript作用域链是什么？如何影响变量查找？

JavaScript作用域链是引擎在变量查找时动态构建的一条单向、线性、自下而上的引用路径，由函数定义时的词法位置决定，而非调用位置；它通过[[Environment]]链接各级词法环境，逐层向上查找直到全局，找到即止，不跨层也不跨兄弟作用域——理解它，就掌握了闭包如何“记住”外层变量、var/let/const为何查找行为一致却报错时机不同、以及那些看似诡异的变量覆盖与共享问题背后的真正原因。

作用域链是什么？它不是作用域的“链条”，而是查找路径

作用域链（scope chain）是 JavaScript 引擎在执行函数时，为变量查找构建的一条**从当前执行上下文向上逐级回溯的引用链**。它不是静态定义的语法结构，而是在函数被调用时动态生成的——由当前函数的 [[Environment]] 内部槽位指向其词法外层环境，再指向外层的外层，直到全局环境为止。

关键点在于：它只跟**函数定义时的位置**有关（词法作用域），跟函数在哪里被调用无关。哪怕把一个函数作为参数传到另一个文件里执行，它的作用域链起点仍是它原本定义时所处的词法环境。

变量查找怎么走这条链？从左到右，找到即停

当访问一个变量（比如 foo）时，JavaScript 引擎会按以下顺序查找：

• 先查当前执行上下文的**词法环境（LexicalEnvironment）**，也就是当前函数自己的 [[Environment]]
• 没找到，就顺着 [[Environment]] 指向的外层环境继续查（可能是外层函数的词法环境，也可能是全局环境）
• 一路向上，直到找到第一个匹配的绑定；如果全局都没找到，就抛出 ReferenceError: foo is not defined

注意：查找过程是单向、线性的，不会跳过某一层去下一层找，也不会“跨兄弟作用域”搜索。例如两个并列的 function，彼此的作用域互不可见。

var、let、const 在作用域链中表现一样吗？

查找行为一致——都走同一条作用域链；但**是否能被查到，取决于声明是否已初始化、是否处于暂时性死区（TDZ）**：

• var 声明会被提升（hoisted），且初始化为 undefined，所以在作用域链任何层级都能查到（即使还没执行到声明语句）
• let 和 const 也会被提升，但不初始化；从块级作用域开头到声明语句之间是 TDZ，此时访问会直接报 ReferenceError，而不是顺着链继续往上找
• 也就是说：作用域链没变，但“能不能读”受 TDZ 阻断

示例：

function outer() {
  let x = 10;
  function inner() {
    console.log(x); // ✅ 找到 outer 的 x
  }
  inner();
}

闭包是怎么靠作用域链“记住”外层变量的？

闭包的本质，就是内部函数的 [[Environment]] 持有对外层词法环境的引用。只要这个内部函数还存在（比如被返回、被赋值给全局变量），那它所依赖的外层变量就不会被垃圾回收——因为作用域链还在维持着对它们的强引用。

容易忽略的细节：

• 每次调用外层函数，都会创建**新的词法环境实例**；多个闭包可能共享同一份外层变量（如循环中未用 let 声明迭代变量），也可能各自持有独立副本（如用 let 或立即执行函数）
• 作用域链本身不存储变量值，只存对词法环境对象的引用；变量值实际存在那些环境记录（Environment Record）里
• Chrome DevTools 的 “Scope” 面板里看到的 “Closure” 条目，就是该函数当前的 [[Environment]] 所指向的那些外层环境

真正难调试的，往往不是链没连上，而是多个闭包意外共享了同一个环境记录——这时得盯住声明方式和调用时机。

理论要掌握，实操不能落！以上关于《JavaScript作用域链是什么？如何影响变量查找？》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！