变量提升会打乱代码线性阅读节奏，造成声明与赋值错位、形成“先用后定义”假象；函数声明优先提升掩盖作用域意图；let/const 的 TDZ 强制声明前置；现代开发应统一用 let/const 替代 var，函数优先用表达式，声明集中顶部并启用严格模式。
变量提升会打乱代码的线性阅读节奏，让声明和赋值在物理位置上分离，容易让人误判变量状态。它不改变执行结果，但显著干扰对逻辑顺序的理解。
变量声明与赋值错位，造成“先用后定义”的假象
使用 var 时，声明被提升，赋值留在原处。比如：
console.log(name); // undefined var name = "Alice";
表面看是“未声明就访问”，实际是“已声明未赋值”。这种错位会让新人以为 JavaScript 支持任意顺序调用，也掩盖了真实初始化时机。
- 阅读时需 mentally 拆解为“声明提前 + 赋值滞后”，增加认知负担
- 团队协作中，若有人依赖这种写法，其他人可能误以为变量已在上方初始化完毕
- 重构时容易遗漏隐式声明，比如把
var x = 1拆成var x;和x = 1两行，语义不变但可读性下降
函数声明优先提升，掩盖作用域意图
函数声明（function foo() {...}）整体会被提升，且优先级高于同名 var 声明。例如：
立即学习“Java免费学习笔记（深入）”；
foo(); // 正常输出 "I'm hoisted"
var foo = "not a function";
function foo() { console.log("I'm hoisted"); }
这里 foo 先作为函数被提升，之后又被字符串赋值覆盖。代码从上到下读，却要倒着理解执行顺序。
- 函数定义出现在底部，但行为像在顶部——破坏“自上而下”的阅读直觉
- 若混用函数声明与函数表达式（
var bar = function() {...}），后者只提升var bar，不提升函数体，行为不一致 - 模块内部多个同名函数时，最终生效的是最后一个声明，但提升阶段已覆盖前序定义，调试时难追溯
let/const 引入暂时性死区（TDZ），强制声明前置
let 和 const 不提升声明，而是在声明前的区域形成 TDZ。访问会直接报 ReferenceError：
console.log(age); // ReferenceError let age = 25;
这种“不妥协”的设计倒逼开发者把声明放在使用之前。
- 阅读代码时，变量首次出现即代表其生命周期起点，无需回溯查找声明
- 配合块级作用域，能清晰表达变量的有效范围（如
if块内声明，外部不可见） - ESLint 等工具可自然捕获未声明使用，规范编写不再依赖人工约定
规范编写应主动规避提升带来的歧义
现代项目中，变量提升不再是必须适应的特性，而是可规避的设计包袱。
- 统一用 let / const 替代 var，消除声明与赋值分离问题
- 函数尽量用表达式形式（
const handler = () => {...}），避免声明提升带来的调用时机困惑 - 即使使用 var（如兼容旧环境），也坚持在作用域顶部集中声明，保持视觉与逻辑一致
- 启用
"use strict"，禁用隐式全局变量，减少因提升引发的意外污染
