簡(jiǎn)介這是一份面向JavaScript初學(xué)者的系統(tǒng)教程適合對(duì)編程感興趣但尚未系統(tǒng)接觸過JS的人也適合有一定基礎(chǔ)想深入理解核心概念的開發(fā)者目標(biāo)是解決語法零散、DOM操作不熟、異步邏輯混淆等常見入門難題。資源包僅含1個(gè)docx文檔大小19KB內(nèi)容精煉且便于離線閱讀目前已有88人學(xué)習(xí)。文檔從變量聲明、數(shù)據(jù)類型、運(yùn)算符與控制結(jié)構(gòu)講起用示例逐步說明函數(shù)定義與調(diào)用、對(duì)象屬性與方法再延伸到DOM元素獲取、內(nèi)容修改和事件監(jiān)聽并清晰介紹回調(diào)函數(shù)、Promise和async/await等異步編程方案。教程同時(shí)建議讀者制作時(shí)鐘、待辦列表、計(jì)算器等小項(xiàng)目來鞏固知識(shí)并推薦MDN、Eloquent JavaScript等免費(fèi)學(xué)習(xí)資源幫助初學(xué)者建立完整知識(shí)體系快速過渡到實(shí)際項(xiàng)目開發(fā)。1. 從臨時(shí)腳本到前端基石單線程的 JavaScript 憑什么撐起整個(gè)現(xiàn)代 WebJavaScript 可能是唯一一門“槽點(diǎn)越多、用得越廣”的語言單線程卻被用來承載所有并發(fā)效果var 的提升和 this 的飄忽讓一代又一代新手翻車可它依然同時(shí)統(tǒng)治著瀏覽器、服務(wù)端和移動(dòng)端。反直覺的地方在于它不做多線程卻幾乎從沒因?yàn)榫W(wǎng)絡(luò)請(qǐng)求把頁面卡死過。這靠的不是運(yùn)氣而是一套任務(wù)調(diào)度機(jī)制——事件循環(huán)把執(zhí)行切成一塊塊同步代碼異步操作完成后再排隊(duì)回來單線程反而成了這套模型最可靠的底座。入門文檔開頭那句“輕量級(jí)、解釋型或即時(shí)編譯型、多范式”其實(shí)暗含了全部答案這些特性不是缺陷而是它在不同環(huán)境里突圍出來的原因。下面順著這份文檔的五個(gè)模塊——變量、函數(shù)、對(duì)象、DOM、異步——逐層往下拆你會(huì)看到每個(gè)“坑”背后的設(shè)計(jì)動(dòng)機(jī)而不只是記住怎么繞。2. 變量與作用域var 的提升、let 的暫時(shí)性死區(qū)到底改了什么教程里一句話帶過var 存在提升let/const 有塊級(jí)作用域。但“提升”到底是編譯期行為還是運(yùn)行時(shí)行為let 的塊級(jí)作用域?yàn)槭裁茨茉诼暶髑霸L問時(shí)直接拋錯(cuò)答案藏在語言引擎的兩階段工作方式里先整體掃描登記再逐行執(zhí)行。理解了這兩步變量這塊就不再是背誦結(jié)論。2.1 提升不是“把代碼搬上去”var 的編譯期登記最典型的提升現(xiàn)象長(zhǎng)這樣console.log(a); // undefined而不是 ReferenceError var a 10; console.log(a); // 10看起來像是“引擎把聲明搬到了頂部”實(shí)際上引擎在執(zhí)行前會(huì)對(duì)整個(gè)作用域做一次掃描把所有 var 聲明和 function 聲明登記到該作用域的環(huán)境記錄Environment Record里var 的綁定初始值為 undefined。聲明的登記發(fā)生在執(zhí)行之前這就是“提升”的真相——它不是一個(gè)移動(dòng)代碼的動(dòng)作而是一個(gè)提前登記的動(dòng)作。賦值a 10仍然停留在第二行執(zhí)行到那里才真正寫入值。提示提升只提升聲明不提升賦值。所以提前讀取輸出的是 undefined而不是 10。函數(shù)聲明則完全不一樣它是整體提升的包括函數(shù)體greet(World); // 即使函數(shù)聲明在后面也能正常調(diào)用 function greet(name) { return Hello, name; }引擎在掃描階段就把 greet 的完整定義登記好了所以“先調(diào)用后聲明”也能跑。多個(gè)函數(shù)互相遞歸引用靠的正是這份提前登記。但把同樣的函數(shù)改寫成函數(shù)表達(dá)式var greet function(name) {...}提前調(diào)用就會(huì)拋 TypeError——因?yàn)榇藭r(shí) greet 只是 undefinedundefined 不可調(diào)用。這個(gè)區(qū)別經(jīng)常出現(xiàn)在真實(shí)的模塊化代碼里有人把函數(shù)聲明改成表達(dá)式做“統(tǒng)一風(fēng)格”結(jié)果破壞了啟動(dòng)順序。為什么設(shè)計(jì)者保留這種“看起來亂”的行為因?yàn)樵缙诰W(wǎng)頁腳本大量依賴先調(diào)用后聲明瀏覽器兼容性讓這個(gè)行為成了既定事實(shí)。后來引入 let/const 時(shí)規(guī)范就順勢(shì)做出了更嚴(yán)格的新規(guī)則。2.2 暫時(shí)性死區(qū)let/const 的防呆機(jī)制let 和 const 同樣會(huì)被提前登記進(jìn)環(huán)境記錄但它們的綁定初始狀態(tài)與 var 有本質(zhì)差異{ // 從這里開始進(jìn)入暫時(shí)性死區(qū) console.log(x); // ReferenceError: Cannot access x before initialization let x 42; // 執(zhí)行到這行TDZ 結(jié)束 }x 的綁定在進(jìn)入這個(gè)塊的那一刻就存在了否則塊內(nèi)更靠后的代碼無法形成閉包引用它。但綁定處于“未初始化”狀態(tài)任何讀取或賦值都會(huì)拋 ReferenceError。聲明前的這段區(qū)域就叫暫時(shí)性死區(qū)TDZ。設(shè)計(jì)動(dòng)機(jī)很直白把“讀到一個(gè)未初始化的變量”從靜默的 undefined 變成顯式報(bào)錯(cuò)。var 時(shí)代最大的隱性 bug 就是“以為有值、其實(shí)是 undefined”TDZ 從機(jī)制上杜絕了這種隱患。有個(gè)細(xì)節(jié)值得注意對(duì)未聲明的變量執(zhí)行typeof會(huì)返回 undefined但對(duì)處于 TDZ 的變量執(zhí)行typeof會(huì)直接拋錯(cuò)。這意味著 typeof 不再是萬能的“安全探測(cè)”手段從 var 遷移到 let/const 的人經(jīng)常在這里踩坑。const 是在 let 之上再加一層約束綁定不可重新賦值。注意不可變的是綁定關(guān)系不是值本身——const obj {a: 1}; obj.a 2;完全合法因?yàn)?obj 這個(gè)綁定仍然指向同一個(gè)對(duì)象只是對(duì)象內(nèi)部狀態(tài)變了。很多項(xiàng)目里用 const 聲明數(shù)組后依然可以 push、改元素原理就在這里。聲明方式作用域聲明前訪問可重新賦值全局掛載var函數(shù)作用域undefined不報(bào)錯(cuò)可掛到全局對(duì)象上let塊級(jí)作用域ReferenceErrorTDZ可不掛全局const塊級(jí)作用域ReferenceErrorTDZ綁定不可不掛全局表中最后一項(xiàng)也常被忽略全局 var 會(huì)掛到全局對(duì)象上所以老代碼里window.version能讀到 var 聲明的變量改成 let/const 后全局對(duì)象上就沒有這個(gè)屬性了。不少歷史代碼遷移時(shí)在這里靜默失效表現(xiàn)就是“換個(gè)寫法全局變量突然找不到了”。2.3 閉包函數(shù)帶著出生環(huán)境到處走作用域決定了變量能不能被讀到閉包則決定了“讀到的那個(gè)環(huán)境能活多久”。看一個(gè)最經(jīng)典的例子function createCounter() { let count 0; return function () { // 返回的函數(shù)引用了 createCounter 的詞法環(huán)境 count 1; return count; }; } const counter createCounter(); console.log(counter()); // 1 console.log(counter()); // 2普通理解是“返回的函數(shù)記住了 count”機(jī)制層面的解釋是每個(gè)函數(shù)對(duì)象在創(chuàng)建時(shí)都攜帶一個(gè)內(nèi)部引用 [[Environment]]指向創(chuàng)建它的詞法環(huán)境。createCounter 執(zhí)行結(jié)束后它的環(huán)境按理該被回收但返回的匿名函數(shù)還引用著這個(gè)環(huán)境垃圾回收器發(fā)現(xiàn)它仍可達(dá)就不會(huì)動(dòng)它。于是 count 變成了一個(gè)只能通過 counter 訪問的私有狀態(tài)——外部代碼碰不到它這正是閉包模擬私有屬性的經(jīng)典方式。作用域鏈在運(yùn)行時(shí)是鏈?zhǔn)讲檎业漠?dāng)前函數(shù)環(huán)境 - 外層環(huán)境 - 再外層 - 全局環(huán)境。讀取 count 時(shí)引擎先看匿名函數(shù)自己的環(huán)境沒有再往上找賦值也一樣沿著鏈找到最近的綁定并寫入。這也解釋了閉包和垃圾回收的一個(gè)常見誤區(qū)“閉包導(dǎo)致內(nèi)存泄漏”——真正泄漏的從來不是閉包本身而是無意中讓大對(duì)象被長(zhǎng)生命周期函數(shù)引用住比如把整個(gè) DOM 節(jié)點(diǎn)掛在閉包里。var/let 在閉包上的差異會(huì)在循環(huán)場(chǎng)景里集中爆發(fā)這件事留到異步避坑章節(jié)用完整例子展開。現(xiàn)在先記住一個(gè)結(jié)論閉包不是語法糖它是詞法作用域加函數(shù)一等公民這兩個(gè)機(jī)制自然疊加的產(chǎn)物。JavaScript 里所有“記住狀態(tài)”的寫法都建立在它上面。3. 函數(shù)與對(duì)象一等公民、原型鏈與 this 綁定的底層邏輯如果說變量機(jī)制是地基函數(shù)和對(duì)象就是承重墻。教程把它們分開講但引擎層面兩者是同一套東西函數(shù)是可調(diào)用對(duì)象對(duì)象靠原型鏈關(guān)聯(lián)。這一章把它們放在一起拆是因?yàn)楹芏唷盀槭裁础北仨毢掀饋聿趴吹们濉?.1 一等公民為什么函數(shù)能當(dāng)參數(shù)又能當(dāng)返回值“函數(shù)是第一等公民”的意思是函數(shù)和其他值數(shù)字、字符串、對(duì)象享有同等待遇可以賦值給變量、作為參數(shù)傳進(jìn)別的函數(shù)、作為返回值從函數(shù)里出來。其他語言想做到類似效果通常要搞函數(shù)指針、接口或反射JavaScript 不需要這些中間層原因就是函數(shù)本身是一個(gè)對(duì)象——對(duì)象該有的屬性它全都有還多了一個(gè)內(nèi)部方法 [[Call]]把括號(hào)語法fn()映射成一次調(diào)用。function higherOrder(fn, value) { // fn 是函數(shù)對(duì)象的引用在內(nèi)部被調(diào)用不是調(diào)用結(jié)果 return fn(value) !; } function shout(text) { return text.toUpperCase(); } console.log(higherOrder(shout, hello)); // HELLO!傳進(jìn)去的是函數(shù)對(duì)象本身不是調(diào)用結(jié)果。新手最常見的手誤是寫成higherOrder(shout(), hello)——shout() 會(huì)立即執(zhí)行返回 HELLO再被當(dāng)參數(shù)傳進(jìn)去fn 就變成了字符串調(diào)用時(shí)直接 TypeError。理解“函數(shù)引用”和“函數(shù)調(diào)用結(jié)果”的差別是使用高階函數(shù)的第一道坎。高階函數(shù)真正的價(jià)值是把“做什么”和“怎么做”解耦回調(diào)函數(shù)說明做什么框架代碼決定怎么做。教程里的 DOM 事件監(jiān)聽、Promise 的 then 回調(diào)全部建立在這個(gè)機(jī)制上。數(shù)組的 map/filter/reduce 也是一樣的套路——接收一個(gè)函數(shù)作為參數(shù)內(nèi)部遍歷數(shù)組逐項(xiàng)調(diào)用。自己手寫一遍 map 就能體會(huì)函數(shù)能當(dāng)參數(shù)讓“算法骨架”和“具體邏輯”可以分開復(fù)用。3.2 原型鏈為什么數(shù)組能用 map普通對(duì)象不行教程說“數(shù)組和函數(shù)也是對(duì)象的一種”這句話背后是 JavaScript 獨(dú)特的繼承模型。它沒有“類復(fù)制”式的繼承而是對(duì)象之間通過內(nèi)部引用 [[Prototype]] 連成一條查找鏈const arr [1, 2, 3]; console.log(arr.hasOwnProperty(map)); // falsemap 不在 arr 自身 // 真正能調(diào)到 map 的原因 // arr - Array.prototype - Object.prototype - null console.log(Array.prototype.hasOwnProperty(map)); // true屬性訪問的規(guī)則是先查對(duì)象自身屬性查不到就沿 [[Prototype]] 鏈逐層往上找找到即返回。arr 自己沒有 map但鏈上的 Array.prototype 有所以 arr.map 可用。數(shù)組、普通對(duì)象、函數(shù)三者的差異本質(zhì)是它們各自的 prototype 掛在不同的對(duì)象上。這也是“在原型上加方法所有實(shí)例都能用”的機(jī)制來源同時(shí)也是“千萬別亂改 Object.prototype”的原因——一條鏈被污染全天下對(duì)象都會(huì)受影響。用構(gòu)造函數(shù)的視角看更清楚每個(gè)函數(shù)都有一個(gè) prototype 屬性new 出來的實(shí)例其 [[Prototype]] 指向構(gòu)造函數(shù)的 prototype。ES6 的 class 只是對(duì)這層關(guān)系的語法糖包裝class Person { constructor(name) { this.name name; } greet() { return Hello, this.name; } } const john new Person(John); console.log(john.greet()); // Hello, John console.log(john.hasOwnProperty(greet)); // false方法在原型上這里有一個(gè)內(nèi)存層面的實(shí)質(zhì)差異教程里的對(duì)象字面量寫法{greet: function(){...}}是每個(gè)實(shí)例各存一份函數(shù)副本class 語法定義的方法全部共享 Person.prototype 上的一份。幾千個(gè)實(shí)例時(shí)后者省下的內(nèi)存非常可觀。所以“方法放原型、狀態(tài)放實(shí)例”不是風(fēng)格偏好而是有明確工程收益的設(shè)計(jì)。new 關(guān)鍵字的執(zhí)行過程也值得拆開它內(nèi)部做了四件事——?jiǎng)?chuàng)建一個(gè)新對(duì)象、把新對(duì)象的 [[Prototype]] 指向構(gòu)造函數(shù)的 prototype、把構(gòu)造函數(shù)里的 this 綁定到新對(duì)象并執(zhí)行、返回新對(duì)象除非構(gòu)造函數(shù)顯式返回了對(duì)象。this 的變化就藏在這一步里下一節(jié)展開。3.3 this 綁定調(diào)用方式?jīng)Q定 this而不是定義位置教程里的person.greet()輸出了 Hello, John看起來 this 指向 person 是理所當(dāng)然的。但同一個(gè)函數(shù)換個(gè)姿勢(shì)調(diào)用結(jié)果可能完全不一樣const person { name: John, greet: function () { console.log(Hello, this.name); } }; person.greet(); // Hello, John隱式綁定this person const unbound person.greet; unbound(); // this 丟失讀 this.name 讀到 undefined const bound person.greet.bind(person); bound(); // Hello, John顯式綁定bind 固定了 thisthis 不是“定義時(shí)決定”的而是“調(diào)用時(shí)由調(diào)用表達(dá)式?jīng)Q定”的。person.greet()的調(diào)用上下文是 person把函數(shù)從對(duì)象上取下來裸調(diào)用上下文就沒了嚴(yán)格模式下 this 退化為 undefined非嚴(yán)格模式退化為全局對(duì)象。bind/call/apply 可以顯式指定 thisnew 會(huì)把 this 綁定到新實(shí)例。四條規(guī)則按優(yōu)先級(jí)從高到低new bind/call/apply 方法調(diào)用 裸調(diào)用。調(diào)用形式this 指向典型場(chǎng)景obj.fn() 方法調(diào)用objperson.greet()fn() 裸調(diào)用嚴(yán)格模式 undefined否則全局對(duì)象回調(diào)函數(shù)內(nèi)部fn.call(obj)/apply/bind傳入的對(duì)象顯式指定上下文new Fn()新創(chuàng)建的實(shí)例構(gòu)造函數(shù)箭頭函數(shù)是唯一的例外它沒有自己的 this 綁定創(chuàng)建時(shí)直接從外層詞法環(huán)境捕獲 this之后無論怎么調(diào)用都不變。事件回調(diào)里“this 丟了”是最高頻的翻車現(xiàn)場(chǎng)解法通常就是改用箭頭函數(shù)寫回調(diào)或者提前const self this捕獲。理解這條DOM 事件監(jiān)聽和異步回調(diào)里的 this 問題基本就免疫了。4. DOM 操作從 HTML 字符串到可編程對(duì)象樹的完整鏈路教程里 DOM 操作給了三個(gè)動(dòng)作獲取元素、改內(nèi)容、加事件。但“獲取元素”拿到的到底是什么“改內(nèi)容”為什么不是改字符串這一章把鏈路拆開HTML 怎么變成樹、事件怎么在樹里傳播、改動(dòng)怎么觸發(fā)渲染。4.1 文檔樹是怎么來的解析、節(jié)點(diǎn)與活引用瀏覽器拿到 HTML 后先做詞法分析把字節(jié)流切成 token再按標(biāo)簽的嵌套關(guān)系構(gòu)建出一棵 DOM 樹——樹的每個(gè)節(jié)點(diǎn)都是一個(gè)對(duì)象有標(biāo)簽名、屬性、子節(jié)點(diǎn)列表。這棵樹不是 HTML 文本的“快照”而是可編程的活對(duì)象。document.getElementById返回的引用會(huì)實(shí)時(shí)反映后續(xù)改動(dòng)這就是為什么代碼里可以先拿到元素、再修改屬性頁面馬上跟著變。// 獲取元素返回文檔中 id 匹配的節(jié)點(diǎn)找不到返回 null let element document.getElementById(myElement); // 修改內(nèi)容innerHTML 會(huì)把字符串重新解析成子節(jié)點(diǎn)并替換原內(nèi)容 element.innerHTML New content; // 添加事件監(jiān)聽器回調(diào)在事件被派發(fā)到該節(jié)點(diǎn)時(shí)執(zhí)行 element.addEventListener(click, function () { alert(Element was clicked!); });getElementById 在瀏覽器內(nèi)部維護(hù)著 id 到節(jié)點(diǎn)的映射所以查找是常數(shù)級(jí)的比 querySelector 遍歷選擇器更快。innerHTML 的賦值則是重操作傳入的字符串會(huì)被 HTML 解析器重新解析成一棵子樹替換掉原來的子節(jié)點(diǎn)。如果只想改里面的純文本textContent 更合適——它不觸發(fā) HTML 解析也不會(huì)誤把字符串里的尖括號(hào)當(dāng)標(biāo)簽。注意innerHTML 會(huì)把原有子節(jié)點(diǎn)連同它們身上綁定的事件監(jiān)聽器一起丟掉。動(dòng)態(tài)列表里如果先綁好了事件又用 innerHTML 整體重刷監(jiān)聽器會(huì)全部失效。這種問題排查起來很痛苦因?yàn)榇a看起來每一步都對(duì)。安全性也要提一句把用戶輸入直接拼進(jìn) innerHTML等于讓那段字符串擁有解析執(zhí)行 HTML 的能力。用 textContent 或 createElement 逐步構(gòu)建節(jié)點(diǎn)是從源頭避開注入的常規(guī)做法。4.2 事件冒泡與捕獲為什么監(jiān)聽一個(gè)父節(jié)點(diǎn)就夠了事件機(jī)制不是“發(fā)生在誰身上就停在哪”。一次點(diǎn)擊會(huì)經(jīng)歷三個(gè)階段從根節(jié)點(diǎn)向下穿透的捕獲階段、到達(dá)目標(biāo)節(jié)點(diǎn)的目標(biāo)階段、再向上回傳的冒泡階段。addEventListener 的第三個(gè)參數(shù)傳 true 就在捕獲階段觸發(fā)默認(rèn) false 則在冒泡階段觸發(fā)。這個(gè)模型衍生出最實(shí)用的技巧——事件委托document.querySelector(#list).addEventListener(click, function (e) { // e.target 是實(shí)際被點(diǎn)擊的元素不是監(jiān)聽器所在的 #list const li e.target.closest(li); if (li) { console.log(點(diǎn)到了, li.textContent); } });點(diǎn)擊任意一個(gè)子項(xiàng)事件都會(huì)冒泡到 #list由容器統(tǒng)一處理。e.target 給出真正被點(diǎn)擊的節(jié)點(diǎn)closest 沿祖先鏈找到最近的 li。這樣一來動(dòng)態(tài)新增的列表項(xiàng)不需要逐個(gè)綁定監(jiān)聽器新增即生效也不用擔(dān)心重刷 innerHTML 把監(jiān)聽器沖掉。內(nèi)存上也劃算一萬個(gè) li 各綁一個(gè)監(jiān)聽器和容器上只綁一個(gè)差距是數(shù)量級(jí)的。委托失效最常見的場(chǎng)景是中間層調(diào)用了 stopPropagation 阻止冒泡。如果某些隔離交互的代碼強(qiáng)制停掉冒泡外層的委托就收不到事件了。排查時(shí)先想清楚三階段路徑再確認(rèn)每一層有沒有人“截胡”。另一個(gè)相關(guān)細(xì)節(jié)是滾動(dòng)類事件在監(jiān)聽器里做復(fù)雜計(jì)算時(shí)可以考慮傳{passive: true}告訴瀏覽器“我不會(huì)調(diào)用 preventDefault”這樣滾動(dòng)性能會(huì)有明顯改善。4.3 重排與重繪為什么改幾條內(nèi)容會(huì)卡到掉幀DOM 是樹但瀏覽器最終畫出來的是像素。每次修改 DOM渲染進(jìn)程要走一條流水線樣式計(jì)算 - 布局重排- 繪制重繪- 合成。改變幾何尺寸、增刪節(jié)點(diǎn)會(huì)觸發(fā)重排重排必然帶重繪只改顏色這類不涉及幾何的屬性可以只觸發(fā)重繪?？D的根源往往不是單次操作貴而是操作被排成了“一次一刷”的低效序列// 反例循環(huán)里一次一改每次迭代都可能觸發(fā)重排 for (let i 0; i 1000; i) { list.appendChild(document.createElement(li)); } // 正確姿勢(shì)先把節(jié)點(diǎn)攢在 DocumentFragment 里 const frag document.createDocumentFragment(); for (let i 0; i 1000; i) { const li document.createElement(li); li.textContent item i; frag.appendChild(li); // 此時(shí) document 不受影響 } list.appendChild(frag); // 一次性掛載把多次重排合并成一次DocumentFragment 是一個(gè)脫離主文檔的輕量容器往里加節(jié)點(diǎn)不會(huì)觸發(fā)任何布局計(jì)算最后一次性掛接才觸發(fā)一次重排。另一個(gè)隱蔽的殺手是“強(qiáng)制同步布局”在兩次 DOM 寫入之間讀取 offsetWidth、scrollHeight 等布局屬性渲染進(jìn)程為了返回準(zhǔn)確值會(huì)被迫立刻執(zhí)行還沒排隊(duì)的布局計(jì)算。寫-讀-寫-讀交替會(huì)讓瀏覽器反復(fù)做無用的布局習(xí)慣里叫 layout thrashing。正確做法是“批量寫、批量讀”把對(duì)布局屬性的讀取收集到一起避免和寫入交錯(cuò)。5. 異步編程避坑事件循環(huán)、微任務(wù)與 Promise 的真實(shí)執(zhí)行順序教程說 JavaScript 是單線程的同時(shí)又說有異步編程這兩句話靠事件循環(huán)連起來。很多人在這一章栽跟頭不是因?yàn)楦拍铍y而是因?yàn)椤盎卣{(diào)執(zhí)行順序”和直覺相反。這一章把事件循環(huán)、微任務(wù)、Promise、async/await 按執(zhí)行順序串起來最后給四個(gè)最常見的翻車現(xiàn)場(chǎng)。5.1 事件循環(huán)setTimeout 為什么總是不準(zhǔn)時(shí)單線程意味著同一時(shí)刻只有一段同步代碼在跑但瀏覽器不能被網(wǎng)絡(luò)請(qǐng)求阻塞住。解決方案是同步代碼在主線程的調(diào)用棧上執(zhí)行定時(shí)器、網(wǎng)絡(luò)、事件這類異步操作交給瀏覽器其他線程處理完成后把回調(diào)投進(jìn)任務(wù)隊(duì)列調(diào)用棧清空時(shí)事件循環(huán)從隊(duì)列取出下一個(gè)任務(wù)執(zhí)行。這就是“單線程卻不卡”的全部秘密。console.log(A); setTimeout(function () { console.log(B); }, 0); console.log(C); // 實(shí)際輸出順序A C BsetTimeout 的第二個(gè)參數(shù) 0 不代表“立刻執(zhí)行”只代表“盡快入隊(duì)”。主線程要先把當(dāng)前這輪同步任務(wù) A、C 全部跑完才輪到隊(duì)列里的 B。所以延遲時(shí)間是個(gè)下限——“至少等這么久”而不是“到點(diǎn)就執(zhí)行”。用它做高精度定時(shí)器、倒計(jì)時(shí)、動(dòng)畫節(jié)拍誤差會(huì)隨主線程負(fù)載越來越大。這不是玄學(xué)是隊(duì)列機(jī)制的直接推論。真實(shí)的渲染時(shí)機(jī)也插在這一環(huán)里瀏覽器通常會(huì)在宏任務(wù)之間執(zhí)行渲染。所以 setTimeout 里改 DOM效果往往比同步改更平滑因?yàn)楦膭?dòng)會(huì)被合并到下一次渲染。理解這個(gè)位置關(guān)系很多“為什么 setTimeout 包一層就好用了”的謎題就解開了。5.2 Promise 與微任務(wù)then 回調(diào)排在誰前面Promise 核心是個(gè)狀態(tài)機(jī)pending、fulfilled、rejected狀態(tài)一旦落定不可逆。構(gòu)造函數(shù)里的 executor 是同步執(zhí)行的resolve/reject 只是把狀態(tài)翻轉(zhuǎn)真正異步的是 then 里注冊(cè)的回調(diào)——它們進(jìn)入微任務(wù)隊(duì)列在當(dāng)前任務(wù)結(jié)束、下一個(gè)宏任務(wù)開始之前全部清空。let promise new Promise(function (resolve, reject) { // executor 同步執(zhí)行這里注冊(cè)一個(gè) 1 秒后的定時(shí)器 setTimeout(function () { resolve(Success!); }, 1000); }); promise.then(function (result) { console.log(result); // 輸出Success! }); // 更直觀的順序?qū)Ρ?console.log(1); Promise.resolve().then(() console.log(2)); setTimeout(() console.log(3), 0); console.log(4); // 輸出1 4 2 3Promise.resolve().then的回調(diào)是微任務(wù)setTimeout 的回調(diào)是宏任務(wù)。當(dāng)前同步代碼打印 1、4 結(jié)束后事件循環(huán)先清空微任務(wù)隊(duì)列打印 2之后才執(zhí)行宏任務(wù)打印 3。微任務(wù)永遠(yuǎn)插隊(duì)到宏任務(wù)之前這是理解一切 Promise 順序問題的主線。對(duì) then 回調(diào)來說它在微任務(wù)里執(zhí)行意味著“狀態(tài)一落定后續(xù)微任務(wù)立刻就能看到”現(xiàn)代前端框架的批量更新機(jī)制也依賴這條順序。then 鏈的每次 then 都會(huì)產(chǎn)生一個(gè)新 Promise所以狀態(tài)和錯(cuò)誤可以沿著鏈傳遞。reject 或拋出的異常會(huì)沿鏈找最近的 catch如果整條鏈都沒有 catch錯(cuò)誤就變成無人認(rèn)領(lǐng)的 unhandledrejection控制臺(tái)會(huì)直接報(bào)出來。5.3 async/await語法糖背后的狀態(tài)機(jī)async/await 沒有引入新的并發(fā)模型它就是 Promise 的語法糖async 函數(shù)必然返回一個(gè) Promiseawait 會(huì)把后面的代碼打包成“等 Promise 落定后繼續(xù)執(zhí)行”的續(xù)體。引擎通常會(huì)把函數(shù)體改寫成狀態(tài)機(jī)風(fēng)格的實(shí)現(xiàn)每次 await 都是一次掛起和恢復(fù)async function loadUser() { try { const data await slowFetch(); // 掛起當(dāng)前函數(shù)控制權(quán)交回主線程 return data; // slowFetch 落定后恢復(fù)執(zhí)行 } catch (err) { console.error(加載失敗, err); return null; } } loadUser().then((data) { if (data) { console.log(拿到了數(shù)據(jù)); } });await 不是“把異步變同步”而是“把后面的代碼注冊(cè)成 then 回調(diào)”。好處是書寫順序恢復(fù)了同步直覺try/catch 能像抓同步異常一樣處理異步錯(cuò)誤。代價(jià)是很多人把 await 用成了串行循環(huán)里逐個(gè) await或者在兩個(gè)互不依賴的請(qǐng)求上依次等待明明可以并行卻退化成排隊(duì)。兩個(gè)請(qǐng)求互不依賴時(shí)應(yīng)該用 Promise.all 發(fā)起并行再統(tǒng)一 await// 并行發(fā)起兩個(gè)請(qǐng)求全部落定后一次性解包 const [user, posts] await Promise.all([slowFetchUser(), slowFetchPosts()]);Promise.all 接收一個(gè) Promise 數(shù)組返回一個(gè)新 Promise全部落定后把結(jié)果按序解包成數(shù)組。它還有一個(gè)常用變體 Promise.allSettled等待所有請(qǐng)求結(jié)束而不提前失敗適合“部分失敗也能繼續(xù)”的場(chǎng)景。5.4 避坑異步代碼里最常見的四個(gè)翻車現(xiàn)場(chǎng)第一個(gè)是循環(huán)閉包問題老生常談但每次都會(huì)再犯先把代碼擺出來for (var i 0; i 3; i) { setTimeout(function () { console.log(i); // 3 3 3不是 0 1 2 }, 0); } for (let i 0; i 3; i) { setTimeout(function () { console.log(i); // 0 1 2 }, 0); }現(xiàn)象第一個(gè)循環(huán)打印三個(gè) 3。原因var 是函數(shù)作用域三個(gè)回調(diào)共享同一個(gè)變量 i回調(diào)執(zhí)行時(shí) i 已經(jīng)走到 3。解決改用 let每次迭代都會(huì)創(chuàng)建一個(gè)新的塊級(jí)綁定三個(gè)閉包各持一個(gè)副本。這是上一章閉包機(jī)制的直接應(yīng)用也是 var 時(shí)代用 IIFE 手動(dòng)造作用域才能解決的老問題。第二個(gè)坑是 Promise 沒有 catch?，F(xiàn)象接口失敗時(shí)頁面毫無反應(yīng)控制臺(tái)出現(xiàn) unhandledrejection。原因reject 之后沒有任何 handler 接住錯(cuò)誤異常懸空。解決每條 then 鏈尾部補(bǔ) .catch或者用 async/await 加 try/catch 覆蓋。第三個(gè)坑更隱蔽try/catch 包不住 setTimeout 回調(diào)里的異常。async function bad() { try { setTimeout(() { throw new Error(boom); }, 0); } catch (e) { console.log(根本捕獲不到); } }現(xiàn)象回調(diào)拋錯(cuò)catch 完全沒執(zhí)行。原因setTimeout 的回調(diào)在另一個(gè)任務(wù)里運(yùn)行不在 try 的同步路徑上異常只能冒泡到全局。解決把異步操作封裝成 Promise在 async 函數(shù)里 await 它異常才能沿 Promise 鏈被 catch 接住。判斷標(biāo)準(zhǔn)很簡(jiǎn)單catch 只能接住“同一條執(zhí)行路徑”上的錯(cuò)誤跨任務(wù)、跨隊(duì)列的異常不會(huì)自動(dòng)匯入。第四個(gè)坑是請(qǐng)求競(jìng)態(tài)。現(xiàn)象用戶快速點(diǎn)擊按鈕請(qǐng)求發(fā)了三四次先發(fā)出的慢響應(yīng)后返回把新結(jié)果覆蓋了。原因沒有對(duì)過期請(qǐng)求做隔離。解決用 AbortController 取消之前的請(qǐng)求或者用一個(gè)請(qǐng)求序號(hào)/標(biāo)志位只采納最新一次響應(yīng)。這在搜索輸入聯(lián)想里幾乎是必踩的不處理就是“打一個(gè)字彈一堆舊結(jié)果”。6. 設(shè)計(jì)取舍為什么 var 沒被刪掉以及“不完美”背后的演進(jìn)邏輯把前面五章串起來會(huì)看到一個(gè)共性JavaScript 幾乎所有“歷史包袱”都不是沒人想改而是不能改。var 的提升和函數(shù)作用域坑多但大量存量網(wǎng)頁依賴這個(gè)行為typeof null返回 object 是個(gè)公認(rèn)的 bug但 null 作為對(duì)象類型“空引用”的語義已經(jīng)寫進(jìn)無數(shù)判斷邏輯。語言標(biāo)準(zhǔn)不能像應(yīng)用代碼一樣發(fā)個(gè)新版本就推倒重來那會(huì)破壞所有現(xiàn)存網(wǎng)頁這是 Web 平臺(tái)不可動(dòng)搖的兼容性底線。所以演進(jìn)策略變成了“加法而不是換血”let/const 是加新聲明方式Promise 和 async/await 是加新語法糖class 是加新寫法——舊東西全部保留新東西在旁邊生長(zhǎng)。這也是為什么今天寫 JavaScript 要同時(shí)掌握兩套心智模型一套解釋老代碼為什么那樣一套指導(dǎo)新代碼怎么寫。單線程事件循環(huán)的選擇也值得重新評(píng)價(jià)。早期瀏覽器不是沒想過多線程操作 DOM但多線程意味著對(duì)同一棵文檔樹要加鎖、要處理并發(fā)訪問的競(jìng)態(tài)復(fù)雜度會(huì)急劇上升。事件循環(huán)放棄并行換取了一個(gè)簡(jiǎn)單可靠的模型任何時(shí)刻只有一段代碼在改狀態(tài)開發(fā)者不需要考慮鎖。代價(jià)是性能上限被單線程卡住但 Web 場(chǎng)景的大量時(shí)間是 I/O 等待非阻塞加回調(diào)把等待時(shí)間讓出來給其他任務(wù)整體吞吐反而比粗糙的加鎖多線程更好。這個(gè)取舍在服務(wù)端同樣成立服務(wù)端運(yùn)行時(shí)生態(tài)放棄多線程并發(fā)模型、擁抱事件循環(huán)和瀏覽器是一脈相承的思路。往深一層看Promise 和 async/await 的演進(jìn)也遵循同一邏輯回調(diào)地獄不是語法問題是控制流表達(dá)能力的不足Promise 把“回調(diào)在什么時(shí)候恢復(fù)”變成可組合的對(duì)象async/await 再把恢復(fù)點(diǎn)寫成同步樣式的代碼。每一層都沒有改變底層的事件循環(huán)只是換了面向開發(fā)者的表達(dá)方式。引擎層面 await 會(huì)被編譯成狀態(tài)機(jī)這件事提醒我評(píng)價(jià)一個(gè)語法特性要看它編譯后是什么而不是表面像什么。從我自己的習(xí)慣說起每次寫完異步代碼我都會(huì)強(qiáng)制自己先在心里走一遍事件循環(huán)的順序——哪段是同步任務(wù)哪個(gè)回調(diào)進(jìn)微任務(wù)哪個(gè)進(jìn)宏任務(wù)然后打印驗(yàn)證一遍執(zhí)行順序。這一步花不了兩分鐘但能擋掉無數(shù)看似難查的競(jìng)態(tài)問題。從那以后我也習(xí)慣了在改 DOM 時(shí)先問“這一次要觸發(fā)重排還是重繪”在處理 Promise 時(shí)先問“這條鏈有沒有人接住錯(cuò)誤”。希望你也能帶著這套機(jī)制去重讀文檔從“記住結(jié)論”變成“推得出結(jié)論”希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取