变量提升使var声明的变量在声明前可访问但值为undefined；function声明完全提升，let/const仅声明提升且处于TDZ；var无块级作用域，let/const有；应优先使用let/const。
变量提升让 var 声明的变量在声明前可访问但值为 undefined
JavaScript 在执行前会先进行「预解析」，把所有 var 声明（不包括赋值）和 function 声明提升到当前作用域顶部。这意味着你能在声明语句之前读取变量，但它的值还没被赋上：
console.log(a); // undefined var a = 1;
这和 let/const 完全不同——它们虽也会被「声明提升」，但处于「暂时性死区（TDZ）」，在声明前访问会直接抛出 ReferenceError。
-
var提升的是「声明 + 初始化为undefined」 -
let/const只提升「声明」，不初始化，访问即报错 - 函数声明（
function foo() {}）会被完全提升，包括函数体；函数表达式（var foo = function() {}）则按var规则处理
作用域链决定变量查找路径，不是从最近的块级作用域开始，而是沿词法作用域向上找
作用域链在函数定义时就已确定，跟函数在哪调用无关。它由「内部函数能访问外部函数变量」这一机制支撑，本质是每个执行上下文的 [[Scope]] 链表。
常见误解是认为 {} 块会创建新作用域——对 var 来说完全不成立：
立即学习“Java免费学习笔记（深入）”；
if (true) {
var x = 1;
}
console.log(x); // 1 —— x 泄露到外层函数/全局作用域
而 let/const 在块内声明，确实形成块级作用域，不会泄露。
- 函数作用域（
var） vs 块级作用域（let/const）影响变量可见范围 - 闭包捕获的是「变量的引用」，不是值；如果循环中用
var声明计数器并创建多个函数，它们共享同一个i变量 - 箭头函数不创建自己的
this或arguments，但作用域链规则不变：仍沿外层函数词法作用域查找变量
var + 函数作用域 + 提升组合，容易导致意外交互和调试困难
三者叠加会让代码行为偏离直觉，尤其在条件分支、循环或嵌套函数中：
function foo() { console.log(a); // undefined if (false) { var a = 2; } } foo();
ction foo() {
console.log(a); // undefined
if (false) {
var a = 2;
}
}
foo();上面的 var a 仍被提升，所以 console.log(a) 不报错，但输出 undefined。这种「声明存在但逻辑未执行」的状态很难通过阅读代码发现。
- 同一作用域内重复
var声明会被忽略，不会报错，但可能掩盖拼写错误 - 全局下用
var声明，会成为window（浏览器）或global（Node.js）的可枚举属性；而let/const不会 - 模块脚本（
type="module"）默认启用严格模式，且顶层声明不挂载到window，进一步削弱var的「全局污染」能力
现代代码应优先用 let/const，仅在需函数作用域或明确兼容旧环境时才考虑 var
变量提升本身不是 bug，但 var 的宽松规则让错误更隐蔽。ES6 后，绝大多数场景已无需 var：
- 用
const声明不重新赋值的变量（推荐默认使用） - 用
let声明需重新赋值、且作用域应限制在块内的变量（如for循环计数器） - 避免在函数内混用
var和let，防止因提升差异引发意外覆盖 -
工具如 ESLint 可配置
no-var规则强制禁用var，提前拦截问题
真正难调试的，往往不是提升本身，而是提升与作用域边界的错位——比如以为 if 块封住了变量，结果 var 让它跑到了函数顶部。这种隐式行为，在多人协作或重构时最容易暴露。
