JavaScript变量提升与块级作用域：从执行上下文到TDZ的深度解析

简介：这是一份面向JavaScript初学者的系统入门教程，适合零基础或有一定编程经验、希望深入理解JS核心机制的学习者。内容从语言背景与基本语法切入，覆盖变量声明中var、let、const的作用域差异，原始类型与引用类型的数据划分，以及算术、比较、逻辑、三元等运算符用法；进而讲解if...else、for、while等控制结构，函数的定义调用与一等公民特性，对象的键值对组织方式。DOM操作部分演示如何获取元素、修改内容与绑定事件监听，异步编程则围绕回调、Promise与async/await展开，帮助读者理解单线程模型下的并发处理思路。资源包共1个docx文件，约19KB，以图文与示例代码结合的方式编排，便于对照练习。已有88人学习，适合作为边看边敲的入门读物，配合文末推荐的学习资源与小项目实践，可逐步夯实语法基础并提升调试能力。

1. 变量提升与块级作用域：为什么var能“先用后声明”

先看一段让不少人第一次翻车的代码：在函数体顶部打印一个变量，控制台不报错，而是输出undefined；把var换成let，同样的位置直接抛ReferenceError。两行代码只差一个关键字，行为却像两种语言。这不是玄学，而是 JavaScript 引擎在进入执行上下文时，对声明做了两套完全不同的预处理。搞懂这套预处理，你才能理解为什么闭包里的循环变量总是取到最后一个值、为什么const声明的对象还能改属性、为什么暂时性死区（TDZ）不是语法糖而是运行时机制。这份 JavaScript 入门与核心功能详解把变量声明、数据类型、函数、对象、DOM 操作和异步编程串成一条线，而这条线的起点，就是声明在引擎里到底被怎么对待。下面从现象一路拆到执行上下文和词法环境，把“为什么能 work”讲透。

2. 执行上下文：声明在被执行之前经历了什么

2.1 从“创建阶段”和“执行阶段”两趟扫描说起

JavaScript 是解释型或即时编译型语言，但无论哪种实现，一段可执行代码在真正逐行跑之前，引擎都会先为它建立一个执行上下文。常见的实现思路是把一个执行上下文的生命周期拆成两个阶段：创建阶段和执行阶段。创建阶段做三件事——确定this的指向、创建词法环境、创建变量环境；执行阶段才逐条执行语句。变量提升之所以存在，就是因为创建阶段会扫描当前作用域内所有的声明，把函数声明整体放进环境，把var声明的变量名先登记进去并初始化为undefined，而let、const只登记名字、不初始化。

这个“只登记不初始化”的差别，正是 TDZ 的来源。名字已经在词法环境里了，但绑定处于未初始化状态，任何读取都会触发ReferenceError，直到执行到声明语句那一行才完成初始化。所以let并不是“没有提升”，而是“提升了但不可访问”。很多人把 TDZ 理解成“声明之前不能用”的语法规则，其实它是运行时对未初始化绑定的保护。

// 创建阶段：x 被登记并初始化为 undefined；y 被登记但未初始化 console.log(x); // undefined，因为 var 的绑定已初始化 console.log(y); // ReferenceError: Cannot access 'y' before initialization var x = 10; let y = 20;

上面这段代码里，x的undefined不是“值还没赋”，而是创建阶段就写进去的初始值；y的报错也不是“找不到变量”，而是“找到了但还没初始化”。区分这两点，后面排查闭包和循环问题会省很多力气。

2.2 变量环境与词法环境：两套记录本各管什么

执行上下文里其实有两个环境记录：变量环境（VariableEnvironment）和词法环境（LexicalEnvironment）。在早期的规范实现里，var声明进变量环境，let、const进词法环境；函数声明按情况进变量环境。这样设计的好处是，var的函数级作用域和let的块级作用域可以共存于同一套上下文模型里，而不需要为两种声明写两套执行逻辑。

块级作用域的落地方式是：每进入一个{}块，就为它新建一个词法环境，外层通过outer引用串成作用域链。查找变量时从当前词法环境开始，逐层向外，直到全局环境。var不参与这个“每块新建”的过程，它只认函数边界，所以循环体里用var声明的变量在整个函数内是同一个绑定。

