JavaScript变量声明与作用域解析

JavaScript变量声明远不止语法选择那么简单——let、const与var在作用域、提升机制、全局挂载和执行上下文中的行为差异深刻影响着代码的可靠性与可维护性：TDZ让未初始化访问直接报错，块级作用域杜绝重复声明却要求精准时机，var的函数提升和块内泄漏则埋下闭包陷阱；而模块默认严格模式、eval的上下文依赖、globalThis的属性挂载差异，更揭示出作用域边界实为多重运行时条件共同塑造的结果——选错声明方式，轻则逻辑诡异，重则异步回调失序、模块封装失效、沙箱逃逸。

JavaScript 变量声明不是“选一个就行”，而是必须根据行为需求选对关键字；作用域规则不只影响变量能否访问，更直接决定闭包、异步回调、模块封装是否可靠。

let 和 const 声明后为什么不能重复声明同名变量？

因为 let 和 const 具有“暂时性死区”（TDZ）和块级作用域限制，引擎在进入块作用域时就登记了声明，但直到执行到声明语句前都不可访问——这和 var 的变量提升（hoisting）完全不同。

• let x = 1; let x = 2; → 报错 SyntaxError: Identifier 'x' has already been declared
• var x = 1; var x = 2; → 合法，后者覆盖前者（无报错）
• console.log(y); let y = 3; → 报错 ReferenceError: Cannot access 'y' before initialization（TDZ 典型表现）
• 函数参数也受 TDZ 影响：function f(x = x) { } 会报错，因为默认值表达式中右侧的 x 尚未初始化

var 声明为何会在 if 块内泄漏到外层函数？

var 只有函数作用域，没有块作用域。哪怕写在 if、for 或 {} 里，也会被提升到最近的函数顶部（或全局作用域）。

• if (true) { var a = 1; } console.log(a); → 输出 1（不是 ReferenceError）
• for (var i = 0; i → 输出 3（循环变量泄露）
• 这种泄漏是 var 最易被误用的点，在闭包循环中尤其危险（比如给多个按钮绑事件，最后全指向最后一个 i 值）
• 现代写法应改用 let i：每次迭代都会创建新绑定，自然解决闭包问题

顶层 this 指向 globalThis，但 var 声明的变量却不会成为 globalThis 的属性？

这是历史遗留差异：var 在全局作用域声明会自动挂载为全局对象（window / global / globalThis）的可枚举属性；而 let、const、class、function 声明则不会。

• var foo = 'bar'; console.log(globalThis.foo); → 'bar'
• let bar = 'baz'; console.log(globalThis.bar); → undefined
• 这个差异会影响依赖 globalThis 动态访问变量的场景（如插件系统、沙箱环境），不能假设所有顶层声明都可被 globalThis[key] 读取
• ES6 模块的顶层声明（包括 import 绑定）也完全不挂载到全局对象，和 let/const 行为一致

模块作用域和 eval 中的声明行为有何不同？

模块文件（.mjs 或 type="module" 的脚本）自带独立作用域；而 eval() 默认继承调用者作用域，除非显式传入 'use strict' —— 此时 eval 内部的 var 也不会泄漏到外层。

• eval('var x = 1'); console.log(x); → 1（非严格模式下）
• eval('"use strict"; var y = 2'); console.log(y); → ReferenceError（严格模式下 eval 有独立作用域）
• 模块中即使不写 "use strict"，也默认启用严格模式，且所有声明都限定在该模块内
• import 和 export 只能在模块顶层使用，不能在 if 或函数内动态出现，否则语法错误

真正容易被忽略的是：作用域边界不仅由关键字决定，还受执行上下文类型（模块/脚本/eval）、严格模式开关、以及是否在函数内嵌套影响。同一个 let 声明，在模块顶层和 IIFE 内部的表现一致，但在 eval 里可能因严格模式开关而行为突变。

今天关于《JavaScript变量声明与作用域解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！