我很少公開說(shuō)這種話但學(xué) JavaScript 這件事值得每個(gè)寫代碼的人認(rèn)真對(duì)待。倒不是因?yàn)樗悄姆N“最好的語(yǔ)言”而是它的應(yīng)用范圍實(shí)在太廣瀏覽器里的頁(yè)面交互、服務(wù)端的 Node.js 中間層、小程序、桌面端工具、甚至數(shù)據(jù)庫(kù)的存儲(chǔ)函數(shù)里都能看到它的影子。你說(shuō)的“javascript”如果只是停留在聽說(shuō)過(guò)、看過(guò)幾段解法代碼的程度那你會(huì)發(fā)現(xiàn)很多項(xiàng)目用的時(shí)候特別順手、一換場(chǎng)景就完全懵圈。這篇文章就是想把 JavaScript 最核心的地基部分包括數(shù)據(jù)類型判斷、函數(shù)、事件、報(bào)錯(cuò)排查、字符串處理這些從頭到尾拆開講一遍再用幾個(gè)真實(shí)場(chǎng)景把它串起來(lái)。這篇文章沒(méi)有故作高深的理論堆疊講的就是我在實(shí)際項(xiàng)目里反復(fù)用到、反復(fù)踩坑、最后沉淀下來(lái)的理解。不管是剛打算入門前端的新手還是寫后端但經(jīng)常被 JS 卡住的同學(xué)又或者是在 iOS、ETL 工具里被迫和 JavaScript 打交道的人都可以拿它當(dāng)一份實(shí)踐筆記來(lái)讀。碰到一個(gè)知識(shí)點(diǎn)的時(shí)候我會(huì)直接說(shuō)明為什么要這么做這么做解決了什么問(wèn)題。我還會(huì)把自己在項(xiàng)目里遇到過(guò)的最典型的錯(cuò)誤和排查思路寫出來(lái)希望能幫你少走幾個(gè)月彎路。1. JavaScript 的項(xiàng)目定位與學(xué)習(xí)路徑設(shè)計(jì)很多人在 JavaScript 上栽跟頭不是智商問(wèn)題是定位問(wèn)題。他們一上來(lái)就想掌握“所有東西”結(jié)果從框架到構(gòu)建工具全都試了一遍仍然不會(huì)寫。這就像一個(gè)人想學(xué)開車卻先去研究發(fā)動(dòng)機(jī)和變速箱方向就錯(cuò)了。你需要的是一條能循序漸進(jìn)、讓每個(gè)知識(shí)點(diǎn)都對(duì)號(hào)入座的路徑。1.1 JavaScript 在技術(shù)棧里的真實(shí)位置我先說(shuō)結(jié)論JavaScript 是一門解釋型、單線程、基于原型繼承的腳本語(yǔ)言。這個(gè)定位決定了它的很多“性格”。因?yàn)榻忉屝退幌?C 和 Java 那樣需要單獨(dú)的編譯步驟寫完之后瀏覽器或 Node 直接就能運(yùn)行開發(fā)效率高但出了問(wèn)題通常只能靠輸出和調(diào)試工具去找沒(méi)有嚴(yán)格的編譯期攔截。因?yàn)閱尉€程它在瀏覽器里只有一個(gè)主線程所有的耗時(shí)代碼都會(huì)阻塞 UI——這也是后來(lái)出現(xiàn)異步模型、事件循環(huán)的原因。因?yàn)榛谠屠^承它的對(duì)象行為方式跟基于類的語(yǔ)言完全不同大家常困惑的this指向問(wèn)題根源就在繼承模型上。一個(gè)常見(jiàn)的誤解是“JavaScript 只能做網(wǎng)頁(yè)特效”。實(shí)際上Node.js 把 JS 帶到了服務(wù)端Electron 把它帶到了桌面應(yīng)用React Native、小程序框架把它帶到了移動(dòng)端。但還是那句話不管外面套了多少層?xùn)|西核心語(yǔ)言能力才是真正能移民的本錢。你用框架寫三年的組件和先在原生 JavaScript 上把邏輯想清楚再寫組件產(chǎn)出的代碼質(zhì)量和排查問(wèn)題的能力差別非常明顯。1.2 構(gòu)建一條適合自己的學(xué)習(xí)主線我把 JavaScript 學(xué)習(xí)分成五層你可以照著看自己卡在哪一層第一層是語(yǔ)言內(nèi)功變量、數(shù)據(jù)類型、運(yùn)算符、流程控制這是任何程序都離不開的基礎(chǔ)。第二層是函數(shù)與作用域函數(shù)聲明、函數(shù)表達(dá)式、箭頭函數(shù)、閉包、作用域鏈。第三層是對(duì)象與原型對(duì)象創(chuàng)建、屬性遍歷、原型鏈、類。第四層是宿主環(huán)境 APIDOM 操作、事件、AJAX這一層跟具體運(yùn)行環(huán)境綁在一起。第五層才是框架工具和工程化React、Vue、構(gòu)建工具、包管理。很多人的問(wèn)題出在跳層學(xué)習(xí)。第二層還沒(méi)弄明白就直接上框架一遇到this指向、閉包造成的內(nèi)存問(wèn)題、事件綁定失效只能靠百度搜索硬湊。我強(qiáng)烈建議你把前四層徹底搞明白再去看框架。框架更新?lián)Q代很快但語(yǔ)言核心十多年前就是這樣掌握后長(zhǎng)期受用。2. 數(shù)據(jù)類型判斷與字符串處理最容易被忽視的硬功夫?qū)?JavaScript 這些年我最大的感悟之一就是越基礎(chǔ)的東西越能拉開水平差距。很多人寫代碼到一定階段會(huì)陷入一種奇怪的狀態(tài)——組件寫得挺熟但讓他判斷一個(gè)值到底是什么類型、處理一段用戶輸入的字符串轉(zhuǎn)換反而要翻半天 MDN 文檔。2.1 從 typeof 開始的類型判斷體系JavaScript 的數(shù)據(jù)類型從 ECMAScript 標(biāo)準(zhǔn)來(lái)看分為原始類型和引用類型。原始類型包括string、number、boolean、undefined、null、symbol、bigint引用類型本質(zhì)上是對(duì)象包括了普通對(duì)象、數(shù)組、函數(shù)、日期、正則等等。最直接的判斷方式是typeof操作符typeof hello; // string typeof 42; // number typeof true; // boolean typeof undefined; // undefined typeof Symbol(id); // symbol typeof 123n; // bigint這里有一個(gè)著名的歷史坑typeof null返回的是object。原因是早期 JavaScript 實(shí)現(xiàn)中類型標(biāo)記和空指針標(biāo)記重合了這個(gè)行為為保證兼容一直保留到現(xiàn)在。所以如果你想判斷一個(gè)變量是否為null不能用typeof最簡(jiǎn)單的寫法是value null。typeof對(duì)多數(shù)引用類型都會(huì)返回object包括數(shù)組這在實(shí)際開發(fā)中不夠用。我經(jīng)?？吹叫率钟胻ypeof arr array去判斷數(shù)組結(jié)果一路object心態(tài)直接崩掉。數(shù)組判斷要用Array.isArray(arr)這個(gè)方法已經(jīng)是現(xiàn)代 JavaScript 里最可靠的數(shù)組判斷方式。那普通對(duì)象和函數(shù)的判斷呢函數(shù)的typeof會(huì)返回function這個(gè)比較特殊可以用來(lái)判斷函數(shù)類型。但如果你想?yún)^(qū)分“普通對(duì)象”“日期對(duì)象”“正則對(duì)象”就需要另一個(gè)更底層的武器Object.prototype.toString。Object.prototype.toString.call([]); // [object Array] Object.prototype.toString.call({}); // [object Object] Object.prototype.toString.call(new Date()); // [object Date] Object.prototype.toString.call(/abc/); // [object RegExp] Object.prototype.toString.call(null); // [object Null]Object.prototype.toString.call是內(nèi)置的通用判斷方案因?yàn)樗x取的是對(duì)象內(nèi)部的Symbol.toStringTag屬性不依賴構(gòu)造函數(shù)的指向。實(shí)際項(xiàng)目里我通常封裝一個(gè)通用函數(shù)function getType(value) { return Object.prototype.toString.call(value).replace(/^\[object (\S)\]$/, $1); } getType([]); // Array getType({}); // Object getType(1); // Number封裝之后你還得額外處理跨窗口iframe場(chǎng)景下的數(shù)組判斷。一個(gè) iframe 里創(chuàng)建的數(shù)組用instanceof Array在某些舊環(huán)境會(huì)失效但Array.isArray和上面這個(gè)toString方案不會(huì)。這是一個(gè)偏冷門但非常實(shí)用的排查點(diǎn)。2.2 typeof null 的歷史問(wèn)題與 instanceof 的使用邊界再往下說(shuō)instanceof。instanceof判斷的是對(duì)象的原型鏈上是否有某個(gè)構(gòu)造函數(shù)的 prototype。它雖然好用但使用邊界比想象中窄得多。[] instanceof Array; // true {} instanceof Object; // true function test() {} instanceof Function; // true問(wèn)題在于它不是靠“類型標(biāo)記”判斷而是靠“對(duì)象關(guān)系”判斷。如果原型鏈被修改過(guò)或者對(duì)象來(lái)自另一個(gè)執(zhí)行上下文結(jié)果就會(huì)出乎意料。所以判斷原始類型不要用instanceof判斷對(duì)象的精確類型更推薦Object.prototype.toString.call。一段相對(duì)完整的類型判斷可以這樣處理function isPlainObject(value) { if (value null || typeof value ! object) return false; const proto Object.getPrototypeOf(value); return proto Object.prototype || proto null; }這個(gè)寫法在判斷“純普通對(duì)象”時(shí)比直接拿 toString 結(jié)果比對(duì)更穩(wěn)因?yàn)樗懦撕瘮?shù)、數(shù)組、日期以及通過(guò)Object.create(null)創(chuàng)建的無(wú)原型對(duì)象。這段代碼我在寫工具函數(shù)和參數(shù)校驗(yàn)時(shí)經(jīng)常用省掉了無(wú)數(shù)隱性 bug。2.3 字符串操作的實(shí)用高頻方法附帶避坑提示字符串是前端開發(fā)里打交道最多的數(shù)據(jù)類型之一。用戶輸入、接口返回、路徑拼接、模板渲染幾乎全都離不開它。我把自己項(xiàng)目中用過(guò)頻率最高的方法整理成了一張參考表方法作用注意點(diǎn)split(sep)按分隔符拆成數(shù)組超過(guò)一個(gè)字符時(shí)會(huì)整體匹配不是逐字符拆分indexOf(sub)查找子串位置返回 -1 表示未找到全等匹配區(qū)分大小寫includes(sub)是否包含子串返回布爾值比 indexOf 更語(yǔ)義化replace(reg, new)替換匹配內(nèi)容用字符串時(shí)只替換第一個(gè)全局需正則加gslice(start, end)截取片段支持負(fù)數(shù)不會(huì)修改原字符串toUpperCase()/toLowerCase()大小寫轉(zhuǎn)換需要注意 locale 場(chǎng)景如土耳其語(yǔ)trim()去首尾空白不會(huì)去掉字符串內(nèi)部的空格padStart(length, 0)補(bǔ)位常用于格式化參數(shù)一是補(bǔ)足后的總長(zhǎng)度我踩過(guò)最深的坑是replace配合字符串參數(shù)時(shí)只替換第一個(gè)匹配項(xiàng)。例如2023-10-10.replace(-, /)得到的是2023/10-10第二個(gè)連字符沒(méi)被替換。解決方案是用正則的全局標(biāo)志2023-10-10.replace(/-/g, /)。還有一個(gè)讓很多人懵圈的點(diǎn)字符串的length和 Unicode 字符長(zhǎng)度不一致。中文沒(méi)問(wèn)題但遇到 emoji.length; // 2因?yàn)?emoji 用了兩個(gè)碼元代理對(duì)。如果要做“按字符截?cái)唷敝苯佑胹lice可能會(huì)把 emoji 截成亂碼?，F(xiàn)代 JavaScript 提供了Intl.Segmenter或展開運(yùn)算符來(lái)解決這個(gè)問(wèn)題例如[..., 1].length能正確統(tǒng)計(jì)可見(jiàn)字符個(gè)數(shù)。這個(gè)小細(xì)節(jié)在用戶昵稱、文案字?jǐn)?shù)校驗(yàn)場(chǎng)景里非常關(guān)鍵常規(guī)的value.length會(huì)把用戶的 emoji 重復(fù)計(jì)數(shù)導(dǎo)致提示信息完全錯(cuò)誤。我建議你在項(xiàng)目初始化階段就把這些字符串處理的工具函數(shù)封裝到一個(gè) util 文件里而不是散落在各個(gè)組件中。前期多花半小時(shí)后面能省下十幾個(gè)小時(shí)的排錯(cuò)時(shí)間。3. 函數(shù)從聲明方式到閉包徹底搞懂 this 指向熱詞里“javascript函數(shù)”“js函數(shù)”出現(xiàn)頻率很高。其實(shí)函數(shù)在 JavaScript 里不是簡(jiǎn)單的“可調(diào)用代碼塊”它本身是對(duì)象、可以賦值、可以傳遞、可以被返回。為了理解這一點(diǎn)我們得先把視線從“調(diào)用”挪到“函數(shù)作為值”這個(gè)核心思路上。3.1 三種函數(shù)聲明方式的差異JavaScript 中定義一個(gè)函數(shù)常見(jiàn)有三種寫法// 1. 函數(shù)聲明 function add(a, b) { return a b; } // 2. 函數(shù)表達(dá)式 const add2 function(a, b) { return a b; }; // 3. 箭頭函數(shù) const add3 (a, b) a b;函數(shù)聲明會(huì)存在“提升”行為你在函數(shù)聲明之前調(diào)用它也成立。因?yàn)榻馕鲭A段函數(shù)聲明就已進(jìn)入作用域。函數(shù)表達(dá)式和箭頭函數(shù)沒(méi)有這種提升必須先賦值再調(diào)用。這是很多新人寫腳本時(shí)遇到ReferenceError: Cannot access xxx before initialization的原因。再往下說(shuō)this。普通函數(shù)里的this取決于調(diào)用方式——作為對(duì)象方法調(diào)用時(shí)this指向該對(duì)象直接調(diào)用時(shí)指向全局對(duì)象嚴(yán)格模式下是 undefined。箭頭函數(shù)完全不是這樣它的this繼承自定義時(shí)所在的外層作用域不會(huì)因?yàn)檎{(diào)用方式而改變。const obj { name: test, normalFn: function() { console.log(this.name); }, arrowFn: () { console.log(this.name); } }; obj.normalFn(); // test obj.arrowFn(); // undefined箭頭函數(shù)適合用在回調(diào)、事件處理器、數(shù)組高階函數(shù)里因?yàn)樗鼙Ａ敉鈱拥膖his。但它不適合做對(duì)象方法也不適合當(dāng)構(gòu)造函數(shù)。這是兩個(gè)規(guī)則建議直接背下來(lái)對(duì)象方法用普通函數(shù)回調(diào)場(chǎng)景優(yōu)先箭頭函數(shù)。3.2 閉包與作用域鏈實(shí)際項(xiàng)目里的理解框架閉包這個(gè)詞被講得玄乎其實(shí)就是“內(nèi)部函數(shù)持有外部函數(shù)作用域變量”的現(xiàn)象。每次一個(gè)函數(shù)被創(chuàng)建它都會(huì)記住自己聲明時(shí)所在的作用域鏈即使外部函數(shù)執(zhí)行完畢只要內(nèi)部函數(shù)還被人引用著外部作用域中的變量就不會(huì)被回收。function createCounter() { let count 0; return function() { count 1; return count; }; } const counter createCounter(); counter(); // 1 counter(); // 2createCounter執(zhí)行完了但count還活著原因就是內(nèi)部匿名函數(shù)已經(jīng)被賦值給counter并且在繼續(xù)使用。閉包特別適合用來(lái)實(shí)現(xiàn)私有狀態(tài)和一次性初始化的配置對(duì)象因?yàn)榫植孔兞刻烊徊粫?huì)被外部直接訪問(wèn)。但閉包也有副作用變量持有時(shí)間變長(zhǎng)如果一個(gè)很大的對(duì)象被閉包引用就會(huì)一直占據(jù)內(nèi)存形成泄漏。排查內(nèi)存問(wèn)題時(shí)head 子里的“Closure”就是閉包引用鏈的意思我看到過(guò)很多次定位到的原因都是某個(gè)回調(diào)把整棵 DOM 節(jié)點(diǎn)或大數(shù)組給閉包住了。正確的做法是閉包只保留你需要的數(shù)據(jù)用完把引用置為null或者干脆在退出前刪除監(jiān)聽器。3.3 回調(diào)地獄、Promise 與 async/await 的關(guān)系函數(shù)在 JavaScript 里還承擔(dān)了異步任務(wù)的組織作用。老代碼里回調(diào)套回調(diào)非常常見(jiàn)經(jīng)常三層縮進(jìn)就看不下去后來(lái)有了 Promise又有了async/await語(yǔ)法糖。理解這條演進(jìn)線比單純背書寫法更有價(jià)值。// Promise 寫法 fetch(/api/user) .then((res) res.json()) .then((data) console.log(data)) .catch((err) console.error(err)); // async/await 寫法 async function loadUser() { try { const res await fetch(/api/user); const data await res.json(); console.log(data); } catch (err) { console.error(err); } }async/await不是取代了 Promise它本身就是基于 Promise 的語(yǔ)法包裝。寫起來(lái)像同步代碼但背后的執(zhí)行機(jī)制還是事件循環(huán)那一套。注意await只能用在async函數(shù)內(nèi)部一旦用錯(cuò)就會(huì)直接報(bào)語(yǔ)法錯(cuò)誤。另外如果你忘記catch被 reject 的 Promise 會(huì)導(dǎo)致 unhandled rejection這在部分環(huán)境下不會(huì)立刻報(bào)錯(cuò)卻會(huì)在翌日拋出難查的異常。建議在所有異步入口套統(tǒng)一錯(cuò)誤處理函數(shù)而不是靠每個(gè)函數(shù)單獨(dú) try/catch。4. 事件機(jī)制與 DOM 操作寫一個(gè)視頻旋轉(zhuǎn)的實(shí)戰(zhàn)案例熱詞里有一個(gè)非常有意思的片段javascript:vdocument.querySelector(video);v.style.rotate-90deg;v.s。這是典型在控制臺(tái)里直接操作 DOM 的玩法?？雌饋?lái)像玩笑其實(shí)涵蓋了 JavaScript 在瀏覽器里最核心的兩個(gè)能力查詢 DOM 節(jié)點(diǎn)、修改樣式。把這條線延伸開就是完整的事件與 DOM 體系。4.1 從 querySelector 到 style 操作看懂這個(gè)視頻旋轉(zhuǎn)腳本我們先解讀這個(gè)腳本的每一部分。const video document.querySelector(video); // 選中頁(yè)面上第一個(gè) video 元素 video.style.rotate -90deg; // 給該元素應(yīng)用 CSS rotate 屬性 video.play(); // 調(diào)起視頻播放 // v.s 是按下自動(dòng)補(bǔ)全后的展開方向?qū)嶋H運(yùn)行時(shí)是某方法或?qū)傩詃ocument.querySelector接受一個(gè) CSS 選擇器返回第一個(gè)匹配的元素。在控制臺(tái)里調(diào)試時(shí)這句話幾乎是萬(wàn)能入口想找按鈕就寫document.querySelector(button)想找輸入框就寫document.querySelector(input)。嚴(yán)格一點(diǎn)可以用querySelectorAll拿全部匹配項(xiàng)再遍歷適合批量操作。style.rotate是新的獨(dú)立 CSS 旋轉(zhuǎn)屬性等價(jià)于transform: rotate(-90deg)。它不屬于transform屬性的交叉寫法而是獨(dú)立的頂層屬性瀏覽器兼容性已經(jīng)很好。如果你在更老的瀏覽器或某類 WebView 里遇到不生效的情況可退回寫video.style.transform rotate(-90deg)。這個(gè)腳本本身沒(méi)什么高深技術(shù)但它演示了一個(gè)常見(jiàn)調(diào)試流程頁(yè)面視頻方向不對(duì) → 選中元素 → 修改樣式屬性 → 肉眼確認(rèn)效果。這套打法在處理臨時(shí)樣式、做頁(yè)面熵測(cè)、審查第三方頁(yè)面時(shí)特別有用。注意不要在生產(chǎn)環(huán)境直接這么干統(tǒng)一定義類名和 CSS 變量才是正路。4.2 事件流捕獲、目標(biāo)、冒泡與實(shí)際應(yīng)用有了 DOM就會(huì)有事件。瀏覽器里的事件模型有三個(gè)階段捕獲階段從根節(jié)點(diǎn)往下走、目標(biāo)階段到達(dá)觸發(fā)元素、冒泡階段從目標(biāo)元素向上回溯。document.querySelector(button).addEventListener(click, handleClick, false);第三個(gè)參數(shù)傳false表示在冒泡階段處理傳true表示捕獲階段。絕大多數(shù)業(yè)務(wù)場(chǎng)景用冒泡就夠了。但如果你碰到要求“父容器先響應(yīng)”的場(chǎng)景比如攔截子元素點(diǎn)擊事件做日志上報(bào)捕獲階段就有它的價(jià)值。事件代理是一種最常見(jiàn)的冒泡應(yīng)用給父容器統(tǒng)一綁定事件利用冒泡機(jī)制處理所有符合條件的子元素。document.querySelector(.list)?.addEventListener(click, (event) { const target event.target.closest(.item); if (target) { console.log(點(diǎn)擊了 item:, target.dataset.id); } });這樣做的好處是新增的子元素不需要再單獨(dú)綁定事件壞處是如果事件目標(biāo)層級(jí)過(guò)深需要closest來(lái)判斷目標(biāo)是否匹配。event.target永遠(yuǎn)指向最里層被點(diǎn)擊的元素和event.currentTarget當(dāng)前綁定元素區(qū)分開這個(gè)細(xì)節(jié)是大量調(diào)試問(wèn)題的分水嶺。4.3 DOM 操作的最佳實(shí)踐減少重排避免性能炸裂操作 DOM 本身不慢慢的是引起瀏覽器重新布局reflow和重新繪制repaint。這就像你裝修一個(gè)房間每改一個(gè)家具的位置就重新量一次全屋尺寸代價(jià)極高。高頻操作批量修改樣式時(shí)可以把元素先隱藏、改完再顯示或者使用requestAnimationFrame合并視覺(jué)更新。更推薦的手段是直接操作類名// 不推薦多次樣式寫入 el.style.width 100px; el.style.height 100px; el.style.left 50px; // 推薦一次性切類 el.classList.add(active);框架出現(xiàn)之后很多人直接跳過(guò)了原生 DOM 操作的學(xué)習(xí)覺(jué)得框架內(nèi)部都處理好了。但恰恰是框架內(nèi)部也在做 DOM diff 和更新調(diào)度你只有理解了原生 DOM 的更新代價(jià)才能理解為什么虛擬 DOM 能把“重排范圍”縮小為什么列表 key 的變更會(huì)引發(fā)整個(gè)列表的重新渲染。這是從“會(huì)用框架”到“看得懂框架”的關(guān)鍵一環(huán)。5. 運(yùn)行時(shí)報(bào)錯(cuò)排查把異常當(dāng)作理解代碼的入口熱詞里“javascript運(yùn)行時(shí)報(bào)錯(cuò)”幾乎是每個(gè) JS 開發(fā)者每日相伴的課題。很多人一打開控制臺(tái)看到紅色報(bào)錯(cuò)就慌其實(shí)報(bào)錯(cuò)是最有價(jià)值的東西它直接告訴你問(wèn)題位置和類型比你盲猜準(zhǔn)得多。5.1 五類常見(jiàn)運(yùn)行時(shí)錯(cuò)誤與排查思路JavaScript 運(yùn)行時(shí)錯(cuò)誤主要有語(yǔ)法錯(cuò)誤、引用錯(cuò)誤、類型錯(cuò)誤、范圍錯(cuò)誤、以及 URI 相關(guān)錯(cuò)誤。日常開發(fā)中前四個(gè)最常出現(xiàn)我整理成一張速查表錯(cuò)誤類型典型信息常見(jiàn)原因排查方向SyntaxErrorUnexpected token括號(hào)不匹配、字符串引號(hào)未閉合看報(bào)錯(cuò)行號(hào)附近的縮進(jìn)和標(biāo)點(diǎn)ReferenceErrorxxx is not defined變量未聲明或作用域外引用檢查是否 import、是否拼錯(cuò)、是否在函數(shù)外調(diào)用TypeErrorCannot read properties of null對(duì) null/undefined 取值斷點(diǎn)查看變量實(shí)際值加空值保護(hù)TypeErrorxxx is not a function變量類型不是函數(shù)就調(diào)用打印typeof xxx確認(rèn)RangeErrorInvalid array length數(shù)組長(zhǎng)度非法或遞歸溢出檢查遞歸終止條件其中ReferenceError有一個(gè)變體很坑你訪問(wèn)一個(gè)已聲明但還沒(méi)初始化的let變量時(shí)報(bào)的錯(cuò)誤叫“Cannot access x before initialization”但它本質(zhì)上也因塊級(jí)作用域的暫時(shí)性死區(qū)產(chǎn)生。你只要記住一句let和const變量必須在聲明之后才能用。5.2 調(diào)試工具與 console 的正確用法調(diào)試不是靠猜而是靠證據(jù)。我看過(guò)太多同事在代碼里雜七雜八地塞 console.log然后找不到問(wèn)題。推薦的做法是分類使用console.log(); // 常規(guī)過(guò)程日志 console.info(); // 信息性內(nèi)容 console.warn(); // 潛在風(fēng)險(xiǎn) console.error(); // 錯(cuò)誤場(chǎng)景 console.table(); // 數(shù)組或?qū)ο罅斜泶蛴〕杀砀裾{(diào)試復(fù)雜邏輯時(shí)不要只說(shuō)“到這步了”把變量名和數(shù)據(jù)一起打出來(lái)console.log(user data:, user)。數(shù)據(jù)多了可以直接用斷點(diǎn)調(diào)試在瀏覽器 Sources 面板里點(diǎn)行號(hào)打斷點(diǎn)然后刷新頁(yè)面單步執(zhí)行每一步都能看到作用域里的變量值。這是定位問(wèn)題的“正面戰(zhàn)場(chǎng)”。// 有一個(gè)我很常用的組合 try { const data JSON.parse(rawValue); doSomething(data); } catch (err) { console.error(parse failed, rawValue , rawValue, err); }把出錯(cuò)時(shí)的原始數(shù)據(jù)也打印出來(lái)比只打印錯(cuò)誤對(duì)象有用得多。后續(xù)排查時(shí)缺上下文是最痛苦的原始數(shù)據(jù)就是最關(guān)鍵的上下文。5.3 錯(cuò)誤處理的最佳實(shí)踐不吞異常、不裸奔處理錯(cuò)誤最差的方案是try/catch之后什么都不做。我有一個(gè)原則catch 里至少要有一個(gè)console.error并且要決定“這個(gè)錯(cuò)誤是直接給用戶提示還是要繼續(xù)向上拋”。給用戶提示的用專門的錯(cuò)誤提示層要排查的保留堆棧和上下文信息。async function loadConfig() { try { const res await fetch(/api/config); if (!res.ok) { throw new Error(HTTP ${res.status}); } return await res.json(); } catch (err) { console.error([loadConfig] failed, err); return null; } }前端代碼不要輕易在 catch 里用alert因?yàn)閺棿绑w驗(yàn)很差而且用戶也看不懂底層錯(cuò)誤碼。更合理的做法是統(tǒng)一記錄錯(cuò)誤為一個(gè)狀態(tài)渲染階段去展示合適的文案。接口層面建議用“錯(cuò)誤邊界組件”這一類機(jī)制兜底避免一個(gè)子模塊崩潰導(dǎo)致整頁(yè)白屏。如果整個(gè)應(yīng)用沒(méi)有任何錯(cuò)誤兜底任何小異常都能把界面干掉排查體驗(yàn)和生產(chǎn)體驗(yàn)都會(huì)很糟。6. 框架與庫(kù)選型從 fullcalendar 到一個(gè)庫(kù)該不該引入熱詞里出現(xiàn)了“javascript框架或庫(kù)是一組能輕松生成跨瀏覽器兼容的javascript代碼的工具和函數(shù)”和“fullcalendar javascript”。這說(shuō)明選型問(wèn)題是每個(gè) JS 開發(fā)者都繞不開的。我在不同項(xiàng)目里用過(guò)很多庫(kù)最深的一點(diǎn)體會(huì)是一個(gè)庫(kù)的引入不是在解決一個(gè)需求而是在給項(xiàng)目增加一份長(zhǎng)期依賴選型必須帶著成本和退出策略來(lái)思考。6.1 引入一個(gè)庫(kù)前要評(píng)估的 5 個(gè)維度以 fullcalendar 這類日歷組件為例它解決了復(fù)雜日歷視圖和事件排期的問(wèn)題功能強(qiáng)大但體積也不小。我的選擇思路是這樣的需求復(fù)雜度如果只是展示一個(gè)月份視圖加點(diǎn)擊事件原生 JS 加 CSS 可能兩百行代碼就足夠。包體積現(xiàn)代項(xiàng)目中包體積直接影響首屏加載fullcalendar 全量引入可能幾百 KB需要按需引入和 tree-shaking。維護(hù)活躍度檢查它的 GitHub 倉(cāng)庫(kù)最近半年是否有更新Issue 響應(yīng)是否及時(shí)這決定了你遇到 bug 時(shí)是否有人管。樣式定制成本默認(rèn)樣式越厚重你要覆蓋的 CSS 就越多改造成本可能超過(guò)自己寫一個(gè)輕量組件。退出策略如果哪一天不滿足需求了數(shù)據(jù)結(jié)構(gòu)和渲染邏輯是否和庫(kù)強(qiáng)綁定遷移成本高不高我在一個(gè)項(xiàng)目里因?yàn)橹挥昧巳諝v 10% 的能力引入了 fullcalendar結(jié)果每升級(jí)版本都得適配一輪樣式和 API投入產(chǎn)出比極低。后來(lái)?yè)Q成了自己封裝的一個(gè)簡(jiǎn)單月歷組件幾十行核心代碼解決了問(wèn)題體積小了將近十倍。選庫(kù)的時(shí)候克制與需求對(duì)齊是一種更專業(yè)的態(tài)度。6.2 跨瀏覽器兼容庫(kù)存在的意義和你的底線熱詞說(shuō)“javascript框架或庫(kù)是一組能輕松生成跨瀏覽器兼容的javascript代碼的工具和函數(shù)”這句話本身是在描述目標(biāo)不是在用庫(kù)的唯一理由。實(shí)際上現(xiàn)代瀏覽器大多數(shù) API 已經(jīng)統(tǒng)一但兼容問(wèn)題仍然存在。例如 CSS 新屬性rotate在老 WebView 里就不支持Array.prototype.flat在老 Safari 里也缺實(shí)現(xiàn)。處理這類問(wèn)題有兩條路一是引入 polyfill 補(bǔ)全缺失能力二是用庫(kù)自帶的兼容層。但兼容層不是銀彈你可以用caniuse.com或babel的browserslist配置統(tǒng)一設(shè)好目標(biāo)讓構(gòu)建工具自動(dòng)做語(yǔ)法降級(jí)。我個(gè)人的底線是生產(chǎn)環(huán)境至少要覆蓋近兩個(gè)大版本的 Chrome、Safari、Edge移動(dòng)端至少要驗(yàn)證 iOS Safari 和主流 Android 的 WebView。不建議用“以最新技術(shù)為榮”的心態(tài)做線上產(chǎn)品新的 API 雖有魅力但用戶設(shè)備不會(huì)因?yàn)樽非笮绿匦跃妥詣?dòng)升級(jí)。6.3 從原生庫(kù)到集成方案UI 框架到底解決什么問(wèn)題“框架或庫(kù)”這個(gè)大話題里UI 框架是體積最大的一類。React、Vue 這類框架解決的是“視圖與狀態(tài)之間的關(guān)系自動(dòng)化”。在沒(méi)有框架的時(shí)代你要手動(dòng)監(jiān)聽每個(gè)輸入事件手動(dòng)更新多條 DOM狀態(tài)一多就失控?？蚣芡ㄟ^(guò)數(shù)據(jù)驅(qū)動(dòng)視圖讓“數(shù)據(jù)變化 → 視圖更新”這條鏈路自動(dòng)化。但框架也帶來(lái)心智負(fù)擔(dān)生命周期、狀態(tài)管理、渲染性能、依賴注入……如果你的項(xiàng)目只有一兩個(gè)交互頁(yè)面純?cè)?JS 可能更輕快如果項(xiàng)目有大量狀態(tài)聯(lián)動(dòng)、頁(yè)面很多那么引入框架是合算的。一個(gè)有效的評(píng)估方法是畫出核心狀態(tài)在頁(yè)面之間的流轉(zhuǎn)圖。如果狀態(tài)超過(guò)五個(gè)且多個(gè)組件需要共享就別硬寫原生。這個(gè)時(shí)候框架的收益遠(yuǎn)大于負(fù)擔(dān)。如果只是給一個(gè)老頁(yè)面加個(gè)小功能模塊直接用原生 JavaScript 寫一個(gè)隔離模塊反而比硬塞框架進(jìn)構(gòu)建鏈路更穩(wěn)妥。7. 跨環(huán)境互調(diào)與工具鏈里的 JavaScriptOC 互調(diào)與 Kettle 腳本從熱詞“oc和javascript互相調(diào)用”“kettle中javascript代碼”能看出來(lái)很多人接觸 JavaScript 不是在網(wǎng)頁(yè)開發(fā)而是在各種工具、移動(dòng)端混合開發(fā)以及數(shù)據(jù)倉(cāng)庫(kù)領(lǐng)域。這反而更能說(shuō)明 JavaScript 的通用性。7.1 OC 和 JavaScript 互相調(diào)用的核心思路在 iOS 開發(fā)中OCObjective-C和 JavaScript 互調(diào)核心場(chǎng)景是使用 WKWebView 或 JavaScriptCore 框架。理解這種互調(diào)關(guān)鍵在于建立兩個(gè)語(yǔ)言之間的橋梁。先說(shuō) OC 調(diào)用 JavaScript。WKWebView 提供了evaluateJavaScript方法可以執(zhí)行一段 JS 代碼并拿到返回值。這可以用來(lái)更新頁(yè)面屬性、調(diào)用頁(yè)面內(nèi)部函數(shù)、甚至讀取頁(yè)面狀態(tài)。[webView evaluateJavaScript:document.title completionHandler:^(id result, NSError *error) { if (error nil) { NSLog(title %, result); } }];再講 JavaScript 調(diào)用 OC。網(wǎng)頁(yè)側(cè)可以通過(guò)WKScriptMessageHandler注冊(cè)一個(gè)橋接對(duì)象然后網(wǎng)頁(yè)側(cè)直接調(diào)用window.webkit.messageHandlers.xxx.postMessage(payload)原生側(cè)在回調(diào)里處理。window.webkit.messageHandlers.nativeBridge.postMessage({ action: share, data: ... });這個(gè)模型本質(zhì)上是約定一種通信協(xié)議。建議把所有交互消息格式統(tǒng)一成一個(gè)規(guī)范比如都帶action、data、callbackId字段再在原生側(cè)做一個(gè)統(tǒng)一分發(fā)器。如果你不做統(tǒng)一協(xié)議頁(yè)面里散落著幾十個(gè) bridge 方法排查問(wèn)題時(shí)會(huì)非常痛苦。我見(jiàn)過(guò)最混亂的項(xiàng)目頁(yè)面里同時(shí)混了 WKWebView 老協(xié)議和新協(xié)議每次升級(jí)都要兩頭維護(hù)最終只能推倒重來(lái)。7.2 Kettle 里的 JavaScript 步驟ETL 場(chǎng)景的降維打擊Kettle也叫 PDI是數(shù)據(jù)抽取轉(zhuǎn)換加載工具很多人不知道它也內(nèi)置了 JavaScript 步驟可以借助 JavaScript 處理數(shù)據(jù)轉(zhuǎn)換邏輯。這比寫一大段 Java 插件更靈活適合處理字符串清洗、條件分支、數(shù)組重組等邏輯。在 Kettle 的“修改 JavaScript 腳本值”步驟中腳本可以使用一些內(nèi)置變量和函數(shù)比如_row代表當(dāng)前數(shù)據(jù)行g(shù)etInputRowMeta()用于元數(shù)據(jù)putRow()負(fù)責(zé)輸出行。下面的示例做了簡(jiǎn)單的數(shù)據(jù)轉(zhuǎn)換和數(shù)據(jù)過(guò)濾var result row.name.trim().toUpperCase(); if (result.indexOf(TEST) 0) { row.name result; putRow(row); }這里的要點(diǎn)是JavaScript 不是數(shù)據(jù)倉(cāng)庫(kù)的主角但它是一個(gè)極好的“膠水層”。復(fù)雜的清洗邏輯用 Java 寫裝備成本高用 JavaScript 幾行就完成。需要注意 Kettle 內(nèi)置的 Script 引擎版本可能偏老ES6 語(yǔ)法不一定全兼容所以我在 Kettle 里寫 JS 通常只使用 ES5 風(fēng)格避免箭頭函數(shù)和模板字符串踩坑不報(bào)錯(cuò)卻悄悄變了語(yǔ)義。7.3 跨環(huán)境調(diào)試的通用套路邊界隔離與日志穿透不管 OC 互調(diào)還是 Kettle 腳本跨環(huán)境調(diào)試的最大痛點(diǎn)都在“看不到中間過(guò)程”。我總結(jié)了一個(gè)通用套路先確認(rèn)環(huán)境邊界。哪些數(shù)據(jù)是原生側(cè)傳入的哪些是 JS 側(cè)生成的先用一份靜態(tài)樣例分別在兩側(cè)打印日志。第二是保證錯(cuò)誤不被吞。OC 側(cè)捕獲 NSException 時(shí)要把 JavaScript 錯(cuò)誤串接進(jìn)同一套日志體系Kettle 里腳本報(bào)錯(cuò)時(shí)必須把出錯(cuò)的行編號(hào)和數(shù)據(jù)內(nèi)容寫入日志表否則出了問(wèn)題根本不知道是哪一行數(shù)據(jù)導(dǎo)致。第三是接口契約收攏。跨語(yǔ)言調(diào)用最容易出現(xiàn)的問(wèn)題不是不會(huì)寫而是雙方的字段名和狀態(tài)碼對(duì)不上。建議維護(hù)一份“橋梁文檔”把 action 枚舉、payload 示例、返回碼列表寫清楚。8. 常見(jiàn)問(wèn)題與避坑手冊(cè)把高頻坑一次性說(shuō)清對(duì)比了我自己這些年的項(xiàng)目經(jīng)歷以及帶新人過(guò)程中看到的典型問(wèn)題我整理了一份高頻問(wèn)題清單每一條都真實(shí)發(fā)生過(guò)不是從文檔里抄的。8.1 高頻錯(cuò)誤對(duì)照表問(wèn)題現(xiàn)象根因排查推薦處理點(diǎn)擊事件不觸發(fā)元素是動(dòng)態(tài)添加的綁定時(shí)間早于元素創(chuàng)建用事件代理綁定到父容器或用MutationObserver監(jiān)聽節(jié)點(diǎn)插入頁(yè)面跳過(guò)后變量全沒(méi)了刷新導(dǎo)致全局狀態(tài)重置用sessionStorage/localStorage保存或引入狀態(tài)管理var變量循環(huán)導(dǎo)致監(jiān)聽器拿錯(cuò)值var是函數(shù)作用域循環(huán)結(jié)束共享同一個(gè)變量用let塊級(jí)作用域或改用forEach頁(yè)面出現(xiàn)“Cannot read properties of undefined”接口返回?cái)?shù)據(jù)里某個(gè)字段缺失接口層做數(shù)據(jù)格式化前端加可選鏈?.Node 腳本亂碼文件編碼不是 UTF-8保存文件時(shí)統(tǒng)一 UTF-8腳本頭部加// -*- coding: utf-8 -*-一個(gè)頁(yè)面需要引入多個(gè)版本的相同庫(kù)歷史包袱太重計(jì)劃重寫模塊或用無(wú)沖突版本命名空間表格里的每條背后都是一個(gè)具體的 debug 過(guò)程。比如“循環(huán)里 var 變量”這個(gè)問(wèn)題新手版寫得多但是展示中列表里點(diǎn)擊每一項(xiàng)拿出來(lái)的都是最后一個(gè)值。很多人驚呼“靈異事件”根因就是var沒(méi)有塊級(jí)作用域。換成let或者用forEach的回調(diào)參數(shù)后問(wèn)題立刻消失。8.2 我用過(guò)最順手的調(diào)試啟動(dòng)方案如果既有環(huán)境、狀態(tài)、事件我沒(méi)有頭緒時(shí)不會(huì)盲目 console 到處打點(diǎn)而是以下面順序推進(jìn)復(fù)現(xiàn)最小場(chǎng)景把復(fù)雜的業(yè)務(wù)數(shù)據(jù)換成固定靜態(tài)數(shù)據(jù)看能否復(fù)現(xiàn)。從報(bào)錯(cuò)點(diǎn)向上追在報(bào)錯(cuò)棧的最高層函數(shù)打斷點(diǎn)而不是在入口打斷點(diǎn)。打印變量類型不只打印值還要typeof和Array.isArray。檢查異步順序在 then 和 async/await 之間采用日志時(shí)間戳確定調(diào)用時(shí)序。二分排除大段代碼不好定位時(shí)先注釋一半再逐步縮小范圍。這五步聽上去簡(jiǎn)單但能覆蓋大部分日常 bug。真正難的問(wèn)題往往不是某一行寫錯(cuò)而是數(shù)據(jù)或時(shí)序出了問(wèn)題。所以你越早學(xué)會(huì)“看數(shù)據(jù)流動(dòng)”調(diào)試效率就越高。8.3 值得長(zhǎng)期堅(jiān)持的三個(gè)習(xí)慣第一代碼里做到“空值優(yōu)先”不要讓 undefined 滿天飛。接口返回前轉(zhuǎn)換層做默認(rèn)值處理前端拿到的數(shù)據(jù)一定帶可預(yù)期的形狀。如果真的沒(méi)有值也顯式處理而不要在業(yè)務(wù)邏輯里到處if (data)。第二寫函數(shù)時(shí)保持小函數(shù)一個(gè)函數(shù)只做一件事。你寫一個(gè)小函數(shù)天然好測(cè)試、好復(fù)用、好遷移也方便你在新項(xiàng)目的場(chǎng)景里直接搬走核心邏輯。高內(nèi)聚低耦合不是面試話術(shù)是排查問(wèn)題時(shí)的救命稻草。第三全局日志做“類風(fēng)濕”式歸檔。別做一次性 console.log 用完就刪如果這個(gè)日志有可能幫助日后復(fù)現(xiàn)問(wèn)題就把它保留為結(jié)構(gòu)化日志字段。日志里要有時(shí)間戳、操作者身份、關(guān)鍵數(shù)據(jù)量級(jí)和完整上下文。沒(méi)有日志時(shí)間久了你連自己當(dāng)時(shí)怎么想的都回憶不起來(lái)。9. 一些由項(xiàng)目標(biāo)題延伸出來(lái)的私人體會(huì)我在視頻旋轉(zhuǎn)那個(gè)熱詞里其實(shí)看到了一個(gè)更通用的現(xiàn)象很多人遇到問(wèn)題第一反應(yīng)是打開控制臺(tái)用 JavaScript 臨時(shí)改頁(yè)面。這套方法很實(shí)用但要小心別把控制臺(tái)當(dāng)生產(chǎn)工具?？刂婆_(tái)里的隨意改動(dòng)頁(yè)面一刷新就消失不能沉淀為可復(fù)現(xiàn)的代碼。所以我在調(diào)試階段會(huì)用控制臺(tái)驗(yàn)證思路驗(yàn)證通過(guò)后立刻把代碼落進(jìn)真實(shí)項(xiàng)目里用 Git 分支管理來(lái)保存階段性成果而不是讓調(diào)試結(jié)果存在內(nèi)存里。在框架選型那段我想再補(bǔ)充一個(gè)體會(huì)不要因?yàn)椤按蠹叶荚谟谩本鸵胍粋€(gè)庫(kù)也不要因?yàn)椤拔沂质臁本鸵恢蓖Ａ粼诶蠈懛?。?xiàng)目真實(shí)情況才是選型的唯一標(biāo)準(zhǔn)。碰到一個(gè)復(fù)雜組件需求先看一眼手寫成本、再評(píng)估庫(kù)的體積和維護(hù)成本兩邊權(quán)衡的結(jié)果往往和你最初的直覺(jué)相反但更接近合理答案。寫 JavaScript 這些年我最慶幸的一點(diǎn)是始終把基本功放在框架前面。數(shù)據(jù)類型判斷、函數(shù)、事件、異步、字符串操作這些能力在 Vue 里用、在 React 里用、在 Node 里用、在 Kettle 里也用。你在我這篇文章里讀到的東西沒(méi)有一個(gè)是“某個(gè)框架專屬”它們都是 JavaScript 本身的能力。正因?yàn)槿绱怂鼈儾拍茉诓煌h(huán)境里幫你把問(wèn)題拆開把方案落地。如果你現(xiàn)在正處在學(xué) JavaScript 迷茫的階段我的建議是不要急著列一個(gè)巨大的學(xué)習(xí)清單。先按 1 到 9 的節(jié)奏把文章里提到的每個(gè)知識(shí)點(diǎn)抽出來(lái)寫一個(gè)小 demo跑通、拆掉、再寫一遍。代碼這東西看一百遍不如親手敲一遍的效果來(lái)得真實(shí)。