作用域链形成原理全解析

欢迎各位小伙伴来到golang学习网，相聚于此都是缘哈哈哈！今天我给大家带来《作用域链形成原理详解》，这篇文章主要讲到等等知识，如果你对文章相关的知识非常感兴趣或者正在自学，都可以关注我，我会持续更新相关文章！当然，有什么建议也欢迎在评论留言提出！一起学习！

作用域链在函数创建时就确定了，通过[[Environment]]静态绑定外层词法环境；with和非严格eval会动态插入环境；闭包捕获整个词法环境而非变量值；模块、函数、块级作用域对应不同环境类型。

作用域链在函数创建时就确定了

JavaScript 的作用域链不是在函数调用时临时拼出来的，而是在函数对象被创建（即执行 function 声明或表达式）的那一刻，就通过其内部属性 [[Environment]] 绑定了外层词法环境。这个绑定是静态的、不可变的——哪怕后续外层变量被重新赋值，甚至函数被移到完全不同的作用域中调用，它依然沿用创建时的那条链。

常见误解是“调用时才找父作用域”，结果写出类似下面的代码却得不到预期结果：

function makeAdder(x) {
  return function(y) { return x + y; };
}
const add5 = makeAdder(5);
// 此时 add5.[[Environment]] 已固定指向 makeAdder 调用时创建的那个 LexicalEnvironment
// 即使之后把 add5 赋给全局变量、传入 setTimeout，链也不变

with 和 eval 会动态污染作用域链

绝大多数情况下作用域链是静态的，但有两个例外： with 语句和非严格模式下的直接 eval。它们会在运行时把新环境插入到当前作用域链头部，导致变量查找顺序临时改变，且无法被静态分析工具预测。

• with 会将传入对象的属性视为当前作用域的变量，实际开发中应完全避免
• 非严格模式下，eval('var a = 1') 会在当前作用域声明变量；严格模式下 eval 总是新建独立作用域，不影响外层链
• V8 等引擎对含 with 或非严格 eval 的函数会禁用某些优化（如内联缓存），性能明显下降

闭包捕获的是整个词法环境，不是单个变量值

闭包保留的不是某个变量的快照，而是对整个外层 LexicalEnvironment 的引用。这意味着多个闭包共享同一份环境记录，修改其中一个闭包可见的变量，其他闭包也能感知到：

function createCounter() {
  let count = 0;
  return [
    () => ++count,
    () => count
  ];
}
const [inc, get] = createCounter();
inc(); inc();
console.log(get()); // 输出 2 —— 因为两个函数共用同一个 { count: 2 } 环境记录

容易踩的坑：

• 在循环中用 var 声明变量并创建闭包，所有闭包都引用同一个变量绑定（ES5 常见 bug）
• 以为 const 或 let 声明能“冻结”值——其实只是禁止重新赋值，环境记录本身仍是可变的
• 试图用 JSON.stringify 序列化闭包来“保存状态”，结果发现闭包无法序列化

模块顶层、函数顶层、块级作用域对应不同环境类型

作用域链的“底端”不总是全局对象。具体取决于代码所处的上下文：

• 模块脚本（type="module"）顶层：绑定到 ModuleEnvironment，没有 this 指向全局，var 不挂载到 globalThis
• 函数内部：使用 FunctionEnvironment，包含参数、arguments、内部声明等
• if/for 块内（let/const）：生成 BlockEnvironment，仅用于块级声明，生命周期与执行流严格对应

这些差异直接影响 typeof xxx、xxx in window、this 值等行为。比如在模块中 var a = 1 不会让 a 出现在 window.a 上，但 function f(){} 仍会作为属性添加到模块环境记录中——不是全局对象。

真正难调试的，往往是跨环境类型混用时的隐式查找失败，比如在模块中误以为 var 声明会暴露给全局，或者在 eval 中期望访问外层 const 变量却因严格模式限制而报 ReferenceError。

理论要掌握，实操不能落！以上关于《作用域链形成原理全解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！