核心知識(shí)點(diǎn)與實(shí)戰(zhàn)避坑指南:從類型判斷到異步編程)
JS基礎(chǔ)這一塊我估計(jì)是每個(gè)前端人都繞不過去的坎。哪怕你后面用了再多的框架Vue、React、Angular繞來繞去最后啃的其實(shí)還是原生JavaScript這顆硬骨頭。我在帶團(tuán)隊(duì)的時(shí)候發(fā)現(xiàn)一個(gè)規(guī)律基礎(chǔ)語法扎實(shí)的人看框架源碼就像看小說遇到bug也能快速定位基礎(chǔ)不牢的光一個(gè)this指向問題就能折騰一上午。這篇筆記是我自己整理的核心知識(shí)點(diǎn)加上這些年踩過的坑希望能幫新手捋順?biāo)悸芬材軒瓦M(jìn)階的朋友查漏補(bǔ)缺。1. 數(shù)據(jù)類型與類型判斷從底層邏輯到面試高頻坑1.1 基礎(chǔ)數(shù)據(jù)類型詳解JavaScript里數(shù)據(jù)類型分兩大類原始類型Primitive和引用類型Reference。原始類型有七種string、number、boolean、null、undefined、symbol、bigint。引用類型主要就是object包括array、function、date、regexp、map、set這些。這里有個(gè)非常容易踩坑的點(diǎn)typeof null返回的是object這是個(gè)歷史遺留bug從ES1時(shí)代就存在官方也沒打算修。所以判斷null不能依賴typeof要用Object.prototype.toString.call()或者直接 null。再說說number類型。它不是純粹的整數(shù)或浮點(diǎn)數(shù)是雙精度64位二進(jìn)制浮點(diǎn)格式。最經(jīng)典的坑就是0.1 0.2 ! 0.3這個(gè)不用多講了。實(shí)際開發(fā)中遇到金額計(jì)算我一般建議用整數(shù)分來算或者引入decimal.js這類庫。NaN也很特殊typeof NaN返回number但NaN NaN是false。判斷NaN我用Number.isNaN()而不是全局的isNaN()因?yàn)楹笳邥?huì)把字符串也轉(zhuǎn)換了再判斷容易誤判。1.2 typeof與instanceof的適用邊界typeof適合判斷原始類型但區(qū)分不了具體對(duì)象類型。instanceof適合判斷引用類型但有個(gè)問題它能沿著原型鏈往上找。所以如果你有跨iframe的場景instanceof可能失效。我給個(gè)經(jīng)驗(yàn)結(jié)論判斷字符串、數(shù)字、布爾、undefined、symbol、bigint用typeof判斷null用value null判斷數(shù)組用Array.isArray(value)判斷純對(duì)象用Object.prototype.toString.call(value) [object Object]判斷日期用value instanceof Date配合!isNaN(value.getTime())1.3 動(dòng)態(tài)類型與隱式轉(zhuǎn)換的避坑指南JS是動(dòng)態(tài)類型語言變量可以隨意賦不同類型的值。這帶來靈活性的同時(shí)也帶來一堆隱式轉(zhuǎn)換的坑。核心規(guī)則運(yùn)算符如果任一側(cè)是字符串就做字符串拼接其他運(yùn)算符盡量會(huì)把兩邊轉(zhuǎn)成數(shù)字。會(huì)做類型轉(zhuǎn)換不做。我強(qiáng)烈建議項(xiàng)目里全局禁用ESLint規(guī)則eqeqeq打開省去一堆破事。還有一個(gè)常見場景if判斷里0、空字符串、null、undefined、NaN、false都會(huì)被轉(zhuǎn)成false。所以if (someString)這種寫法要小心空字符串也會(huì)走false分支。嚴(yán)謹(jǐn)?shù)呐袛鄳?yīng)該是if (typeof someString string someString.length 0)。2. 函數(shù)與作用域理解閉包和執(zhí)行上下文的本質(zhì)2.1 函數(shù)聲明、函數(shù)表達(dá)式與立即執(zhí)行函數(shù)函數(shù)有三種常見的定義方式它們之間有微妙差異。函數(shù)聲明會(huì)提升hoisting函數(shù)表達(dá)式不會(huì)。提升的意思是在代碼執(zhí)行前解析階段就把函數(shù)名和函數(shù)體綁到了當(dāng)前作用域頂部。所以可以這樣// 函數(shù)聲明可以提前調(diào)用 sayHello(); // 正常運(yùn)行 function sayHello() { console.log(hello); } // 函數(shù)表達(dá)式會(huì)報(bào)錯(cuò)sayHi是undefined sayHi(); // TypeError: sayHi is not a function var sayHi function() { console.log(hi); };因?yàn)関ar聲明的變量會(huì)提升聲明但不會(huì)提升賦值所以調(diào)用時(shí)是undefined自然報(bào)錯(cuò)。立即執(zhí)行函數(shù)IIFE的寫法我常用兩種(function(){ ... })()和(function(){ ... }())。作用就一個(gè)創(chuàng)建一個(gè)獨(dú)立的作用域不污染外部。現(xiàn)在有了塊級(jí)作用域let和constIIFE用得少了但在一些老代碼和某些工具庫封裝里還是會(huì)見到。2.2 閉包的形成機(jī)制與應(yīng)用場景閉包是JS中一個(gè)繞不開的概念。簡單說如果一個(gè)函數(shù)能訪問其外部函數(shù)作用域中的變量那么這個(gè)函數(shù)和它引用變量的組合就是閉包。形成閉包有幾個(gè)必要條件函數(shù)嵌套函數(shù)、內(nèi)部函數(shù)引用外部變量、內(nèi)部函數(shù)被保留下引用。比如function counter() { let count 0; return function() { count; return count; }; } const c1 counter(); const c2 counter(); console.log(c1()); // 1 console.log(c1()); // 2 console.log(c2()); // 1c1和c2各自獨(dú)立的count這里最有意思的細(xì)節(jié)是每調(diào)用一次counter()會(huì)創(chuàng)建一份全新的作用域count不再共享。這也是為什么閉包常被用來做數(shù)據(jù)私有化。閉包有個(gè)性能隱患就是變量無法被垃圾回收因?yàn)橐面溡恢贝嬖凇K匀绻粋€(gè)閉包長期掛在全局變量上它捕獲的對(duì)象會(huì)一直存活。我一般會(huì)建議用完的閉包引用置為null幫GC一把。2.3 作用域鏈與let/const/var的本質(zhì)差異作用域鏈的查找規(guī)則是當(dāng)前作用域找不到就向上一級(jí)找直到全局。全局再找不到非嚴(yán)格模式就隱式創(chuàng)建全局變量這會(huì)污染window嚴(yán)格模式直接報(bào)錯(cuò)。var是函數(shù)作用域let和const是塊級(jí)作用域。塊級(jí)作用域包括if、for、while這些{}包裹的區(qū)域。if (true) { var a 1; let b 2; } console.log(a); // 1 console.log(b); // ReferenceError: b is not definedvar還有個(gè)坑在for循環(huán)里用var聲明的循環(huán)變量會(huì)泄漏到循環(huán)外面而且所有異步回調(diào)共享同一個(gè)變量。用let就沒這個(gè)問題因?yàn)槊看蔚紩?huì)創(chuàng)建新的綁定。這是閉包經(jīng)典面試題的本質(zhì)解法。2.4 this指向規(guī)則與箭頭函數(shù)的例外this的指向在普通函數(shù)里由調(diào)用方式?jīng)Q定有五種規(guī)則默認(rèn)綁定獨(dú)立調(diào)用非嚴(yán)格模式指向全局對(duì)象嚴(yán)格模式是undefined隱式綁定作為對(duì)象方法調(diào)用時(shí)指向這個(gè)對(duì)象顯式綁定call、apply、bind指定thisnew綁定構(gòu)造函數(shù)里this指向新創(chuàng)建的對(duì)象綁定優(yōu)先級(jí)new 顯式 隱式 默認(rèn)箭頭函數(shù)沒有自己的this它繼承外層作用域的this。這個(gè)特性讓它特別適合用在回調(diào)函數(shù)里不用再寫var self this那套了。const obj { name: demo, init() { setTimeout(() { console.log(this.name); // demo箭頭函數(shù)繼承init的this }, 100); } };但如果箭頭函數(shù)在全局作用域定義this就是全局對(duì)象嚴(yán)格模式下也是全局對(duì)象。這個(gè)要注意區(qū)分。3. 運(yùn)算符與流程控制表達(dá)式計(jì)算的優(yōu)先級(jí)陷阱3.1 算術(shù)、比較、邏輯運(yùn)算符的實(shí)際運(yùn)用算術(shù)運(yùn)算符里最復(fù)雜涉及字符串拼接和數(shù)字相加的判斷。和--有前后綴差異前綴先自增再返回值后綴先返回值再自增。這個(gè)在寫循環(huán)或者計(jì)數(shù)器的時(shí)候容易出邊界問題。比較運(yùn)算符有個(gè)經(jīng)典場景比較對(duì)象時(shí)會(huì)先調(diào)用對(duì)象的valueOf()或toString()方法再比較。所以兩個(gè)對(duì)象不管內(nèi)容是否一樣用或比較都是false因?yàn)楸容^的是內(nèi)存引用地址。邏輯運(yùn)算符返回的不一定是布爾值它返回的是操作數(shù)的值。和||是短路運(yùn)算const result a || defaultValue; // 如果a是假值返回defaultValue const value obj obj.name; // 如果obj是空返回undefined避免報(bào)錯(cuò)??空值合并運(yùn)算符是ES2020新增的它只在左側(cè)是null或undefined時(shí)返回右側(cè)值不會(huì)像||那樣把0、空字符串也替換掉。這個(gè)區(qū)別很實(shí)用。3.2 保留兩位小數(shù)與運(yùn)算符優(yōu)先級(jí)處理浮點(diǎn)數(shù)保留兩位小數(shù)我之前常被問。toFixed(2)是最簡單的但有個(gè)坑它返回的是字符串且四舍五入行為和預(yù)期可能不一致底層是浮點(diǎn)數(shù)精度問題。如果只是展示用還好做計(jì)算還是得小心。更穩(wěn)妥的做法function roundToTwo(num) { return Math.round((num Number.EPSILON) * 100) / 100; }Number.EPSILON是用來修正浮點(diǎn)數(shù)誤差的加上它再四舍五入結(jié)果更符合直覺。運(yùn)算符優(yōu)先級(jí)方面最容易出問題的是優(yōu)先級(jí)高于||賦值運(yùn)算符優(yōu)先級(jí)極低。還有三元運(yùn)算符?:的嵌套可讀性很差我一般建議嵌套超過兩層就改寫為if分支。表達(dá)式里的分號(hào)自動(dòng)插入ASI機(jī)制也值得提一句。雖然JS引擎會(huì)自動(dòng)補(bǔ)分號(hào)但某些場景它的策略和你想的不一樣。比如function demo() { return { ok: true }; } // 實(shí)際返回undefined因?yàn)閞eturn后面自動(dòng)補(bǔ)了分號(hào)這種“return換行導(dǎo)致bug”的問題我踩過好機(jī)會(huì)后來習(xí)慣在return后把{放在同一行。3.3 解構(gòu)賦值與展開運(yùn)算符的進(jìn)階用法解構(gòu)賦值真的是提升代碼可讀性的利器。數(shù)組解構(gòu)支持默認(rèn)值、跳過元素、剩余元素const [first, , third, ...rest] [1, 2, 3, 4, 5]; console.log(first); // 1 console.log(third); // 3 console.log(rest); // [4, 5]對(duì)象解構(gòu)支持重命名和默認(rèn)值const { name: username default, age 18 } person;展開運(yùn)算符可以用來做淺拷貝const copy [...arr]、const objCopy {...obj}。但記住只是淺拷貝嵌套對(duì)象還是共享引用。有個(gè)小技巧合并對(duì)象時(shí)Object.assign({}, a, b)和{...a, ...b}在功能上等價(jià)但后者更簡潔。如果屬性值是undefined前者會(huì)忽略后者也會(huì)忽略在對(duì)象字面量展開時(shí)。4. 事件機(jī)制從DOM事件流到委托與自定義事件4.1 DOM事件流的三個(gè)階段事件在瀏覽器里從window出發(fā)經(jīng)過目標(biāo)元素再返回window形成三個(gè)階段捕獲階段、目標(biāo)階段、冒泡階段。addEventListener的第三個(gè)參數(shù)如果傳true或{ capture: true }就是在捕獲階段觸發(fā)默認(rèn)是false在冒泡階段觸發(fā)。我實(shí)際工作中大部分場景都在冒泡階段處理事件因?yàn)樗弦话愕慕换ブ庇X。但focus、blur等事件是不冒泡的如果需要在捕獲階段處理就要用addEventListener配合true。4.2 事件委托的性能與正確姿勢事件委托核心原理是利用事件冒泡把事件監(jiān)聽器掛到父元素上通過event.target判斷實(shí)際觸發(fā)元素。這有兩個(gè)好處性能好監(jiān)聽器少、動(dòng)態(tài)元素?zé)o需重復(fù)綁定。document.querySelector(#list).addEventListener(click, (event) { const target event.target.closest(li); if (!target) return; console.log(target.dataset.id); });這里用closest(li)而不是target.tagName LI是為了處理用戶點(diǎn)到li里面的span這類子元素的情況。closest會(huì)向上查找匹配選擇器更健壯。4.3 Event對(duì)象常用屬性與自定義事件event對(duì)象里我經(jīng)常用的屬性target實(shí)際事件源、currentTarget當(dāng)前綁定監(jiān)聽器的元素、eventPhase當(dāng)前階段、preventDefault()阻止默認(rèn)行為、stopPropagation()阻止冒泡、stopImmediatePropagation()阻止冒泡且阻止同元素上其他監(jiān)聽器執(zhí)行。自定義事件開發(fā)中很有用尤其做組件通信const event new CustomEvent(refresh, { detail: { id: 1 } }); element.dispatchEvent(event);配合detail字段傳數(shù)據(jù)比全局事件總線干凈得多。4.4 瀏覽器事件循環(huán)setTimeout與Promise的執(zhí)行順序事件循環(huán)是理解異步代碼執(zhí)行順序的鑰匙。宏任務(wù)macrotask和微任務(wù)microtask是兩個(gè)隊(duì)列。每次執(zhí)行完一個(gè)宏任務(wù)都會(huì)清空微任務(wù)隊(duì)列再取下一個(gè)宏任務(wù)。setTimeout(() console.log(timeout), 0); Promise.resolve().then(() console.log(promise)); console.log(sync); // 輸出順序sync - promise - timeout微任務(wù)包括Promise.then、MutationObserver、queueMicrotask。渲染和事件處理都發(fā)生在宏任務(wù)之間。所以如果你有數(shù)據(jù)變化的通知放在微任務(wù)里能保證在下次渲染前執(zhí)行。注意事項(xiàng)嵌套的setTimeout層層加深度可能觸發(fā)瀏覽器的嵌套定時(shí)器最小間隔限制5ms但Promise的微任務(wù)沒有這個(gè)限制所以某些循環(huán)用微任務(wù)效率更高。5. 異步編程從回調(diào)地獄到Promise和async/await5.1 Promise的三種狀態(tài)與鏈?zhǔn)秸{(diào)用Promise對(duì)象有三種狀態(tài)pending進(jìn)行中、fulfilled已完成、rejected已失敗。狀態(tài)只能從pending轉(zhuǎn)變到其他兩個(gè)一旦轉(zhuǎn)變就不可逆。鏈?zhǔn)秸{(diào)用的核心規(guī)矩then或catch都會(huì)返回新的Promise所以可以無限鏈下去。then回調(diào)里如果拋異常會(huì)被下一個(gè)catch捕獲如果返回普通值會(huì)被下一個(gè)then接收。一個(gè)容易被忽略的點(diǎn)如果then回調(diào)里返回一個(gè)Promise下一個(gè)then會(huì)等這個(gè)Promise resolve后再執(zhí)行相當(dāng)于展平了一層異步嵌套。5.2 async/await錯(cuò)誤處理的關(guān)鍵技巧async函數(shù)其實(shí)就是生成器加Promise的語法糖。await會(huì)暫停函數(shù)執(zhí)行等待Promise settled后再繼續(xù)。它讓異步代碼看起來像同步代碼但要注意并發(fā)問題。我見過很多項(xiàng)目在請(qǐng)求數(shù)據(jù)時(shí)多個(gè)相互獨(dú)立的請(qǐng)求用了串聯(lián)的await白白浪費(fèi)了大量等待時(shí)間。正確做法是用Promise.allconst [users, posts] await Promise.all([ fetch(/users), fetch(/posts) ]);錯(cuò)誤處理方面try/catch配合await是基本操作。但還有個(gè)技巧await一個(gè)被rejected的Promise異常會(huì)被拋出如果沒有try/catch包裹會(huì)變成unhandledrejection可能靜默失敗。所以規(guī)范做法是每個(gè)await路徑都要有兜底或者在函數(shù)內(nèi)部統(tǒng)一catch后轉(zhuǎn)成正常返回值。5.3 并發(fā)控制與Promise.allSettledPromise.all有個(gè)缺陷只要有一個(gè)rejected整個(gè)Promise直接變成rejected其他結(jié)果都拿不到。如果某個(gè)請(qǐng)求失敗你就全丟了。這時(shí)候用Promise.allSettled更適合const results await Promise.allSettled([p1, p2, p3]); // results里每項(xiàng)是 {status: fulfilled, value} 或 {status: rejected, reason}還有Promise.race只取最快的那個(gè)結(jié)果常用于超時(shí)控制const withTimeout Promise.race([ fetch(/data), new Promise((_, reject) setTimeout(() reject(new Error(timeout)), 5000)) ]);注意timer要clearTimeout清理不然定時(shí)器還會(huì)觸發(fā)只是reject被忽略了而已。6. 運(yùn)行時(shí)報(bào)錯(cuò)排查與console調(diào)試技巧6.1 常見運(yùn)行時(shí)錯(cuò)誤分類前端錯(cuò)誤大致分幾類語法錯(cuò)誤代碼無法解析整個(gè)腳本都不會(huì)執(zhí)行引用錯(cuò)誤ReferenceError變量未定義或不在作用域類型錯(cuò)誤TypeError訪問了undefined的屬性、調(diào)用了不是函數(shù)的東西范圍錯(cuò)誤RangeError數(shù)組長度非法、棧溢出自定義錯(cuò)誤類可以用throw new Error(xxx)主動(dòng)拋出有一個(gè)高頻錯(cuò)誤Cannot read properties of undefined (reading xxx)。排查思路是找到哪個(gè)對(duì)象是undefined往上回溯它的賦值來源。我會(huì)在懷疑點(diǎn)用console.log或debugger打斷點(diǎn)逐步確認(rèn)。6.2 console全家桶的實(shí)用姿勢console.log就不說了。其他幾個(gè)很有用console.log(%c..., color:#f00;font-size:20px)帶顏色輸出排查分組信息很方便console.table(arr)把數(shù)組或?qū)ο笠员砀裥问酱蛴】唇Y(jié)構(gòu)化數(shù)據(jù)一目了然console.time/console.timeEnd測代碼塊執(zhí)行時(shí)間console.trace()打印調(diào)用棧比log更強(qiáng)大能查到函數(shù)是哪里被調(diào)用的console.assert(false, msg)條件為false時(shí)打印消息適合在循環(huán)里做斷言6.3 瀏覽器開發(fā)者工具Sources斷點(diǎn)調(diào)試用斷點(diǎn)調(diào)試比console.log效率高很多。在Sources面板里點(diǎn)擊行號(hào)即可打斷點(diǎn)。然后重點(diǎn)關(guān)注幾個(gè)面板Scope面板查看當(dāng)前作用域變量、閉包變量Call Stack面板查看完整調(diào)用棧有助于定位調(diào)用源頭Watch面板添加你關(guān)注的表達(dá)式實(shí)時(shí)變化一目了然條件斷點(diǎn)很實(shí)用比如想要在count大于5時(shí)才斷住右鍵斷點(diǎn)編輯條件count 5即可省去大量手動(dòng)跳過干擾步驟。7. 常用開發(fā)工具與瀏覽器API擴(kuò)展7.1 嚴(yán)格模式與ESLint的必要性文件頂部寫use strict;或者通過ESM模塊天然啟用嚴(yán)格模式后JS會(huì)避免一些靜默錯(cuò)誤未聲明變量直接賦值會(huì)報(bào)錯(cuò)、this在全局不再指向window、delete不可刪除屬性會(huì)報(bào)錯(cuò)。配合ESLint建議規(guī)則集equeeq禁用、no-var禁用var、no-unused-vars禁未使用變量、prefer-const優(yōu)先const。這些規(guī)則能攔截很多低級(jí)錯(cuò)誤。7.2 JSON序列化與深拷貝的實(shí)現(xiàn)處理JSON字符串時(shí)有個(gè)經(jīng)典坑JSON.stringify遇到undefined、函數(shù)、symbol值會(huì)直接跳過這些屬性。NaN和Infinity會(huì)變成null。所以不能把JSON當(dāng)普通對(duì)象的通用序列化方式。深拷貝除了引庫或JSON.parse(JSON.stringify(obj))外有局限不支持Date、RegExp、循環(huán)引用可以用structuredClone支持循環(huán)引用和更多類型。它是瀏覽器原生API能在window和worker之間傳遞數(shù)據(jù)對(duì)性能要求高的場景可以開transfer列表。7.3 瀏覽器存儲(chǔ)方案對(duì)比cookies、localStorage與IndexedDB本地存儲(chǔ)常用的三種特性localStoragesessionStoragecookie大小約5MB約5MB約4KB生命周期永久除非清除標(biāo)簽頁關(guān)閉即清除根據(jù)expires/Max-Age請(qǐng)求自動(dòng)攜帶否否是同域數(shù)據(jù)格式字符串字符串字符串cookie會(huì)自動(dòng)附加到請(qǐng)求頭所以盡量只存會(huì)話標(biāo)識(shí)不要存業(yè)務(wù)數(shù)據(jù)。localStorage是同步的寫入大量數(shù)據(jù)時(shí)可能阻塞主線程。IndexedDB是異步的適合存儲(chǔ)結(jié)構(gòu)化大對(duì)象。讀取localStorage有個(gè)注意點(diǎn)鍵不存在時(shí)返回null讀取的結(jié)果要用JSON.parse并包一層try/catch因?yàn)橐坏?shù)據(jù)損壞或被篡改解構(gòu)會(huì)直接拋異常應(yīng)用直接崩潰。8. 瀏覽器兼容性實(shí)踐從差異化封裝到構(gòu)建降級(jí)8.1 兼容性判斷基礎(chǔ)判斷一個(gè)API能不能用標(biāo)準(zhǔn)做法是查Can I Use或直接看MDN的瀏覽器兼容性表。但日常開發(fā)時(shí)工具鏈的處理可能更高效Babel把ES6語法轉(zhuǎn)成ES5但要明白語法能轉(zhuǎn)API問題它管不了。Promise、Array.from這些需要polyfill打包工具會(huì)把代碼轉(zhuǎn)換成目標(biāo)瀏覽器能跑的樣子但targets配置對(duì)了才有效8.2 特性檢測代替瀏覽器檢測一個(gè)正確的思路是“特性檢測”而非“瀏覽器版本檢測”。比如判斷是否支持IntersectionObserver做懶加載if (IntersectionObserver in window) { // 新瀏覽器 } else { // 老瀏覽器 }不推薦用navigator.userAgent判斷因?yàn)樽址梢员淮鄹亩倚掳姹緸g覽器特征一直在變。用特性檢測寫出來的代碼天然就更面向未來。9. Canvas與基礎(chǔ)算法從圖形繪制到性能調(diào)優(yōu)9.1 Canvas基礎(chǔ)繪制流程Canvas的起點(diǎn)很簡單獲取2D上下文然后開始繪制。const canvas document.getElementById(myCanvas); const ctx canvas.getContext(2d); ctx.fillStyle #3498db; ctx.fillRect(50, 50, 100, 100);但有個(gè)細(xì)節(jié)坑canvas的寬高屬性和CSS寬高不一樣。如果只想用CSS控制顯示大小必須同時(shí)設(shè)置canvas.width和height與CSS一致否則會(huì)出現(xiàn)畫布內(nèi)容模糊或被拉伸問題。繪制路徑beginPath、moveTo、lineTo、closePath、stroke或fill。beginPath之后別忘了每次重繪時(shí)清屏最常見的動(dòng)畫污染問題是沒調(diào)用clearRect導(dǎo)致上一幀的圖像殘留。用requestAnimationFrame做動(dòng)畫它比setInterval更平滑且能跟隨顯示刷新率。同時(shí)注意requestAnimationFrame在每個(gè)宏任務(wù)里只會(huì)執(zhí)行一次如果在里面又注冊一幀還能繼續(xù)下一幀循環(huán)。9.2 高頻操作的數(shù)據(jù)結(jié)構(gòu)與算法基礎(chǔ)寫交互組件時(shí)數(shù)據(jù)結(jié)構(gòu)的選擇直接影響性能。常見場景大量列表篩選用filter遍歷沒問題但如果超過萬級(jí)用Set或Map做索引更快防抖與節(jié)流防抖是等用戶停止輸入再執(zhí)行節(jié)流是固定時(shí)間間隔執(zhí)行一次。這兩種都是性能優(yōu)化里非常基礎(chǔ)的模式function debounce(fn, wait) { let timer null; return function(...args) { clearTimeout(timer); timer setTimeout(() fn.apply(this, args), wait); }; }深比較如果對(duì)象層級(jí)復(fù)雜沒必要手寫用JSON.stringify比較粗略可以但屬性順序不同會(huì)導(dǎo)致誤判。更嚴(yán)謹(jǐn)?shù)氖沁f歸比較每個(gè)屬性。9.3 跨平臺(tái)開發(fā)中的JavaScript運(yùn)行環(huán)境差異JavaScript不只跑在瀏覽器里。Node.js環(huán)境里沒有window、document而是有process、Buffer。有些桌面開發(fā)框架中渲染進(jìn)程和主進(jìn)程之間通信也和瀏覽器不同。還有一個(gè)“運(yùn)行環(huán)境差異”的典型場景Object的遍歷順序。整數(shù)鍵按升序遍歷字符串鍵按插入順序遍歷symbol鍵最后。這套規(guī)則在Node和瀏覽器里一致但跨引擎如果實(shí)現(xiàn)差異就容易出bug。遇到跨環(huán)境代碼建議每個(gè)環(huán)境都做一遍冒煙測試尤其注意typeof window undefined的判斷用來區(qū)分瀏覽器和Node。10. 框架與工具鏈視角如何反哺基礎(chǔ)語法10.1 框架外的JavaScript依然要掌握的核心API現(xiàn)在很多開發(fā)者一上來就學(xué)框架忽略了原生能力。但無論什么框架底層都依賴這些APIObject.keys/Object.values/Object.entries遍歷對(duì)象的三種方式Array.prototype.map/filter/reduce/forEach函數(shù)式操作數(shù)據(jù)String.prototype.includes/startsWith/padStart字符串處理URLSearchParams讀寫URL參數(shù)FormData處理表單提交這些API是框架的基石也是面試?yán)锾硬贿^的重點(diǎn)。刷一遍文檔再結(jié)合小項(xiàng)目用一用基本上就能融會(huì)貫通。10.2 組件化開發(fā)中如何利用基礎(chǔ)語法優(yōu)化狀態(tài)管理狀態(tài)管理無論用什么庫本質(zhì)還是JavaScript對(duì)象和數(shù)組的變更檢測。有些框架依賴數(shù)據(jù)劫持Vue的reactive有些靠不可變數(shù)據(jù)React的setState。如果你用React理解不可變更新很重要不能直接修改state對(duì)象里的屬性要返回新對(duì)象。這里用展開運(yùn)算符就比深拷貝高效setState(prev ({ ...prev, field: newValue }));如果你用Vue要小心響應(yīng)式丟失用索引直接修改數(shù)組項(xiàng)、添加新的對(duì)象屬性可能不會(huì)被偵測到。正確姿勢是用Vue.set或$set或者干脆整體替換。10.3 框架時(shí)代為什么還要夯實(shí)基礎(chǔ)我經(jīng)常和新同事說框架能幫你解決80%的重復(fù)勞動(dòng)但剩下的20%——性能優(yōu)化、復(fù)雜交互、內(nèi)核級(jí)調(diào)試——必需原生JavaScript的功底。很多框架的源碼其實(shí)都是原生語法的高級(jí)運(yùn)用比如Vue的Object.defineProperty和Proxy的配合、React的鏈表結(jié)構(gòu)調(diào)度。你如果連Object.defineProperty的特性都不清楚讀源碼就像在看天書。另外無論是npm install的依賴升級(jí)還是底層API的兼容降級(jí)都有可能需要手動(dòng)處理原生暴露出來的差異?;A(chǔ)語法越扎實(shí)處理這些邊界情況時(shí)就越從容。寫在最后的一些體會(huì)回頭再看這份筆記我刪掉了很多教科書式的贅述盡量把每個(gè)知識(shí)點(diǎn)都和我實(shí)際寫代碼時(shí)踩過的坑掛鉤。尤其是數(shù)據(jù)類型判斷、事件委托、異步并發(fā)、Canvas寬度設(shè)置、Object.defineProperty響應(yīng)式這些幾乎每個(gè)月都會(huì)在項(xiàng)目里遇到相關(guān)的問題?;A(chǔ)語法從來不是背出來的是在寫代碼、出bug、修bug的過程中慢慢內(nèi)化的。如果這份筆記能幫你少走幾個(gè)彎路或者在工作里理清某個(gè)模糊點(diǎn)我就覺得值了。JS這條路很長保持好奇多敲多練才是唯一的捷徑。