我很少公開說這種話但學(xué) JavaScript 這件事值得每個(gè)寫代碼的人認(rèn)真對(duì)待。倒不是因?yàn)樗悄姆N“最好的語(yǔ)言”而是它的應(yīng)用范圍實(shí)在太廣瀏覽器里的頁(yè)面交互、服務(wù)端的 Node.js 中間層、小程序、桌面端工具、甚至數(shù)據(jù)庫(kù)的存儲(chǔ)函數(shù)里都能看到它的影子。你說的“javascript”如果只是停留在聽說過、看過幾段解法代碼的程度那你會(huì)發(fā)現(xiàn)很多項(xiàng)目用的時(shí)候特別順手、一換場(chǎng)景就完全懵圈。這篇文章就是想把 JavaScript 最核心的地基部分包括數(shù)據(jù)類型判斷、函數(shù)、事件、報(bào)錯(cuò)排查、字符串處理這些從頭到尾拆開講一遍再用幾個(gè)真實(shí)場(chǎng)景把它串起來。這篇文章沒有故作高深的理論堆疊講的就是我在實(shí)際項(xiàng)目里反復(fù)用到、反復(fù)踩坑、最后沉淀下來的理解。不管是剛打算入門前端的新手還是寫后端但經(jīng)常被 JS 卡住的同學(xué)又或者是在 iOS、ETL 工具里被迫和 JavaScript 打交道的人都可以拿它當(dāng)一份實(shí)踐筆記來讀。碰到一個(gè)知識(shí)點(diǎn)的時(shí)候我會(huì)直接說明為什么要這么做這么做解決了什么問題。我還會(huì)把自己在項(xiàng)目里遇到過的最典型的錯(cuò)誤和排查思路寫出來希望能幫你少走幾個(gè)月彎路。1. JavaScript 的項(xiàng)目定位與學(xué)習(xí)路徑設(shè)計(jì)很多人在 JavaScript 上栽跟頭不是智商問題是定位問題。他們一上來就想掌握“所有東西”結(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í)位置我先說結(jié)論JavaScript 是一門解釋型、單線程、基于原型繼承的腳本語(yǔ)言。這個(gè)定位決定了它的很多“性格”。因?yàn)榻忉屝退幌?C 和 Java 那樣需要單獨(dú)的編譯步驟寫完之后瀏覽器或 Node 直接就能運(yùn)行開發(fā)效率高但出了問題通常只能靠輸出和調(diào)試工具去找沒有嚴(yán)格的編譯期攔截。因?yàn)閱尉€程它在瀏覽器里只有一個(gè)主線程所有的耗時(shí)代碼都會(huì)阻塞 UI——這也是后來出現(xiàn)異步模型、事件循環(huán)的原因。因?yàn)榛谠屠^承它的對(duì)象行為方式跟基于類的語(yǔ)言完全不同大家常困惑的this指向問題根源就在繼承模型上。一個(gè)常見的誤解是“JavaScript 只能做網(wǎng)頁(yè)特效”。實(shí)際上Node.js 把 JS 帶到了服務(wù)端Electron 把它帶到了桌面應(yīng)用React Native、小程序框架把它帶到了移動(dòng)端。但還是那句話不管外面套了多少層?xùn)|西核心語(yǔ)言能力才是真正能移民的本錢。你用框架寫三年的組件和先在原生 JavaScript 上把邏輯想清楚再寫組件產(chǎn)出的代碼質(zhì)量和排查問題的能力差別非常明顯。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)建工具、包管理。很多人的問題出在跳層學(xué)習(xí)。第二層還沒弄明白就直接上框架一遇到this指向、閉包造成的內(nèi)存問題、事件綁定失效只能靠百度搜索硬湊。我強(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)來看分為原始類型和引用類型。原始類型包括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è)比較特殊可以用來判斷函數(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 的歷史問題與 instanceof 的使用邊界再往下說instanceof。instanceof判斷的是對(duì)象的原型鏈上是否有某個(gè)構(gòu)造函數(shù)的 prototype。它雖然好用但使用邊界比想象中窄得多。[] instanceof Array; // true {} instanceof Object; // true function test() {} instanceof Function; // true問題在于它不是靠“類型標(biāo)記”判斷而是靠“對(duì)象關(guān)系”判斷。如果原型鏈被修改過或者對(duì)象來自另一個(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ù)組、日期以及通過Object.create(null)創(chuàng)建的無原型對(duì)象。這段代碼我在寫工具函數(shù)和參數(shù)校驗(yàn)時(shí)經(jīng)常用省掉了無數(shù)隱性 bug。2.3 字符串操作的實(shí)用高頻方法附帶避坑提示字符串是前端開發(fā)里打交道最多的數(shù)據(jù)類型之一。用戶輸入、接口返回、路徑拼接、模板渲染幾乎全都離不開它。我把自己項(xiàng)目中用過頻率最高的方法整理成了一張參考表方法作用注意點(diǎn)split(sep)按分隔符拆成數(shù)組超過一個(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)度我踩過最深的坑是replace配合字符串參數(shù)時(shí)只替換第一個(gè)匹配項(xiàng)。例如2023-10-10.replace(-, /)得到的是2023/10-10第二個(gè)連字符沒被替換。解決方案是用正則的全局標(biāo)志2023-10-10.replace(/-/g, /)。還有一個(gè)讓很多人懵圈的點(diǎn)字符串的length和 Unicode 字符長(zhǎng)度不一致。中文沒問題但遇到 emoji.length; // 2因?yàn)?emoji 用了兩個(gè)碼元代理對(duì)。如果要做“按字符截?cái)唷敝苯佑胹lice可能會(huì)把 emoji 截成亂碼。現(xiàn)代 JavaScript 提供了Intl.Segmenter或展開運(yùn)算符來解決這個(gè)問題例如[..., 1].length能正確統(tǒng)計(jì)可見字符個(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ù)常見有三種寫法// 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ù)沒有這種提升必須先賦值再調(diào)用。這是很多新人寫腳本時(shí)遇到ReferenceError: Cannot access xxx before initialization的原因。再往下說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ī)則建議直接背下來對(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ù)使用。閉包特別適合用來實(shí)現(xiàn)私有狀態(tài)和一次性初始化的配置對(duì)象因?yàn)榫植孔兞刻烊徊粫?huì)被外部直接訪問。但閉包也有副作用變量持有時(shí)間變長(zhǎng)如果一個(gè)很大的對(duì)象被閉包引用就會(huì)一直占據(jù)內(nèi)存形成泄漏。排查內(nèi)存問題時(shí)head 子里的“Closure”就是閉包引用鏈的意思我看到過很多次定位到的原因都是某個(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)非常常見經(jīng)常三層縮進(jìn)就看不下去后來有了 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ǔ)法包裝。寫起來像同步代碼但背后的執(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 的玩法?？雌饋硐裢嫘ζ鋵?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í)這句話幾乎是萬能入口想找按鈕就寫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è)腳本本身沒什么高深技術(shù)但它演示了一個(gè)常見調(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à)值。事件代理是一種最常見的冒泡應(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í)過深需要closest來判斷目標(biāo)是否匹配。event.target永遠(yuǎn)指向最里層被點(diǎn)擊的元素和event.currentTarget當(dāng)前綁定元素區(qū)分開這個(gè)細(xì)節(jié)是大量調(diào)試問題的分水嶺。4.3 DOM 操作的最佳實(shí)踐減少重排避免性能炸裂操作 DOM 本身不慢慢的是引起瀏覽器重新布局reflow和重新繪制repaint。這就像你裝修一個(gè)房間每改一個(gè)家具的位置就重新量一次全屋尺寸代價(jià)極高。高頻操作批量修改樣式時(shí)可以把元素先隱藏、改完再顯示或者使用requestAnimationFrame合并視覺更新。更推薦的手段是直接操作類名// 不推薦多次樣式寫入 el.style.width 100px; el.style.height 100px; el.style.left 50px; // 推薦一次性切類 el.classList.add(active);框架出現(xiàn)之后很多人直接跳過了原生 DOM 操作的學(xué)習(xí)覺得框架內(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à)值的東西它直接告訴你問題位置和類型比你盲猜準(zhǔn)得多。5.1 五類常見運(yùn)行時(shí)錯(cuò)誤與排查思路JavaScript 運(yùn)行時(shí)錯(cuò)誤主要有語(yǔ)法錯(cuò)誤、引用錯(cuò)誤、類型錯(cuò)誤、范圍錯(cuò)誤、以及 URI 相關(guān)錯(cuò)誤。日常開發(fā)中前四個(gè)最常出現(xiàn)我整理成一張速查表錯(cuò)誤類型典型信息常見原因排查方向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è)變體很坑你訪問一個(gè)已聲明但還沒初始化的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ù)。我看過太多同事在代碼里雜七雜八地塞 console.log然后找不到問題。推薦的做法是分類使用console.log(); // 常規(guī)過程日志 console.info(); // 信息性內(nèi)容 console.warn(); // 潛在風(fēng)險(xiǎn) console.error(); // 錯(cuò)誤場(chǎng)景 console.table(); // 數(shù)組或?qū)ο罅斜泶蛴〕杀砀裾{(diào)試復(fù)雜邏輯時(shí)不要只說“到這步了”把變量名和數(shù)據(jù)一起打出來console.log(user data:, user)。數(shù)據(jù)多了可以直接用斷點(diǎn)調(diào)試在瀏覽器 Sources 面板里點(diǎn)行號(hào)打斷點(diǎn)然后刷新頁(yè)面單步執(zhí)行每一步都能看到作用域里的變量值。這是定位問題的“正面戰(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ù)也打印出來比只打印錯(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)用沒有任何錯(cuò)誤兜底任何小異常都能把界面干掉排查體驗(yàn)和生產(chǎn)體驗(yàn)都會(huì)很糟。6. 框架與庫(kù)選型從 fullcalendar 到一個(gè)庫(kù)該不該引入熱詞里出現(xiàn)了“javascript框架或庫(kù)是一組能輕松生成跨瀏覽器兼容的javascript代碼的工具和函數(shù)”和“fullcalendar javascript”。這說明選型問題是每個(gè) JS 開發(fā)者都繞不開的。我在不同項(xiàng)目里用過很多庫(kù)最深的一點(diǎn)體會(huì)是一個(gè)庫(kù)的引入不是在解決一個(gè)需求而是在給項(xiàng)目增加一份長(zhǎng)期依賴選型必須帶著成本和退出策略來思考。6.1 引入一個(gè)庫(kù)前要評(píng)估的 5 個(gè)維度以 fullcalendar 這類日歷組件為例它解決了復(fù)雜日歷視圖和事件排期的問題功能強(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 就越多改造成本可能超過自己寫一個(gè)輕量組件。退出策略如果哪一天不滿足需求了數(shù)據(jù)結(jié)構(gòu)和渲染邏輯是否和庫(kù)強(qiáng)綁定遷移成本高不高我在一個(gè)項(xiàng)目里因?yàn)橹挥昧巳諝v 10% 的能力引入了 fullcalendar結(jié)果每升級(jí)版本都得適配一輪樣式和 API投入產(chǎn)出比極低。后來?yè)Q成了自己封裝的一個(gè)簡(jiǎn)單月歷組件幾十行核心代碼解決了問題體積小了將近十倍。選庫(kù)的時(shí)候克制與需求對(duì)齊是一種更專業(yè)的態(tài)度。6.2 跨瀏覽器兼容庫(kù)存在的意義和你的底線熱詞說“javascript框架或庫(kù)是一組能輕松生成跨瀏覽器兼容的javascript代碼的工具和函數(shù)”這句話本身是在描述目標(biāo)不是在用庫(kù)的唯一理由。實(shí)際上現(xiàn)代瀏覽器大多數(shù) API 已經(jīng)統(tǒng)一但兼容問題仍然存在。例如 CSS 新屬性rotate在老 WebView 里就不支持Array.prototype.flat在老 Safari 里也缺實(shí)現(xià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 框架到底解決什么問題“框架或庫(kù)”這個(gè)大話題里UI 框架是體積最大的一類。React、Vue 這類框架解決的是“視圖與狀態(tài)之間的關(guān)系自動(dòng)化”。在沒有框架的時(shí)代你要手動(dòng)監(jiān)聽每個(gè)輸入事件手動(dòng)更新多條 DOM狀態(tài)一多就失控?？蚣芡ㄟ^數(shù)據(jù)驅(qū)動(dòng)視圖讓“數(shù)據(jù)變化 → 視圖更新”這條鏈路自動(dòng)化。但框架也帶來心智負(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)超過五個(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代碼”能看出來很多人接觸 JavaScript 不是在網(wǎng)頁(yè)開發(fā)而是在各種工具、移動(dòng)端混合開發(fā)以及數(shù)據(jù)倉(cāng)庫(kù)領(lǐng)域。這反而更能說明 JavaScript 的通用性。7.1 OC 和 JavaScript 互相調(diào)用的核心思路在 iOS 開發(fā)中OCObjective-C和 JavaScript 互調(diào)核心場(chǎng)景是使用 WKWebView 或 JavaScriptCore 框架。理解這種互調(diào)關(guān)鍵在于建立兩個(gè)語(yǔ)言之間的橋梁。先說 OC 調(diào)用 JavaScript。WKWebView 提供了evaluateJavaScript方法可以執(zhí)行一段 JS 代碼并拿到返回值。這可以用來更新頁(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è)可以通過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 方法排查問題時(shí)會(huì)非常痛苦。我見過最混亂的項(xiàng)目頁(yè)面里同時(shí)混了 WKWebView 老協(xié)議和新協(xié)議每次升級(jí)都要兩頭維護(hù)最終只能推倒重來。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ù)過濾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)都在“看不到中間過程”。我總結(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)容寫入日志表否則出了問題根本不知道是哪一行數(shù)據(jù)導(dǎo)致。第三是接口契約收攏。跨語(yǔ)言調(diào)用最容易出現(xiàn)的問題不是不會(huì)寫而是雙方的字段名和狀態(tài)碼對(duì)不上。建議維護(hù)一份“橋梁文檔”把 action 枚舉、payload 示例、返回碼列表寫清楚。8. 常見問題與避坑手冊(cè)把高頻坑一次性說清對(duì)比了我自己這些年的項(xiàng)目經(jīng)歷以及帶新人過程中看到的典型問題我整理了一份高頻問題清單每一條都真實(shí)發(fā)生過不是從文檔里抄的。8.1 高頻錯(cuò)誤對(duì)照表問題現(xiàn)象根因排查推薦處理點(diǎn)擊事件不觸發(fā)元素是動(dòng)態(tài)添加的綁定時(shí)間早于元素創(chuàng)建用事件代理綁定到父容器或用MutationObserver監(jiān)聽節(jié)點(diǎn)插入頁(yè)面跳過后變量全沒了刷新導(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ì)劃重寫模塊或用無沖突版本命名空間表格里的每條背后都是一個(gè)具體的 debug 過程。比如“循環(huán)里 var 變量”這個(gè)問題新手版寫得多但是展示中列表里點(diǎn)擊每一項(xiàng)拿出來的都是最后一個(gè)值。很多人驚呼“靈異事件”根因就是var沒有塊級(jí)作用域。換成let或者用forEach的回調(diào)參數(shù)后問題立刻消失。8.2 我用過最順手的調(diào)試啟動(dòng)方案如果既有環(huán)境、狀態(tà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。真正難的問題往往不是某一行寫錯(cuò)而是數(shù)據(jù)或時(shí)序出了問題。所以你越早學(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ù)期的形狀。如果真的沒有值也顯式處理而不要在業(yè)務(wù)邏輯里到處if (data)。第二寫函數(shù)時(shí)保持小函數(shù)一個(gè)函數(shù)只做一件事。你寫一個(gè)小函數(shù)天然好測(cè)試、好復(fù)用、好遷移也方便你在新項(xiàng)目的場(chǎng)景里直接搬走核心邏輯。高內(nèi)聚低耦合不是面試話術(shù)是排查問題時(shí)的救命稻草。第三全局日志做“類風(fēng)濕”式歸檔。別做一次性 console.log 用完就刪如果這個(gè)日志有可能幫助日后復(fù)現(xiàn)問題就把它保留為結(jié)構(gòu)化日志字段。日志里要有時(shí)間戳、操作者身份、關(guān)鍵數(shù)據(jù)量級(jí)和完整上下文。沒有日志時(shí)間久了你連自己當(dāng)時(shí)怎么想的都回憶不起來。9. 一些由項(xiàng)目標(biāo)題延伸出來的私人體會(huì)我在視頻旋轉(zhuǎn)那個(gè)熱詞里其實(shí)看到了一個(gè)更通用的現(xià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)證通過后立刻把代碼落進(jìn)真實(shí)項(xiàng)目里用 Git 分支管理來保存階段性成果而不是讓調(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é)果往往和你最初的直覺相反但更接近合理答案。寫 JavaScript 這些年我最慶幸的一點(diǎn)是始終把基本功放在框架前面。數(shù)據(jù)類型判斷、函數(shù)、事件、異步、字符串操作這些能力在 Vue 里用、在 React 里用、在 Node 里用、在 Kettle 里也用。你在我這篇文章里讀到的東西沒有一個(gè)是“某個(gè)框架專屬”它們都是 JavaScript 本身的能力。正因?yàn)槿绱怂鼈儾拍茉诓煌h(huán)境里幫你把問題拆開把方案落地。如果你現(xiàn)在正處在學(xué) JavaScript 迷茫的階段我的建議是不要急著列一個(gè)巨大的學(xué)習(xí)清單。先按 1 到 9 的節(jié)奏把文章里提到的每個(gè)知識(shí)點(diǎn)抽出來寫一個(gè)小 demo跑通、拆掉、再寫一遍。代碼這東西看一百遍不如親手敲一遍的效果來得真實(shí)。