简介：一份面向JavaScript初学者的系统入门教程，以docx文档形式呈现，帮助读者从零建立对JS语言核心知识的完整认知。教程内容覆盖变量声明（var、let、const的区别与作用域）、数据类型、运算符、控制结构、函数、对象、DOM操作及异步编程等关键模块，每个知识点均配有示例代码，适合零基础入门或有一定编程基础但希望系统梳理JavaScript概念的读者。资源打包为1个docx文件，压缩包大小仅19KB，内容轻量、便于快速阅读，已有88人学习浏览。通过逐步讲解与代码演示，读者可以掌握变量与类型的运用、函数与对象的使用、通过DOM动态操作网页内容，并理解基于回调、Promise与async/await的异步编程思路，为实际开发打好基础。

1. JavaScript的体制：一门「单线程」语言，凭什么扛起整个现代前端

单线程、动态弱类型、原型对象、事件循环。这四个词几乎出现在每一本 JavaScript 入门书的前几页，但很少有人停下来追问：为什么偏偏是这些设计？一门最初只是为了「给网页加点交互」而仓促诞生的语言，为什么最终成为整个现代前端的基石，甚至反向杀回服务器端？

答案藏在 JavaScript 的核心体制里：它本质上是一个「单线程执行 + 事件循环调度 + 基于原型链的对象模型」的组合。初学者当玄学背的变量提升、闭包、this 丢失、Promise 执行顺序，其实是同一套底层机制的四个侧面。把这些机制拆开看透，你再看 JavaScript 的「反常设计」，会从记结论变成推导结论。下文从这份教程覆盖的核心主题——变量、函数、对象、DOM 与异步——逐层拆解，试着回答「为什么这样设计、凭什么能 work」。

2. 变量声明三兄弟：为什么 var 能提升，let 却有「暂时性死区」

2.1 var 的「提升」是登记，不是搬运

很多教程讲 var，直接说「变量被提升到了作用域顶部」。这个说法有迷惑性——引擎并不会真的把代码「搬」到上面去。真实的机制是这样的：JavaScript 引擎在执行一段代码之前，会做一次「预扫描」，把作用域内所有 var 声明和函数声明的名字收集起来，登记进当前执行上下文的环境记录里，var 登记的初始值是 undefined。这就是声明登记阶段。等到真正执行到var x = 10这一行，发生的事情只是「给一个已经存在的名字赋值」。

console.log(a); // undefined，不报错 var a = 10; console.log(a); // 10

第一行能跑通，不是因为代码被移位了，而是预扫描阶段已经把a登记在了当前环境里。函数声明同理，但函数声明的登记是「整体登记」，整个函数体在预扫描时就位，所以函数声明可以在定义前调用。我一般把这段过程分成两个阶段理解：声明阶段负责造「名字」，执行阶段负责赋「值」。名字先出现，值后出现，中间那一段空档，就是人们说的「提升」的真相。注意，var a = 10这句在引擎眼里是两条指令：声明a和赋值10，前者已经被预扫描抢跑了。

2.2 块级作用域：花括号里多了一块环境记录

let 和 const 与 var 最大的差异是作用域。在运行时，每进入一个花括号代码块（if、for、while，甚至单独的{}），引擎都会创建一个新的词法环境，嵌套在外部环境里。这个环境有自己的环境记录，let/const 声明的变量就存在这里。换句话说，块级作用域不是语法层面的「规则」，而是运行时真实存在的「对象」——一块环境记录。

