变量提升是javascript引擎在编译阶段将var声明（仅声明）提升至当前函数作用域顶部并初始化为undefined的行为，导致变量遮蔽、undefined陷阱及块级作用域失效等核心副作用。
变量提升（Hoisting）不是“代码被移动”，而是 JavaScript 引擎在编译阶段对声明的预处理行为：它把 var 声明（仅声明，不含赋值）提前到当前作用域顶部，并初始化为 undefined。这种机制本身不难，但和函数作用域叠加后，容易引发遮蔽、未预期的 undefined 和逻辑断裂——这才是 var 带来的核心副作用。
var 声明会悄悄创建局部变量，覆盖外层同名变量
只要函数体内出现 var x，无论写在哪儿，整个函数内所有对 x 的访问都指向这个新声明的局部变量，哪怕它出现在 console.log(x) 后面。
- 外部
var x = 100在函数内部完全不可见 -
console.log(x)不报错，但输出undefined（因为局部x已声明但未赋值） - 这是“变量遮蔽”（shadowing），不是错误，但极易被误读为“读取了外部值”
声明与赋值分离，导致执行顺序失真
代码看起来是“先用再定义”，实际运行时却像“先声明后使用”，中间夹着一个隐式的 undefined 状态。
- 写
console.log(a); var a = 42;，等价于var a; console.log(a); a = 42; - 如果依赖
a的初始值做判断（比如if (a === undefined)），结果可能不符合直觉 - 循环或条件分支中重复声明
var不会报错，但会强化这种隐蔽性
函数作用域让问题扩散，块级逻辑失效
var 没有块级作用域，if 或 for 内声明的变量会泄露到整个函数顶层。
for (var i = 0; i 结束后，<code>i仍可访问，值为3- 多个
for共用同一个i，容易相互干扰 - 看似独立的逻辑块，实际共享变量，增加维护成本
对比 let/const 就更清楚问题所在
let 和 const 虽也“提升”，但进入“暂时性死区”（TDZ）：在声明前访问直接报 ReferenceError，强制开发者按顺序组织代码。
- 报错比静默返回
undefined更安全——它暴露问题，而不是掩盖问题 - 块级作用域让
if、for内的变量真正局限在块内 - 没有遮蔽陷阱：内层
let x不会影响外层同名变量的可访问性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
