本文深入解析 `var` 提升（hoisting）机制为何在同页面不同 `
在 JavaScript 中，var 声明确实会被“提升”（hoisting）——即变量声明会被移动到其所在作用域的顶部，但仅限于当前作用域内。关键点在于：每个 ，它们之间不共享变量声明，即使位于同一 HTML 页面中。
为什么跨
看这个例子：
虽然 var x 在第二段脚本中声明，但第一段脚本完全不知道它的存在——因为 var x 的提升只发生在它所在的
✅ undefined 出现在“已声明但未初始化”的情况； ❌ ReferenceError 出现在“根本未声明”的情况。
为什么同个
这是因为 var x 的声明被提升到了该
var x; // 提升：声明存在，值为 undefined console.log(x); // → undefined x = 10; // 初始化：此时才赋值
这就是典型的 var 提升行为：声明提升 + 初始化不提升。
let 和 const 的行为更严格（推荐使用）
现代 JavaScript 推荐用 let 和 const 替代 var，它们也存在“提升”，但处于暂时性死区（Temporal Dead Zone, TDZ）：在声明语句执行前访问变量，会直接抛出 ReferenceError，而非返回 undefined。
TDZ 的设计初衷正是为了暴露潜在错误，避免 var 那种静默返回 undefined 导致的隐蔽逻辑 bug。
补充说明：能否让后定义的变量被前置脚本访问？
常规
⚠️ 实际上，上述模块脚本依然无法访问第二个 ，因为模块拥有自己的顶级作用域，不继承传统
总结与最佳实践
- ✅ var 提升仅限单个 标签不共享声明；
- ✅ console.log(x) 报 ReferenceError → x 未声明；输出 undefined → x 已声明但未初始化；
- ✅ 优先使用 const / let：更安全、语义清晰、避免 TDZ 外的意外行为；
- ✅ 避免依赖提升编写逻辑；始终遵循“先声明，后使用”原则；
- ✅ 大型项目建议采用 ES 模块（type="module"）+ 显式导入导出，实现可控的变量共享与作用域管理。
理解作用域边界与提升机制，是写出健壮、可维护 JavaScript 代码的基础。