let x = 1; if (true) { let x = 2; console.log(x); // 2，当前块级环境里找到了 } console.log(x); // 1，回到外层环境查找

这里要引出作用域链的运行时实现：环境记录之间靠一个outer指针串成链表。你在函数内部访问一个变量，引擎先查当前函数的环境记录，查不到就顺着outer往外层找，直到全局环境。这就是「作用域链查找」的底层动作——不是抽象概念，而是一条实际存在的链表。花括号创建的新环境记录挂在链上，内部声明的x存进新环境，与外层x互不干扰。用 var 则不同：var 没有块级环境的概念，它登记的永远是最近的函数环境或全局环境，所以for循环里用 var 声明的变量，循环结束之后依然活着，这也为后面要讲的坑埋下了伏笔。

2.3 暂时性死区：引擎给 let/const 加的一道初始化锁

严格来说，let/const 也有「提升」——引擎预扫描时同样会登记它们。区别在于，登记时这些名字会被标记为「未初始化」，在初始化语句执行之前访问，引擎直接抛 ReferenceError。这个「声明了但还没初始化」的区间，就是暂时性死区。

console.log(y); // ReferenceError: Cannot access 'y' before initialization let y = 20;

注意一个关键细节：报错信息是Cannot access before initialization，而不是y is not defined。这两者差别很大——not defined是说环境记录里根本没有这个名字；TDZ 是说名字存在，但处于「未初始化」状态，引擎不允许读取。环境记录里找不到名字，和找到名字但标记未初始化，是两条不同的错误路径。为什么偏偏要设计 TDZ？因为 var 那种「默认 undefined」的行为掩盖了一个严重问题：你声明了变量但忘了赋值，读取时拿到 undefined，程序不报错，bug 被拖延到运行时某个隐蔽角落才暴露。TDZ 把错误提前到「访问的第一瞬间」暴露，宁可报错也不静默失败——这种设计取向在 JavaScript 后续版本里反复出现。我习惯把 TDZ 理解为引擎给 let/const 加的一道「初始化检查锁」，锁在赋值执行的那一刻才打开。

提示：const 要求声明时必须赋值，并且不能重赋值。注意「不能重赋值」不等于「不能修改属性」——const p = {name: 'a'}之后p.name = 'b'合法，因为变的是 p 指向的对象内部，不是 p 这个绑定本身。「绑定」是名字到值的关联，const 锁定的是关联关系，不是值对象的内部状态。

2.4 三种声明的取舍对比

这张表里最值得琢磨的是「可重复声明」一列。var 允许在同一作用域重复声明，本质是「后声明覆盖前声明」，这给大型项目埋了不少雷——两个文件里的同名全局变量可能互相踩。let/const 禁止重复声明，则是在语法解析阶段就能报错，把冲突提前暴露。从 var 到 let/const，JavaScript 走的是一条「把运行时错误变成编译时错误」的路子，这个取向在理解整个语言进化史时非常重要。

3. 闭包与 this：三起 JS「玄学」bug 的现场排查

3.1 案例一：循环里用 var 绑定事件，回调拿到的全是最后一个值

现象：给一组按钮绑定点击事件，点任意按钮，控制台打印出来的都是最后一个下标。复现代码：

for (var i = 0; i < 3; i++) { document.getElementById('btn' + i).addEventListener('click', function () { console.log(i); // 无论点哪个按钮，都打印 3 }); }

原因：var 声明的i登记在 for 循环所在的函数作用域里，整个作用域只有一份i。循环结束后i走到 3，三个事件回调引用的其实是同一个变量。点击发生时读取i，拿到的已经是循环结束后的 3。注意回调函数没有「记住当时的 i」，它记住的是「名字 i」，而这个名字最终指向 3——这句话是理解闭包的关键。

解决：把 var 换成 let。引擎每次迭代会创建新的词法环境，i在每一轮循环里各存一份，闭包引用的是各自环境里的i。也可以用「闭包工厂」：把i作为参数传给立即执行函数，让每一轮的i变成该闭包的局部变量。从那以后我在循环里一律用 let，这条血泪经验几乎再没犯过。

3.2 案例二：对象方法被拆出来调用，this 变成 undefined

现象：对象方法单独赋值给变量后再调用，this 不再是原对象：

const person = { name: 'JS', greet() { console.log(`Hello, ${this.name}`); } }; const fn = person.greet; fn(); // TypeError: Cannot read properties of undefined (reading 'name')

原因：this 的指向不是由「函数定义在哪里」决定的，而是由「函数被怎么调用」决定的。person.greet()这种调用方式，调用主体是 person，引擎把 this 绑定为 person。而fn()是裸调用，在严格模式下 this 是 undefined，this.name就成了读 undefined 的属性。方法内部的 this 没有「记住」它来自哪个对象——JavaScript 的函数本身是无状态的行为包，上下文是在调用点临时决定的。

解决：用fn.bind(person)把 this 固定成 person，或者用箭头函数定义方法（箭头函数没有自己的 this，词汇上向外层借用），又或者保证调用姿势永远是person.greet()。我排查这类 bug 的第一条习惯：先看调用点，不看定义处。this 丢失，九成是调用姿势变了。

3.3 案例三：闭包「记住」的是一个变量，不是那一刻的值

现象：定时器里连续打印计数器，预期每隔一秒打印 1、2、3，实际打印 3、3、3：

for (var i = 1; i <= 3; i++) { setTimeout(function () { console.log(i); }, i * 1000); }

原因：闭包捕获的是变量绑定本身，不是快照。setTimeout 的回调执行时，循环早已结束，读到的是i的最终值 3。这里和案例一共享同一个底层原因，只是换了一层皮。很多人以为闭包会「复制一份当时的 i」，不对——闭包捕获的是环境记录里那个名字，后续对这个名字的每一次赋值，闭包都会实时看到。这也是「为什么这个值又变了」这类诡异问题的根源。

解决：let 或 IIFE 传参。除此之外，还要养成一个习惯：闭包里引用基本类型变量时，先问一句「这个变量以后还会变吗」。如果会变，就该考虑把值固化。

3.4 一套可复用的排查流程

遇到闭包或 this 相关的诡异行为，我一般按三步走：

1. 看变量声明方式：var 还是 let？var 的情况下先怀疑「共享变量」问题。
2. 看调用点：函数是裸调用、方法调用还是作为回调传入？裸调用且严格模式下，this 就是 undefined。
3. 看捕获目标：闭包引用的变量是基本类型还是对象？基本类型看当前值，对象看引用。

这三步能覆盖绝大多数 JavaScript 作用域与 this 相关的坑。出现报错别急着搜答案，把调用点翻译成引擎视角的「谁在调、读哪个环境记录」，基本就能自己推出来。

4. 函数与对象：一等公民是如何用原型链替代「类继承」的

4.1 函数是一等公民：把「行为」当成值传

JavaScript 里函数也是对象——具体说是 Function 类型的对象。这意味着函数可以赋给变量、装进数组、作为参数传给另一个函数、被另一个函数返回。这个「一等公民」地位是整个异步编程的地基：setTimeout 接收一个函数当参数，Promise 的 then 接收一个函数当参数，事件监听的 addEventListener 也接收函数。它们的本质都是「在某个时机，由引擎来调用你传进来的函数」——这叫控制反转，你只管描述「要做什么」，不用管什么时候做、在哪做。

function compose(f, g) { return function (x) { return f(g(x)); }; } const add1 = x => x + 1; const double = x => x * 2; const run = compose(add1, double); console.log(run(3)); // 7，先 double 得 6，再 add1 得 7

这段代码里，compose 返回了一个匿名函数，这个匿名函数捕获了参数 f 和 g，构成了闭包。调用 run(3) 时，先执行内部约束好的g(3) = 6，再执行f(6) = 7。这里能成立的关键就是「函数可以被返回」——函数体是被延迟执行的「值」，而闭包保证了 f、g 不会在 compose 返回后消失。日常写的防抖节流、柯里化、装饰器，都是这套机制的变体。理解「函数即值」，再回头看回调风格，就会明白它并不是什么复杂设计，只是一个语言特性被反复复用。

4.2 原型链：属性查找是一条运行时动态的链

JavaScript 对象是「键值对集合」，这是常识。但对象身上还有一个隐藏属性[[Prototype]]，它指向另一个对象（通常是某个构造函数的 prototype 对象）。读取对象属性时，引擎先查对象自身属性，查不到就顺着[[Prototype]]往上找，直到 null。这条链路，就是原型链。

function Person(name) { this.name = name; } Person.prototype.sayHello = function () { return `Hello, ${this.name}`; }; const p1 = new Person('JS'); console.log(p1.sayHello()); // Hello, JS console.log(p1.toString()); // [object Object]，从 Object.prototype 找到

new Person('JS')本质上做了四件事：创建一个新对象、把新对象的[[Prototype]]指向 Person.prototype、以新对象为 this 调用 Person 函数、如果构造函数没有显式返回对象就返回这个新对象。关键点：p1 自身没有 sayHello 属性，引擎沿着「p1 → Person.prototype」这条链找到了方法；toString 则来自更上层的 Object.prototype。原型链查找是运行时的动态过程——你在 Person.prototype 上后补一个方法，所有已有的实例立刻能用。这种「运行时按需扩展」的能力，是传统类继承做起来很别扭、原型链却天然擅长的事。

4.3 「一切皆对象」是个伪命题：装箱机制

「JavaScript 里一切皆对象」是流传很广但不严谨的说法。字符串、数字、布尔这些基本类型在运行时不是对象，是原始值。那么问题来了：'abc'.length为什么能用？

let s = 'abc'; console.log(s.length); // 3，临时装箱后访问 let n = 12.5; console.log(n.toFixed(1)); // 12.5，临时装箱后调用

因为引擎在「访问属性的一瞬间」，把原始值临时包装成了对应的包装对象（String、Number、Boolean），访问结束后这个临时对象立刻被丢弃。这个隐式转换叫装箱。理解它，就能明白为什么给基本类型挂属性是无效的：s.custom = 1执行时，装箱对象马上就没了，下一次读s.custom又是新的装箱对象。如果你发现「给字符串加了属性却丢了」，先别怀疑引擎坏了——它压根没打算让你绑在临时对象上。装箱机制是 JavaScript 类型系统里「看似矛盾、实际自洽」的典型：语言用一层临时包装，让原始值也能享受对象方法，同时又不改变原始值的本质。

4.4 class 语法糖：换了套礼服的原型链

ES6 的 class 并没有发明新的继承体系，它编译后的运行时结构依然是那根原型链。class 里定义的方法会成为 prototype 上的方法，constructor 就是原来的构造函数。看到 class 别以为 JavaScript 终于拥抱了传统「类继承」——底层那条委托链没变，变的只是书写方式。

class Animal { constructor(name) { this.name = name; } speak() { return `${this.name} makes a sound`; } } class Dog extends Animal { speak() { return `${this.name} barks`; } }

Dog.prototype的内部[[Prototype]]指向Animal.prototype，所以 Dog 的实例能一路委托到 Animal 的方法。class 只是把「构造函数 + 原型方法」打包成更符合其他语言习惯的样子，内部依然是对象与对象之间的委托关系。设计上的取舍在于：委托模型更灵活，但理解成本高；class 牺牲了一部分「非主流玩法」，换来了更低的入门门槛和更好的可读性。

5. 事件循环与异步：单线程凭什么扛住高并发

5.1 单线程的一个线程，配一群后台干活的线程

JavaScript 主线程只有一条，同一时刻只能执行一段代码。但浏览器并不只有一个线程：渲染线程、网络线程、定时器线程各司其职。JavaScript 的「单线程」指的是「执行 JS 代码的调用栈只有一个」，但浏览器环境把耗时的活外包给了其他线程，等线程干完，往消息队列里丢一个任务，JS 线程空闲时就去取。这个模型就是事件循环。

这里值得澄清一个常见误解：async、Promise、setTimeout 都不是「并行执行」，而是「延后执行」。真正的计算还是在一条线程上排队做，所谓异步只是改变了「什么时候被排进队列」。网络请求的耗时发生在浏览器的网络线程里，JS 线程并没有阻塞，等结果回来了，回调被插入队列。这个「不排队等待、先干别的去」的调度策略，让单线程也能同时挂起成百上千个请求。DOM 操作也受这个模型约束：操作 DOM 的代码本身是同步执行的，但浏览器把样式计算和绘制放在下一个渲染时机，所以同一帧内多次改 DOM 会合并处理，而不是改一次画一次。

5.2 宏任务与微任务：队列也有优先级

事件循环的队列分两层：宏任务队列和微任务队列。setTimeout、setInterval、DOM 事件、IO 操作的回调进宏任务队列；Promise.then/catch/finally、queueMicrotask、MutationObserver 的回调进微任务队列。每次事件循环先处理一个宏任务，然后把当前微任务队列里所有任务全部清空，再取下一个宏任务。微任务不仅能插队，还能在清理过程中生成新的微任务，这些新任务会在当前这一轮全部执行完，不会拖到下一轮。

console.log('1: 同步'); setTimeout(() => console.log('2: 宏任务'), 0); Promise.resolve().then(() => console.log('3: 微任务')); console.log('4: 同步');

输出顺序是 1、4、3、2。解析：同步代码先跑完；Promise.then 的回调进了微任务队列，宏任务队列里躺着 setTimeout 回调；调用栈清空后，引擎先清空微任务队列，再回来取宏任务。setTimeout 设置 0 毫秒，不代表「立刻执行」，只是「尽快排进宏任务队列」，实际执行要等当前宏任务结束并清空微任务之后。面试里那道经典输出顺序题，把队列层级关系搞清楚，答案根本不用背。

5.3 Promise：一个带状态机的任务盒

Promise 的核心实现是状态机。一个 Promise 实例只能从 pending 变为 fulfilled 或 rejected，状态一旦定型不可逆。resolve 和 reject 就是触发状态转移的两个开关。then 注册的回调会进入微任务队列，而不是立即执行。

const p = new Promise(function (resolve, reject) { setTimeout(function () { resolve('成功'); }, 1000); }); p.then(v => console.log(v)); console.log('先执行这行');

代码执行流程：Promise 构造器里的函数会同步执行，里面只是发起了一个 setTimeout，然后立即返回，此时 p 的状态还是 pending；最后一行同步代码先执行；1 秒后定时器回调触发 resolve，把 p 置为 fulfilled，并把 p.then 里注册的回调推进微任务队列；JS 线程空闲后，打印「成功」。整个过程中主线程没有被任何一步卡住，这就是 Promise 给异步代码带来的「可编排」能力——多个异步步骤可以用链式 then 串起来，避免回调一层套一层的金字塔。链式 then 的机制是：then 本身返回一个新的 Promise，所以可以继续 then，直到状态落定。

5.4 async/await：给异步穿上同步外衣

async/await 本质上是 Promise 加生成器的语法糖。async 函数执行到 await 那一行会「暂停」，把 await 后面的 Promise 挂到事件循环上，让出线程；等 Promise 落定，恢复执行，把结果当作表达式的值赋给 await 左侧。暂停与恢复正是生成器的核心能力，async/await 把它的状态管理整个隐藏掉了。

async function main() { console.log('A'); const result = await new Promise(r => setTimeout(() => r('done'), 500)); console.log(result); } main(); // A →（约500ms后）done

这里有两个常被忽略的细节：async 函数返回的永远是一个 Promise，即使函数体里没有 await；调用 main() 时，同步部分先执行，打印 A，遇到 await 挂起，main 函数让出调用栈。之后 Promise 落定，恢复执行，打印 done。如果 await 那里抛错，整个 async 函数返回的 Promise 变成 rejected 状态，用 try/catch 包住 await 就能捕获。从回调到 Promise 再到 async/await，是一次次「可读性革命」——Promise 解决了回调的信任问题（状态只能转移一次），async/await 解决了嵌套问题（用同步写法表达异步流程），但底层的事件循环调度机制一直没有变过。

6. 设计取舍：为什么 var 该退场却一直在，异步为什么越改越好读

回头看 JavaScript 的演进，有一条贯穿始终的原则：只加新的，不删旧的。var 的语义在现代 JavaScript 里已经被 let/const 全面超越，但你不能移除它——浏览器里有海量的存量代码依赖 var 的提升和函数作用域语义，一旦移除或彻底改变行为，整个现有网页生态会瞬间崩塌。向上兼容是 Web 平台的生存底线，于是 var 与 let 共存，新代码用新语义，旧代码运行不误。这不是「设计懒惰」，而是平台语言特有的约束：它不能像普通软件一样发布一个「破坏性大版本」。

原型链也没被「改造」成真正的类继承。class 语法糖把常见写法规范化了，但底层的委托机制原样保留。原因是委托模型在对象间共享行为这件事上极度灵活——运行时给 prototype 加方法，所有实例立即生效，没有编译步骤、没有重编译成本。这个特性对浏览器这种「代码常驻、热更新频繁」的环境是宝贵的。代价是理解成本高：新手很难一眼看透 this 的传递和原型链的方向。所以 JavaScript 的取舍是「保留灵活的核心，在上面盖一层好用的语法」——class 是那层外壳，原型链是内核。

异步的演进则展示了另一条思路：回调把控制反转交给外部，Promise 把状态管理收进一个可组合的对象，async/await 再把组合过程变成线性的同步代码。每一步都没有推翻前一步的运行时模型，只是换了一层更接近人类思考习惯的表达方式。这其实是语言设计里最难的部分——不改变底层调度，却彻底改变写代码的感受。从那以后我学任何 JavaScript 新特性，都会先问两个问题：它解决了什么痛点？代价是什么？而不是直接背 API。这份教程从 var 一路讲到 async/await，正好覆盖了 JavaScript 机制演进的完整链条，配合代码逐个在浏览器里跑一遍，比碎片化刷短视频建立的理解要扎实得多。需要这份资料的话，进资源详情页直接取就行，希望帮到你。

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