function demo() { if (true) { var a = 1; // 登记在函数级变量环境 let b = 2; // 登记在 if 块的词法环境 } console.log(a); // 1，var 穿透了块 console.log(b); // ReferenceError，b 的块已经退出 } demo();

这段代码说明块级作用域不是“看不见”，而是“出了块就查不到”。b的绑定随块的环境一起失效，而a始终挂在函数环境上。理解这一点，就能解释为什么在for循环里用let声明循环变量，每次迭代都能拿到独立的值——规范要求for语句为每次迭代创建新的词法环境，把上一轮的值复制进去。

2.3 函数声明为什么能整体提升

函数声明和var的处理不一样：创建阶段会把整个函数对象放进环境，而不只是名字。所以你在声明之前调用函数声明是合法的。但函数表达式不行，因为它本质是一次赋值，右侧的函数对象要到执行阶段才创建。

sayHi(); // 正常输出，函数声明整体提升 function sayHi() { console.log("hi"); } sayBye(); // TypeError: sayBye is not a function var sayBye = function () { console.log("bye"); };

第二段报TypeError而不是ReferenceError，原因是sayBye这个名字已经被var登记为undefined，调用undefined()才抛类型错误。这个细节在排查“为什么我的回调没执行”时很关键：先看报错类型，ReferenceError指向 TDZ 或未声明，TypeError往往指向“声明了但还没赋值”。

提示：把函数声明和函数表达式混用是变量提升类 bug 的高发区，尤其在条件分支里写函数声明时，不同引擎的历史行为曾有差异，稳妥做法是统一用const fn = () => {}或函数表达式。

3. 函数是一等公民：闭包、this 与调用栈的三角关系

3.1 闭包不是魔法，是作用域链没被回收

函数在 JavaScript 里是一等公民，可以作为参数传递、作为返回值返回。一旦函数被返回，它携带的作用域链并不会因为外层函数执行完毕就消失，而是被这个内层函数引用着，这就是闭包。闭包的本质是“函数对象 + 它创建时所在词法环境的引用”。引擎不会主动回收仍被引用的环境，所以外层函数的局部变量得以存活。

function makeCounter() { let count = 0; // 被内层函数引用，不会随 makeCounter 返回而销毁 return function () { count += 1; return count; }; } const next = makeCounter(); console.log(next()); // 1 console.log(next()); // 2

count不在全局，也不在next自身的执行上下文里，而是挂在next的作用域链上。每次调用next，查找count都会顺着链找到makeCounter那次调用留下的词法环境。这也解释了循环里用var的经典翻车：所有回调共享同一个函数级绑定，循环结束时它已经是最后一个值。

3.2this由调用方式决定，不由定义位置决定

普通函数的this是在调用时绑定的，取决于“怎么调”：作为对象方法调用指向该对象，独立调用在非严格模式下指向全局对象、严格模式下是undefined，用call/apply/bind可以显式指定。箭头函数是例外，它没有自己的this，捕获定义时外层作用域的this。这个差异经常让“把方法当回调传出去”的代码翻车。

const timer = { seconds: 0, start() { setInterval(function () { this.seconds += 1; // 普通函数，this 不是 timer console.log(this.seconds); }, 1000); } };

上面这段里，回调里的this在非严格模式下是全局对象，this.seconds变成NaN或污染全局。改成箭头函数() => { this.seconds += 1; }就能正确捕获timer。这不是箭头函数“更好”，而是它的this语义恰好匹配“回调里想用外层 this”的场景。反过来，如果需要一个可被bind改写的动态this，就不该用箭头函数。

3.3 调用栈与参数传递：值传递的真相

JavaScript 的参数一律按值传递。原始类型传的是值的副本，引用类型传的是引用的副本——所以函数内重新赋值参数不会影响外部变量，但通过引用修改对象属性会影响外部。这个区别在写工具函数时经常被忽略。

function reassign(obj) { obj = { name: "new" }; // 只改了形参这个引用的副本 } function mutate(obj) { obj.name = "changed"; // 通过引用改到了同一个对象 } const p = { name: "old" }; reassign(p); console.log(p.name); // old mutate(p); console.log(p.name); // changed

调用栈方面，每次函数调用都会压入一个新的执行上下文，返回时弹出。递归过深会触发栈溢出，这也是为什么处理大树或深嵌套结构时，常见的实现思路是改成显式栈加循环，而不是依赖递归。

4. 对象与原型链：属性查找为什么能一路向上

4.1 对象是键值对，但查找走的是原型链

对象在 JavaScript 里是核心概念，数组和函数本质上也是对象。每个对象都有一个内部链接指向它的原型对象，读取属性时先查自身，找不到就沿原型链向上，直到null。这条链是 JavaScript 实现继承和共享方法的底层机制，也是“为什么数组能调map”的答案——map挂在Array.prototype上。

const arr = [1, 2, 3]; console.log(arr.hasOwnProperty("map")); // false，map 不在实例自身 console.log("map" in arr); // true，沿原型链能找到 console.log(Object.getPrototypeOf(arr) === Array.prototype); // true

理解原型链后，很多“玄学”现象就有了解释：给实例赋值同名属性会遮蔽原型上的属性；for...in会枚举可枚举的继承属性，而Object.keys只返回自身可枚举属性。排查“为什么多了一个不该有的键”时，先分清是自身属性还是原型上的。

4.2const锁的是绑定，不是对象内容

const声明的变量不能被重新赋值，但它指向的对象内容可以改。原因是const约束的是词法环境里的绑定，不允许绑定指向新的值，而对象内部属性的修改不涉及重新绑定。

const config = { debug: false }; config.debug = true; // 合法，改的是对象属性 // config = {}; // TypeError，试图重新绑定 Object.freeze(config); // 冻结后属性也不可改（浅冻结）

需要真正不可变时，用Object.freeze，但要注意它是浅冻结，嵌套对象仍需逐层处理。这也是很多配置对象在运行时被意外改写的原因之一。

4.3 属性描述符与this在方法调用中的绑定

对象方法里的this指向调用它的对象，但方法被单独取出后调用，绑定就丢了。这是“方法丢失 this”的典型场景，常见于把方法作为回调传递。

const person = { name: "A", greet() { console.log(this.name); } }; const g = person.greet; g(); // undefined（严格模式下 this 为 undefined） person.greet(); // A

解决办法是用bind固定，或在调用处用person.greet()形式。理解属性查找和this绑定是两条独立的规则，能避免把“方法找不到”和“this 不对”混为一谈。

5. DOM 与异步：单线程怎么同时处理点击和网络

5.1 DOM 是编程接口，操作的是节点树

DOM 把 HTML 文档抽象成节点树，JavaScript 通过它动态访问和更新内容、结构、样式。getElementById、querySelector返回的是节点引用，修改innerHTML会触发解析和重排，频繁操作代价高。常见的实现思路是批量修改、用文档片段减少回流，或者先改class再统一应用样式。

const list = document.getElementById("list"); const fragment = document.createDocumentFragment(); for (let i = 0; i < 100; i += 1) { const item = document.createElement("li"); item.textContent = `item ${i}`; fragment.appendChild(item); // 先在离屏片段里拼装 } list.appendChild(fragment); // 一次性挂到文档，减少重排

事件监听方面，addEventListener支持冒泡和捕获两个阶段，利用冒泡做事件委托可以减少监听器数量。注意移除监听时要传同一个函数引用，匿名函数无法移除，这是排查“监听器越绑越多”的常见坑。

5.2 事件循环：单线程靠任务队列实现并发假象

JavaScript 是单线程的，但能处理网络请求、定时器和用户交互，靠的是事件循环。同步代码执行完后，引擎先清空微任务队列（Promise 回调、queueMicrotask），再取一个宏任务（定时器、事件回调）执行，如此往复。setTimeout(fn, 0)并不是立即执行，而是排到宏任务队列，等当前同步代码和微任务都处理完。

console.log("A"); setTimeout(() => console.log("B"), 0); Promise.resolve().then(() => console.log("C")); console.log("D"); // 输出顺序：A D C B

这个顺序是排查“为什么我的状态更新晚于预期”的基础。微任务在每轮宏任务之间清空，所以 Promise 链会比定时器先跑。理解这一点，就不会把异步回调的执行时机当成随机。

5.3 Promise 与 async/await：把回调地狱拉平

Promise 把异步结果包装成三种状态：pending、fulfilled、rejected，状态一旦落定不可逆。then返回新的 Promise，支持链式调用；async/await是 Promise 的语法糖，让异步代码读起来像同步，但本质仍是微任务调度。

async function loadData() { try { const res = await fetch("/api/data"); // 等待 Promise 落定 const data = await res.json(); return data; } catch (err) { console.error("load failed", err); // 统一捕获链路上的错误 throw err; } }

await后面的代码会被包进微任务，所以它不会阻塞主线程，但会改变执行顺序。常见误区是在forEach里用async回调，forEach不会等待 Promise，导致“循环跑完了但请求还没回来”。需要串行就用for...of加await，需要并行就用Promise.all。

6. 避坑与排查：声明、this、异步的高频翻车现场

6.1 循环里用var注册回调，全部拿到最后一个值

现象：给一组按钮绑定点击事件，点任何一个都输出最后一个索引。原因：var是函数级作用域，所有回调共享同一个绑定，循环结束时它已是终值。解决：改用let让每次迭代有独立绑定，或用闭包工厂函数把当前值包起来。

for (var i = 0; i < 3; i += 1) { setTimeout(() => console.log(i), 0); // 输出 3 3 3 } for (let j = 0; j < 3; j += 1) { setTimeout(() => console.log(j), 0); // 输出 0 1 2 }

6.2 方法当回调传出去，this丢了

现象：对象方法里访问this.xxx得到undefined或报错。原因：方法被单独取出后独立调用，this不再指向原对象。解决：用bind固定，或改成箭头函数捕获外层this，或在调用处保持obj.method()形式。

6.3 在 TDZ 里访问let变量，报错信息被误读

现象：控制台报Cannot access 'x' before initialization，有人以为是“变量没声明”。原因：let/const的绑定已登记但未初始化，处于暂时性死区。解决：把声明移到使用之前，或检查是否有块级作用域提前引用的逻辑。

6.4forEach里写async，以为会串行等待

现象：循环里的异步请求看似同时发出，后续代码在请求完成前就执行了。原因：forEach不处理回调返回的 Promise。解决：串行用for...of加await，并行用Promise.all收集。

6.5 频繁改innerHTML导致页面卡顿

现象：循环里逐条追加列表项，页面明显掉帧。原因：每次修改都触发解析和重排。解决：用DocumentFragment离屏拼装后一次性挂载，或批量更新后统一触发样式变更。

7. 设计取舍：为什么 JavaScript 要保留这些“反直觉”

回头看，变量提升、TDZ、原型链、事件循环这些机制，单看每一条都像是历史包袱，但放在一起看，它们服务的是同一个目标：让一门最初只为浏览器加动态效果的语言，在不破坏已有页面的前提下持续演进。var的提升行为是早期实现留下的兼容性约束，let/const用 TDZ 在不改变旧代码语义的情况下引入了块级作用域；原型链用委托而不是复制来实现共享，省内存但让属性查找多了一层；单线程加事件循环避免了锁的复杂度，代价是异步顺序需要开发者自己理清。这些不是“设计得不好”，而是在兼容、性能和表达力之间做的取舍。

验证这些机制最直接的办法不是背结论，而是打开控制台做小实验：改一个关键字看报错类型，把回调换成箭头函数看this变化，用console.log打出执行顺序。我一般会在遇到“明明写了却没生效”时，先问自己三个问题：这个绑定在哪个环境里、this是谁、这段代码排在哪个队列。从那以后我每次写涉及闭包和异步的代码，都强制先在纸上画出作用域链和任务顺序再动手，翻车次数明显少了。希望帮到你。

本文还有配套的精品资源，点击获取