词法作用域如何影响JS变量访问？

各位小伙伴们，大家好呀！看看今天我又给各位带来了什么文章？本文标题是《词法作用域如何影响JS变量访问？》，很明显是关于文章的文章哈哈哈，其中内容主要会涉及到等等，如果能帮到你，觉得很不错的话，欢迎各位多多点评和分享！

JavaScript词法作用域在函数定义时即确定，与调用位置无关；自由变量按源码嵌套结构向上查找；闭包通过[[Environment]]保持对外层变量的引用；var/let/const均遵循词法作用域但提升和TDZ行为不同；箭头函数无this但继承外层词法作用域。

词法作用域在函数定义时就确定了

JavaScript 的词法作用域（Lexical Scope）不是运行时动态决定的，而是在代码写完、函数被定义的那一刻就固定下来。这意味着 function 内部能访问哪些变量，只取决于它在源码中所处的位置，和它在哪里被调用完全无关。

常见错误现象：把闭包返回的函数在别处调用，误以为它会捕获调用时所在作用域的变量。实际上它只认自己定义时外层的那些变量。

• function 体内的自由变量（即未在本函数中声明的变量）会沿代码嵌套层级向上查找，直到全局作用域
• 查找过程不看调用栈，只看函数在源文件中的嵌套结构
• eval 和 with 会破坏词法作用域静态性，应避免使用

嵌套函数如何通过词法作用域“记住”外层变量

这是闭包的核心机制。内层函数即使在外部作用域已经执行结束之后仍能访问其词法环境中的变量，因为 JS 引擎保留了该函数定义时的 [[Environment]] 内部属性。

使用场景：封装私有状态、工厂函数、事件处理器绑定固定参数等。

function createCounter() {
  let count = 0;
  return function() {
    count++;
    return count;
  };
}

const inc = createCounter();
console.log(inc()); // 1
console.log(inc()); // 2
// count 没有被释放，因为 inc 的 [[Environment]] 仍引用着 createCounter 的词法环境

var / let / const 对词法作用域的影响差异

三者都遵循词法作用域，但变量提升和暂时性死区（TDZ）行为不同，直接影响你在作用域内何时能安全访问变量。

• var 声明会被提升到函数作用域顶部，初始化为 undefined；在声明前访问不会报错，但值是 undefined
• let 和 const 也会被提升，但处于 TDZ —— 在声明语句执行前访问会抛出 ReferenceError
• 块级作用域（{}）对 let/const 有效，对 var 无效；这会影响你在 if 或 for 块中定义的变量是否泄漏到外层

容易被忽略的细节：箭头函数没有自己的 this，但词法作用域照常生效

箭头函数不绑定 this、arguments、super 或 new.target，但它依然严格遵循词法作用域规则查找其他变量 —— 包括普通变量、函数名、甚至外层的 this 值（因为 this 在箭头函数里是词法继承的）。

性能影响：箭头函数本身不创建新的词法环境对象，复用外层的 [[Environment]]，内存开销略小；但若滥用嵌套箭头函数，可能延长外层变量的生命周期，延迟垃圾回收。

function foo() {
  const x = 10;
  return () => {
    console.log(x); // ✅ 正常访问，x 来自 foo 的词法环境
    console.log(this); // ✅ this 也来自 foo 调用时的上下文
  };
}

真正复杂的地方在于：词法作用域是静态的，但变量值是动态的。同一个闭包多次执行，访问的是同一份词法环境里的变量，而这些变量的值可能已被多次修改 —— 这正是循环中生成多个闭包却共享同一个 var i 的根源。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~