现代JavaScript开发为何推荐弃用var改用let

一、作用域层级重塑：块级隔离代替函数泄漏

在 ES6 之前，JavaScript 仅有全局作用域与函数作用域，不存在块级作用域。使用 var 声明的变量，即便写在 if 条件判断分支、for 循环体或任意一对独立的花括号 {} 内，其作用域也会直接穿透这些代码块，向上挂载到外层函数（若无外层函数则挂载到全局环境）。

这种“穿透现象”导致变量生命周期失去精细控制。例如在同一函数内部的不同逻辑分支中，原本仅在特定代码块内临时使用的中间变量，会持续驻留并对外层其他代码可见，形成变量污染：

function processUserData(user, shouldFormat) {
  if (shouldFormat) {
    var formattedName = user.name.trim().toUpperCase();
  }
  // formattedName 泄漏到 if 代码块外部，未进入 if 分支时为 undefined
  console.log(formattedName); 
}

改用 let 后，变量的作用域被严格限制在声明它所在的代码块 {} 内部。一旦程序执行流程跳出该块，内部声明的 let 变量立即被销毁，任何在块外部的访问尝试都会直接触发 ReferenceError，从而在编码期杜绝意外的数据依赖。

二、提升机制与暂时性死区：消除隐式 undefined

JavaScript 引擎在执行代码时分为两个主要阶段：编译解析阶段与逐行执行阶段。在 var 的规则下，引擎在进入函数或全局上下文时，会将所有 var 声明提取到作用域顶部（即变量提升 Hoisting），并同时将其初始化为 undefined。

这意味着开发者在物理代码行声明 var 之前读取该变量，程序不仅不会抛出语法或引用异常，反而会静默返回 undefined。这种“假定安全”的行为隐藏了大量的书写顺序缺陷与逻辑漏洞：

console.log(timeoutMs); // 输出: undefined（执行期并不报错）
var timeoutMs = 5000;

而 let 彻底终结了这种宽容的静默错误机制。当引擎进入包含 let 声明的块级作用域时，虽然标识符在词法分析阶段已经被引擎识别，但它不会被初始化。从代码块开始到正式执行到 let 声明语句之间的这一物理与时间区间，被称为暂时性死区（Temporal Dead Zone，简称 TDZ）。

在 TDZ 内部任何尝试读取或写入该变量的操作，都会立即抛出 ReferenceError: Cannot access '...' before initialization。这强制推行了“先声明后使用”的确定性编程范式，确保了变量在使用时必定具备预期的明确状态。

三、循环迭代与异步闭包：告别共享变量陷阱

在传统 JavaScript 开发中，最臭名昭著的问题莫过于循环体内注册异步回调（例如定时器或 DOM 点击事件监听）。当使用 var 时，循环变量仅在外部作用域声明了一次，所有的闭包回调均引用同一个内存地址中的变量引用：

// 传统 var 陷阱
for (var i = 0; i < 3; i++) {
  setTimeout(function() {
    console.log("var index:", i); // 期望 0, 1, 2；实际输出三次 3
  }, 100);
}

在过去，为了修复这个缺陷，开发者不得不使用立即调用函数表达式（IIFE）人为构筑一层函数作用域来锁住当前的迭代变量值。这使得简单的迭代逻辑变得臃肿且难于理解。

根据 ECMAScript 规范定义，for (let i = 0; ...) 具有一种专门设计的词法行为：在每次迭代开始时，引擎都会为当前循环体创建一个崭新的块级词法环境，并将前一次迭代计算得到的最新值拷贝绑定到新的独立变量上。因此，每次迭代中生成的异步闭包自然捕获了属于当次迭代的私有值：

// 现代 let 原生正确处理
for (let i = 0; i < 3; i++) {
  setTimeout(() => {
    console.log("let index:", i); // 精确依次输出: 0, 1, 2
  }, 100);
}

四、重复声明与全局对象污染防御

除了作用域和提升机制，let 还从根本上修正了另外两项长期困扰开发者的历史遗留包袱：

• 禁止在同一作用域内重复声明：使用 var 时，重复声明同一变量是合法的，后声明的语句会静默覆盖先前的赋值。当多模块协作或较长函数维护时，很容易在不知情的情况下把同名变量覆盖掉。而在 let 规则下，同一作用域内的重复声明会在解析阶段直接触发 SyntaxError: Identifier '...' has already been declared，阻断潜在风险。
• 杜绝全局对象（window / globalThis）属性污染：在浏览器全局作用域下，使用 var foo = 'bar' 会自动将其作为可枚举属性挂载到 window 对象上（即 window.foo === 'bar'）。这极易无意覆盖浏览器的内置 API（例如全局声明 var name = "app" 会直接篡改 window.name 窗体属性）。而全局作用域下的 let 仅保存在全局词法环境中，绝不会成为 window 的属性。

五、从 var 到 let/const 的四步工程迁移流程

在大型遗留系统的现代化重构过程中，不能粗暴地对所有 var 执行全局盲目替换，而需要遵循兼顾语义分析与安全校验的标准化流程：

实施各步骤的关键注意点：

1. 步骤一（扫描定位）：配置 .eslintrc.json 中的 "no-var": "error"。利用 npx eslint --fix 可以自动替换掉大部分无语法争议的基础声明。
2. 步骤二（赋值判定）：不能简单将所有 var 全转为 let。业界共识的最佳实践是“默认使用 const，仅在确实需要变量重新绑定时使用 let”。这可以最大程度避免状态被意外篡改。
3. 步骤三（隐式依赖重构）：重点排查旧代码中是否有先使用后声明、或者利用 if 块内 var 泄漏给外层使用的逻辑。若有，必须显式将 let 提升至对应的父级代码块中声明，并按需赋初值。
4. 步骤四（测试与固化）：执行端到端或单元测试套件，在构建流程中配置 CI 门禁，确保后续提交的新代码不再引入任何 var 关键字。

六、现代声明选型矩阵与总结

在现代 JavaScript 规范及主流工程体系（TypeScript、React、Vue、Node.js 等）中，var 已经被全面判定为具有历史包袱的技术债。了解三种声明方式的核心差异有助于构建清晰、健壮的变量使用直觉：