javascript变量提升本质是声明在编译阶段进入作用域而赋值不变；var声明提升并初始化为undefined，let/const存在暂时性死区（tdz）致referenceerror；函数声明完全提升，表达式仅声明提升；推荐用const/let、就近声明、禁用var以规避隐患。
JavaScript变量提升不是代码被“移动”了，而是声明在编译阶段就被放入作用域中——赋值始终留在原地。理解它，是为了预判变量何时可读、为何报错、以及为什么var和let行为截然不同。
var声明为什么会输出undefined而不是报错？
因为var的声明和初始化是分离的：声明被提升到函数或全局作用域顶部，并自动初始化为undefined；赋值语句仍保留在原位置。
- 常见错误现象：
console.log(a); // undefined var a = 10;
你以为会报错，实际却静默返回undefined，容易掩盖逻辑漏洞（比如if (a === undefined)意外成立） - 函数内同名变量更危险：
var name = "全局"; function test() { console.log(name); // undefined —— 不是"全局" var name = "局部"; } test();函数作用域内的var name被提升，覆盖了外部变量，但尚未赋值 - 性能/兼容性影响：现代引擎已高度优化，无需担心开销；但IE8–IE9仅支持
var提升，let/const需转译
let/const的“暂时性死区”（TDZ）到底在防什么？
let和const的声明确实也被提升，但引擎会在块级作用域开头到声明语句之间划出一段“不可访问区域”，即暂时性死区。访问即抛ReferenceError，而非返回undefined。
- 使用场景：强制先声明后使用，避免因提升导致的意外绑定（尤其在
for循环闭包中） - 容易踩的坑：
console.log(typeof b); // ReferenceError let b = 42;
typeof在TDZ里也不安全，不能靠它“兜底”检测变量是否存在 - 参数差异：TDZ只存在于
let/const声明的块级作用域内；var没有TDZ，且不绑定块级作用域
函数声明 vs 函数表达式：为什么一个能提前调用，一个不行？
函数声明（function foo() {}）会被完全提升——函数名和函数体都可用；而函数表达式（const foo = function() {}）只按变量规则处理，仅变量声明被提升，赋值仍原地执行。
立即学习“Java免费学习笔记（深入）”；
- 常见错误现象：
bar(); // TypeError: bar is not a function var bar = function() { console.log('no'); };因为bar被提升为undefined，不是函数 - 函数优先级陷阱：
console.log(foo); // function foo() {} function foo() {} var foo = 'hello';函数声明覆盖了后续同名var声明，但若换成let foo，则直接报错（重复声明） - 注意：ES规范不鼓励在
if等条件块中写函数声明，不同浏览器行为不一致
如何写出不被提升机制拖累的可靠代码？
别依赖提升，从语言特性上切断隐患源头。
- 统一用
const代替var，需要重赋值时才用let——这能天然避开var的静默undefined和重复声明问题 - 声明尽量靠近首次使用位置，而不是堆在函数顶部（尤其对
let/const，堆在顶部反而增加TDZ范围） - 启用
ESLint规则：no-use-before-define捕获提前访问，no-var强制淘汰var - 函数定义优先用表达式：
const handleClick = () => { /* ... */ };语义清晰，行为可预测，也方便配合export和条件分支
最常被忽略的一点：提升不是语法糖，而是执行上下文创建阶段的真实行为。你看到的“顺序执行”，背后是两阶段（创建 + 执行）模型。写代码时若还下意识认为“上面没写就不存在”，那var和function仍会悄悄给你埋雷。
