頁(yè)面無(wú)響應(yīng)這個(gè)問(wèn)題干前端的兄弟基本都遇到過(guò)。群里一喊“頁(yè)面卡死了”大家第一反應(yīng)就是“清緩存刷新看看”。可真正棘手的是那種刷新也沒(méi)用、過(guò)一會(huì)兒又自己恢復(fù)、或者直接白屏卡死的場(chǎng)景。說(shuō)實(shí)話這種問(wèn)題之所以難搞不是因?yàn)榇a邏輯多復(fù)雜而是因?yàn)椤盁o(wú)響應(yīng)”這個(gè)現(xiàn)象太模糊了——它可能是主線程被長(zhǎng)任務(wù)霸占可能是內(nèi)存被某個(gè)隱藏的定時(shí)器吃光也可能是渲染層被無(wú)限重繪拖垮。我在不同項(xiàng)目里斷斷續(xù)續(xù)折騰了幾個(gè)月從 Performance 面板到 Memory 堆快照再到代碼層面的逐段拆解總算把這套定位流程跑通了也總結(jié)出一些可以直接套用的優(yōu)化手段。這篇就當(dāng)是踩坑記錄把從定位思路到真實(shí)案例的完整過(guò)程梳理清楚希望能幫你省掉那些我在排障上浪費(fèi)掉的時(shí)間。先說(shuō)一個(gè)我這幾年最大的體會(huì)頁(yè)面無(wú)響應(yīng)絕大多數(shù)情況下不是 JavaScript 代碼“運(yùn)行出錯(cuò)”而是主線程被“堵死”了。瀏覽器的主線程既要執(zhí)行腳本又要處理樣式計(jì)算、布局繪制、事件響應(yīng)一旦某個(gè)任務(wù)把主線程占住超過(guò)幾百毫秒用戶的所有點(diǎn)擊、滾動(dòng)、輸入都會(huì)排隊(duì)等一個(gè)“空檔”表現(xiàn)出來(lái)就是頁(yè)面跟死了一樣。定位的核心就是找到到底是哪個(gè)任務(wù)把主線程給霸占了。1. 頁(yè)面無(wú)響應(yīng)到底是什么在“卡”我們先把罪魁禍?zhǔn)着宄芏嗳艘簧蟻?lái)就扒代碼找 Bug其實(shí)方向就偏了。頁(yè)面無(wú)響應(yīng)從來(lái)不是一件事而是好幾種原因疊加的結(jié)果。我習(xí)慣把它拆成三個(gè)層面去看第一是主線程執(zhí)行的長(zhǎng)任務(wù)第二是內(nèi)存占用異常第三是渲染層反復(fù)做無(wú)效工作。1.1 主線程長(zhǎng)任務(wù)才是最隱蔽的“卡死元兇”瀏覽器的主線程就那么一條道和單車道公路一樣只要有一輛大卡車堵在前面后面所有小車都得停著等。這里的大卡車就是“長(zhǎng)任務(wù)”Long Task。按瀏覽器的標(biāo)準(zhǔn)任何超過(guò) 50ms 的連續(xù)任務(wù)都算長(zhǎng)任務(wù)。為什么是 50ms因?yàn)槿搜鄹兄舆t的閾值以及點(diǎn)擊、輸入反饋的理論上限基本都在這個(gè)數(shù)值附近。超過(guò) 50ms用戶就會(huì)開(kāi)始隱隱覺(jué)得“有點(diǎn)不對(duì)勁”超過(guò) 500ms基本就是“頁(yè)面是不是死了”的體驗(yàn)。我排查過(guò)一個(gè)大屏可視化項(xiàng)目癥狀就是切 Tab 后圖表區(qū)域白屏 2 到 3 秒期間整個(gè)頁(yè)面點(diǎn)哪兒都沒(méi)反應(yīng)。一開(kāi)始懷疑是 ECharts 渲染卡頓但把渲染去掉后問(wèn)題依舊。后來(lái)用 Performance 錄了一段操作記錄發(fā)現(xiàn)主線程上橫著一條巨大的黃色塊時(shí)長(zhǎng)直接沖到 2.3 秒對(duì)應(yīng)的函數(shù)名是 formatReportData。打開(kāi)一看里面用 for 循環(huán)對(duì)幾千條記錄做了嵌套排序還順便做了三層 map 結(jié)構(gòu)轉(zhuǎn)換。真正的問(wèn)題就在這里——這不是渲染的鍋是數(shù)據(jù)處理邏輯把主線程堵死了。1.2 別忽略渲染層的“無(wú)效勞動(dòng)”還有一個(gè)特別容易忽略的地方是強(qiáng)制同步布局Forced Synchronous Layout。簡(jiǎn)單說(shuō)就是你剛改完元素的樣式馬上就調(diào)用讀取布局屬性的方法比如 offsetHeight、getBoundingClientRect瀏覽器沒(méi)辦法只能立刻放棄之前攢的所有優(yōu)化當(dāng)場(chǎng)重新算一遍布局。如果這種操作被塞進(jìn)一個(gè)幾百次的循環(huán)里那性能直接雪崩。生活化的理解是這樣的本來(lái)廚房可以先把所有菜切好、把鍋燒熱、再統(tǒng)一炒菜效率很高。結(jié)果你每隔一分鐘就喊一句“我要看鹽罐在哪”廚師只能放下刀去給你找鹽找到之后又得重新進(jìn)入狀態(tài)。跑去讀一次 offsetHeight就是喊了一次“我要看鹽罐”。讀完十次廚師基本上就什么都干不成了。1.3 內(nèi)存異常頁(yè)面無(wú)響應(yīng)的“慢性毒藥”長(zhǎng)任務(wù)是“急性的刀傷”內(nèi)存問(wèn)題就是“慢性毒藥”。內(nèi)存持續(xù)上漲不回收垃圾回收器一啟動(dòng)就得全停頓Stop The World頁(yè)面表現(xiàn)為間歇性卡頓、越用越卡最終徹底無(wú)響應(yīng)。常見(jiàn)的內(nèi)存泄漏源包括全局變量里掛著 DOM 引用、定時(shí)器沒(méi)有被清除、事件監(jiān)聽(tīng)器重復(fù)添加、閉包把大對(duì)象一直拽著不放開(kāi)。定位內(nèi)存問(wèn)題比定位長(zhǎng)任務(wù)要難一點(diǎn)因?yàn)橛袝r(shí)候你盯著代碼看半天也看不出是誰(shuí)把內(nèi)存攥在手里不放。還是要靠瀏覽器自帶的 Memory 面板做堆快照對(duì)比后面我會(huì)詳細(xì)講具體怎么操作。2. 定位無(wú)響應(yīng)的完整過(guò)程從 Performance 面板把“兇手”揪出來(lái)先聲明一下網(wǎng)上有很多講性能優(yōu)化的文章但大多數(shù)只講了“怎么優(yōu)化”沒(méi)有講“怎么定位”。定位其實(shí)才是最有價(jià)值的部分——優(yōu)化方案你抄作業(yè)就行但每個(gè)項(xiàng)目的堵點(diǎn)完全不一樣。工具思路是一樣的我用的是 Chrome DevTools大家手邊基本都是它。2.1 用 Performance 面板抓長(zhǎng)任務(wù)別憑感覺(jué)猜定位長(zhǎng)任務(wù)最直接的方式就是錄制一段操作再看主線程火焰圖。Chrome 的 Performance 面板老版本叫 Performance新版本直接叫 Performance 就行操作路徑是F12 打開(kāi) DevTools → 切到 Performance → 點(diǎn)擊左上角的錄制按鈕 → 在頁(yè)面上操作你要復(fù)現(xiàn)的步驟 → 點(diǎn)擊 Stop。錄制時(shí)間不用太長(zhǎng)夠復(fù)現(xiàn)問(wèn)題就行。如果頁(yè)面做一次切換要卡 2 秒那從操作開(kāi)始到卡頓結(jié)束錄制個(gè) 5 秒就足夠。重點(diǎn)是 Stop 之后看什么很多人看到滿屏花花綠綠的色塊就懵了。其實(shí)你只需要關(guān)注兩點(diǎn)第一有沒(méi)有紅色角標(biāo)標(biāo)出來(lái)的 Long Task第二主線程Main軌道上哪一塊長(zhǎng)度最離譜。選中一段異常區(qū)域下方會(huì)彈出這段任務(wù)的調(diào)用棧明細(xì)。我通常會(huì)按“Self Time”排序也就是這個(gè)函數(shù)自身執(zhí)行花了多少時(shí)間排除它調(diào)用的子函數(shù)耗時(shí)。這個(gè)數(shù)據(jù)非常重要因?yàn)橛袝r(shí)候外層函數(shù)看起來(lái)很耗時(shí)其實(shí)時(shí)間全花在它調(diào)用的另一個(gè)函數(shù)上了。只有看 Self Time 才能找到真正干活干活最多的那個(gè)函數(shù)。2.2 用 Performance Monitor 實(shí)時(shí)看頁(yè)面狀態(tài)除了錄制回放還可以開(kāi) Performance Monitor 做實(shí)時(shí)監(jiān)控。打開(kāi)方式DevTools 里按 CommandShiftPMac或 CtrlShiftPWindows呼出命令菜單輸入 Performance Monitor 回車。這個(gè)面板的好處是你可以盯著 CPU 占用率、JS 內(nèi)存、DOM 節(jié)點(diǎn)數(shù)這幾個(gè)指標(biāo)實(shí)時(shí)的跳不用反復(fù)錄制回放。我在排查內(nèi)存泄漏的時(shí)候就是開(kāi)著 Performance Monitor 掛在旁邊每 5 分鐘回來(lái)看一眼。如果 JS memory 的曲線一路向上從來(lái)不帶回落那基本可以確定有泄漏。如果是一會(huì)兒升高一會(huì)兒降低那就是正常的內(nèi)存波動(dòng)是垃圾回收在正常工作反而不用太擔(dān)心。2.3 用 Memory 面板對(duì)比堆快照找泄漏找到了趨勢(shì)還得找到具體對(duì)象。Memory 面板的操作流程先做一次 Heap snapshot記為快照 A然后你回到頁(yè)面里反復(fù)做那些你以為會(huì)導(dǎo)致問(wèn)題的操作比如反復(fù)切 Tab、反復(fù)打開(kāi)關(guān)閉彈窗操作完再打一次快照 B。重點(diǎn)來(lái)了用 Comparison 視圖對(duì)比快照 A 和 B。如果發(fā)現(xiàn)某類對(duì)象數(shù)量在操作后大量增加并且沒(méi)有被回收那就要懷疑它了。常見(jiàn)的泄露頭號(hào)嫌疑犯是 Detached nodes也就是已經(jīng)被移除出 DOM 樹(shù)、但 JavaScript 還在引用著它的節(jié)點(diǎn)。這類東西光是掛在文檔里不顯示每個(gè)還在占著內(nèi)存累積幾百個(gè)之后頁(yè)面基本就廢了。Close 按鈕上的事件處理器、定時(shí)器回調(diào)、全局變量為緩存而做的數(shù)組這類東西都是 Detached 節(jié)點(diǎn)的溫床。定位到這個(gè)節(jié)點(diǎn)的引用路徑之后順著路徑找到賦值的代碼清理掉對(duì)應(yīng)引用就行。3. 特定場(chǎng)景定位高頻切換、大數(shù)據(jù)渲染、后臺(tái)任務(wù)的處理技巧前面說(shuō)的大概率是通用的定位思路但實(shí)際開(kāi)發(fā)中還有幾個(gè)高頻場(chǎng)景需要單獨(dú)對(duì)癥下藥不然用一本萬(wàn)能的《傷寒論》治不了所有病。3.1 高頻切換場(chǎng)景路由切換白屏、Tab 切卡頓這種場(chǎng)景的特征是剛進(jìn)頁(yè)面正常來(lái)回切五六次之后開(kāi)始卡切十幾次直接卡死。問(wèn)題往往出在“舊頁(yè)面沒(méi)有被清理”上。SPA 單頁(yè)應(yīng)用里路由切換只是把舊組件卸載、新組件掛載但如果你在組件里注冊(cè)了事件監(jiān)聽(tīng)器、定時(shí)器、WebSocket 連接而卸載的時(shí)候沒(méi)有清理這些東西就會(huì)像幽靈一樣留在后臺(tái)繼續(xù)跑。有一個(gè)非常典型的例子某個(gè)功能組件在 mounted 生命周期里啟動(dòng)了 setInterval 輪詢數(shù)據(jù)每 2 秒拉一次接口。用戶切走之后組件被卸載了但 setInterval 沒(méi)有 clear輪詢照常進(jìn)行。每切一次 Tab就多一個(gè)輪詢?nèi)蝿?wù)。切十個(gè) Tab后臺(tái)就有十個(gè)接口在每 2 秒輪詢一次。主線程不卡才怪。這個(gè)場(chǎng)景的操作建議是兩條第一在 beforeUnmount 或 onUnmounted 里把所有長(zhǎng)生命周期任務(wù)都清掉第二用 Performance 面板錄制一次“連續(xù)切換 Tab 5 次”的操作看后臺(tái)是否有周期性重復(fù)的黃色任務(wù)塊。如果看到類似心跳一樣規(guī)律出現(xiàn)的大色塊那基本就是定時(shí)器漏清了。3.2 大數(shù)據(jù)渲染表格、列表、圖表動(dòng)輒上萬(wàn)條數(shù)據(jù)大數(shù)據(jù)量場(chǎng)景的表現(xiàn)是數(shù)據(jù)返回后用 setState 一次性全部灌到前端頁(yè)面瞬間卡死。這種問(wèn)題最有效的第一步不是去優(yōu)化代碼而是先確認(rèn)數(shù)據(jù)到底是怎么被渲染的。真正拖垮頁(yè)面的往往不是數(shù)據(jù)量本身而是數(shù)據(jù)量觸發(fā)了多少次重排、多少次重繪。比如把 5000 條數(shù)據(jù)一次性渲染成 5000 個(gè) DOM 節(jié)點(diǎn)瀏覽器把所有節(jié)點(diǎn)插入文檔時(shí)必然觸發(fā)大規(guī)模重排。你每多塞一個(gè)節(jié)點(diǎn)整個(gè)文檔的布局都要重算一遍最后的總耗時(shí)和 DOM 節(jié)點(diǎn)數(shù)量呈指數(shù)關(guān)系。解決思路嘛核心策略就是“別一次性全量渲染”。常見(jiàn)的方案有幾種虛擬滾動(dòng)只渲染可視區(qū)域內(nèi)的節(jié)點(diǎn)、分頁(yè)加載、按需渲染。你如果用的是 Element Plus 的 el-table它本身就支持虛擬表格如果用的是自研的列表可以找一個(gè)虛擬滾動(dòng)庫(kù)。這里提醒一點(diǎn)虛擬滾動(dòng)不是萬(wàn)能的它只適合高度確定的列表不適合有大量嵌套內(nèi)容、高度不固定的場(chǎng)景。3.3 后臺(tái)任務(wù)CDN 數(shù)據(jù)解析、批量計(jì)算、請(qǐng)求重試我在一個(gè)數(shù)據(jù)中臺(tái)項(xiàng)目里還遇到過(guò)一種情況頁(yè)面本身沒(méi)有耗時(shí)的渲染但會(huì)定期接收服務(wù)端推送的數(shù)據(jù)然后在前端做統(tǒng)計(jì)計(jì)算。數(shù)據(jù)量一大計(jì)算過(guò)程就把主線程堵住了。表現(xiàn)是頁(yè)面右上角有數(shù)據(jù)更新的轉(zhuǎn)圈動(dòng)畫(huà)但整個(gè)頁(yè)面已經(jīng)點(diǎn)不動(dòng)了。這種問(wèn)題用 Performance 也能定位但定位到之后優(yōu)化手段要更講究一些。計(jì)算任務(wù)本身不能不做你要做的是“把計(jì)算切成片”讓主線程在每個(gè)時(shí)間片之間能喘口氣。這個(gè)方案叫時(shí)間切片Time Slicing核心思想是用 setTimeout 或 requestIdleCallback 把一個(gè)大計(jì)算任務(wù)拆分成多個(gè)小任務(wù)在每個(gè)小任務(wù)之間讓出主線程讓瀏覽器能處理用戶的點(diǎn)擊和滾動(dòng)。這里我用過(guò)比較順手的工具是 requestIdleCallback它能在瀏覽器空閑的時(shí)候執(zhí)行回調(diào)不會(huì)搶占關(guān)鍵渲染路徑。不過(guò)在具體落地的時(shí)候要注意瀏覽器兼容性和回調(diào)執(zhí)行時(shí)機(jī)的不可控性必要時(shí)還是得用分割數(shù)組 setTimeout 的方式手動(dòng)控制切片的粒度和節(jié)奏。4. 優(yōu)化手段怎么做才有效從代碼層到架構(gòu)層的幾板斧定位是“治病”優(yōu)化是“根治”。很多人定位到了長(zhǎng)任務(wù)卻不知道怎么改或者改了之后發(fā)現(xiàn)沒(méi)效果。我按從輕到重的順序把真正有效的優(yōu)化手段整理成了“幾板斧”你可以根據(jù)問(wèn)題的嚴(yán)重程度選擇用哪一層。4.1 代碼層優(yōu)化最直接的“外科手術(shù)”代碼層優(yōu)化的本質(zhì)是減少無(wú)效工作目標(biāo)是把長(zhǎng)任務(wù)從 500ms 壓到 100ms 以下。常見(jiàn)手段有這么幾種。第一防抖debounce和節(jié)流throttle。這倆是最好用但也是最容易被用錯(cuò)的。簡(jiǎn)單區(qū)分一下防抖是“事件停止觸發(fā)后延遲執(zhí)行”適合搜索框輸入、窗口 resize節(jié)流是“固定時(shí)間內(nèi)只執(zhí)行一次”適合滾動(dòng)事件、鼠標(biāo)移動(dòng)事件。使用場(chǎng)景千萬(wàn)別搞反不然效果會(huì)大打折扣。第二減少?gòu)?qiáng)制同步布局。代碼規(guī)范上我給自己定了三條紅線不要在循環(huán)里讀 offsetHeight 之類的布局屬性不要在一個(gè)語(yǔ)句里同時(shí)改樣式然后又讀布局屬性如果非要批量改樣式先用 class 切換代替逐個(gè)修改 style 屬性。第三批量 DOM 操作。用 DocumentFragment 先攢一批節(jié)點(diǎn)一次性掛到文檔里而不是一條一條 appendChild。這個(gè)在老的 jQuery 時(shí)代是常識(shí)現(xiàn)在用框架的人反而容易忽略。4.2 渲染層優(yōu)化從“每次全量重建”到“按需更新”這一層主要是針對(duì)框架層面的渲染優(yōu)化。我以 Vue 和 React 為主說(shuō)幾個(gè)通用原則。Vue 里核心是避免多余的響應(yīng)式更新。用 Object.freeze 凍結(jié)不需要響應(yīng)式的數(shù)據(jù)可以避免 Vue 為這些數(shù)據(jù)做響應(yīng)式代理。對(duì)于從接口拉回來(lái)的靜態(tài)字典數(shù)據(jù)、長(zhǎng)列表數(shù)據(jù)直接用 Object.freeze 包一層性能提升立竿見(jiàn)影。另一個(gè)是合理使用 computed 和 watch——computed 有緩存適合做派生數(shù)據(jù)的計(jì)算watch 適合做有副作用的操作。別把兩者場(chǎng)景搞反了尤其是不要在 watch 里做重型數(shù)據(jù)處理或調(diào)用接口容易造成隱性的性能黑洞。React 里主要是用 React.memo 避免不必要的子組件重渲染用 useMemo 和 useCallback 緩存值和函數(shù)引用。但注意這些手段不是越多越好。濫用 useMemo 會(huì)讓代碼可讀性變差而且 memo 比較本身也是有開(kāi)銷的。我的經(jīng)驗(yàn)是只有當(dāng)子組件渲染開(kāi)銷真的很大或者該組件在父組件頻繁重渲染時(shí)才會(huì)被連帶渲染才值得用 memo 優(yōu)化。4.3 架構(gòu)層優(yōu)化用 Web Worker 把計(jì)算挪出主線程如果經(jīng)過(guò)代碼層優(yōu)化后計(jì)算量還是非常大那就得走架構(gòu)層路線了。核心思路是把那些不需要操作 DOM 的重計(jì)算任務(wù)搬到 Web Worker 里去執(zhí)行。Web Worker 相當(dāng)于給主線程找到一個(gè)外包公司——不需要你親自干的活扔給外包公司干干完把結(jié)果送回來(lái)。這樣主線程就騰出來(lái)了用戶響應(yīng)自然就快了。我之前做過(guò)一個(gè)數(shù)據(jù)清洗功能需要把服務(wù)端返回的幾十萬(wàn)條打點(diǎn)數(shù)據(jù)做聚合、去重、排序。之前在主線程跑要卡 3 秒多遷移到 Web Worker 之后主線程完全不卡計(jì)算過(guò)程它自己異步去做完成后通過(guò) postMessage 回報(bào)結(jié)果。頁(yè)面體驗(yàn)直接從“卡死”變成“等著加載”。要注意的是Web Worker 里不能直接用 window、document 等 API所以只適合做純計(jì)算邏輯。另外通過(guò) postMessage 傳遞數(shù)據(jù)的時(shí)候會(huì)有結(jié)構(gòu)化克隆的開(kāi)銷如果數(shù)據(jù)量特別大可以考慮用 Transferable Objects 轉(zhuǎn)移 ArrayBuffer 的所有權(quán)這樣不需要復(fù)制數(shù)據(jù)性能會(huì)更好。4.4 場(chǎng)景化優(yōu)化懶加載、虛擬列表、骨架屏換數(shù)據(jù)處理如果問(wèn)題出在特定的大數(shù)據(jù)列表或者圖片資源上還有幾個(gè)很對(duì)癥的手段。懶加載適合圖片懶加載、路由懶加載、組件懶加載。核心原則是“用到的時(shí)候才加載”。一張圖片不加 loadinglazy瀏覽器無(wú)論如何都會(huì)把圖片資源拉到本地加了這個(gè)屬性之后瀏覽器只有在圖片出現(xiàn)在視口附近才開(kāi)始下載這樣首屏的加載壓力會(huì)小很多。路由懶加載在 Vue Router 和 React Router 里都有對(duì)應(yīng)的動(dòng)態(tài)導(dǎo)入寫(xiě)法直接把 component 參數(shù)改成 ( ) import(./xxx.vue) 就能實(shí)現(xiàn)。虛擬列表是我處理長(zhǎng)列表的殺手锏。核心思想是無(wú)論你的數(shù)據(jù)有多長(zhǎng)我都只渲染可視區(qū)域內(nèi)那十幾個(gè)節(jié)點(diǎn)滾動(dòng)的時(shí)候通過(guò)計(jì)算 startIndex 和 endIndex 動(dòng)態(tài)更新渲染的切片。幾百條數(shù)據(jù)的時(shí)候可能沒(méi)什么感覺(jué)一旦數(shù)據(jù)到上萬(wàn)條虛擬列表和普通渲染的性能差距可以達(dá)到幾十倍?？梢暬笃晾锩娉Ｓ眠@種方案來(lái)處理高密度表格和日志流。骨架屏雖然沒(méi)有直接提升頁(yè)面響應(yīng)速度但是它優(yōu)化了用戶對(duì)“無(wú)響應(yīng)”的感知。用戶看到骨架屏知道數(shù)據(jù)在加載中比面對(duì)一個(gè)白屏心里踏實(shí)得多。這個(gè)屬于體驗(yàn)層的優(yōu)化建議和數(shù)據(jù)請(qǐng)求配套一起做成本很低效果卻不錯(cuò)。5. 真實(shí)案例復(fù)盤(pán)一個(gè)頁(yè)面無(wú)響應(yīng)是怎么一步步定位清楚并解決的前面講了方法論可能有點(diǎn)散。我拿一個(gè)真實(shí)案例完整串一遍。這是一個(gè) ToB 后臺(tái)系統(tǒng)的訂單列表頁(yè)用戶反饋是“頁(yè)面用了大概 10 分鐘后開(kāi)始卡點(diǎn)擊沒(méi)有反應(yīng)必須刷新頁(yè)面才能恢復(fù)但恢復(fù)之后過(guò)一陣又卡死”。間歇性、周期性、必現(xiàn)這三個(gè)特征疊加在一起基本就鎖定是內(nèi)存泄漏或者資源沒(méi)釋放。5.1 復(fù)現(xiàn)與初檢先用 Performance Monitor 做了排出我第一步不是立刻打開(kāi) Performance 做錄制因?yàn)檫@種“用 10 分鐘才卡”的問(wèn)題錄一次短操作根本錄不到。我先把 Performance Monitor 掛在頁(yè)面旁邊同時(shí)跟用戶確認(rèn)了卡死的觸發(fā)條件——只要開(kāi)著頁(yè)面不操作過(guò)幾分鐘就卡如果頻繁點(diǎn)擊按鈕卡得更快。觀察了大概 20 分鐘發(fā)現(xiàn)頁(yè)面 JS heap 曲線一路向上從 30MB 持續(xù)漲到 200MB 以上中間沒(méi)有任何顯著的回落。這時(shí)候基本可以確定有內(nèi)容在持續(xù)生成且無(wú)法被垃圾回收。而且 DOM node 總數(shù)也在持續(xù)上漲。對(duì)象在累積內(nèi)存不被釋放這就說(shuō)得通為什么頁(yè)面會(huì)越用越卡了。5.2 源頭追蹤從堆快照里揪出 Detached Nodes接下來(lái)的定位手段是對(duì)比快照。我在頁(yè)面空載狀態(tài)下打了一次 Heap snapshot 作為基線然后在 5 分鐘內(nèi)我用腳本模擬了 50 次點(diǎn)擊詳情按鈕、打開(kāi)彈窗、再關(guān)閉彈窗的操作操作完再打一次快照。用 Comparison 視圖對(duì)比兩次快照發(fā)現(xiàn) Detached nodes 增加了 300 多個(gè)節(jié)點(diǎn)每個(gè)節(jié)點(diǎn)都包含整個(gè)彈窗的 DOM 結(jié)構(gòu)。順著引用路徑往下挖發(fā)現(xiàn)詳情彈窗組件里綁定了一個(gè)全局的 bus 事件監(jiān)聽(tīng)器監(jiān)聽(tīng)名是 order-detail-refresh用來(lái)刷新彈窗里的訂單狀態(tài)。但彈窗關(guān)閉的時(shí)候只銷毀了彈窗自身沒(méi)有主動(dòng) off 掉 bus 上的監(jiān)聽(tīng)器。等于每打開(kāi)一次彈窗就在全局事件中心留了一個(gè)監(jiān)聽(tīng)器監(jiān)聽(tīng)器又引用了彈窗的 DOM 實(shí)例所以垃圾回收器一看這個(gè) DOM 還有引用就不敢回收。彈窗越開(kāi)越多Detached 節(jié)點(diǎn)就越積越多內(nèi)存也就不斷上漲。5.3 修復(fù)方案與結(jié)果修復(fù)方案很簡(jiǎn)單兩條第一在彈窗關(guān)閉的 onClosed/onUnmounted 生命周期里主動(dòng)調(diào)用 bus.$off(order-detail-refresh)把監(jiān)聽(tīng)器解綁第二全局統(tǒng)一規(guī)范凡是使用全局事件總線或跨組件通信的事件必須在組件銷毀時(shí)做對(duì)稱清理。改完之后我重新跑了一遍同樣的操作序列打開(kāi)關(guān)閉彈窗 50 次再看內(nèi)存曲線。Detached nodes 的數(shù)量基本保持平穩(wěn)JS heap 也不再持續(xù)上漲長(zhǎng)時(shí)間掛機(jī)觀察 30 分鐘之后內(nèi)存曲線依然是一條水平的直線。用戶再也沒(méi)反饋過(guò)卡死的問(wèn)題。一個(gè)值得注意的細(xì)節(jié)是這類問(wèn)題修起來(lái)通常只要幾行代碼難的是定位的那一個(gè)多小時(shí)。這中間如果靠肉眼去翻代碼是根本翻不出來(lái)的因?yàn)槟悴恢酪膫€(gè)方向找。所以我想強(qiáng)調(diào)一個(gè)觀點(diǎn)排查頁(yè)面無(wú)響應(yīng)一定要在工具的幫助下做“數(shù)據(jù)驅(qū)動(dòng)”的排查不要“縫縫補(bǔ)補(bǔ)靠猜”。6. 常見(jiàn)問(wèn)題速查與避坑清單最后把我在多個(gè)項(xiàng)目里遇到的典型無(wú)響應(yīng)場(chǎng)景整理成一個(gè)速查表方便你在排查的時(shí)候?qū)φ諈⒖肌，F(xiàn)象特征最可能的原因優(yōu)先排查方向點(diǎn)擊按鈕后整個(gè)頁(yè)面卡住 N 秒主線程長(zhǎng)任務(wù)同步計(jì)算量過(guò)大Performance 面板看長(zhǎng)任務(wù)Self Time 排序頁(yè)面越用越卡刷新后恢復(fù)內(nèi)存泄漏Detached DOM 節(jié)點(diǎn)或事件監(jiān)聽(tīng)器殘留Memory 面板堆快照對(duì)比滾動(dòng)列表時(shí)掉幀、卡頓滾動(dòng)事件處理器過(guò)于頻繁節(jié)流或把高頻計(jì)算移到 Web Worker切換路由后白屏再切幾次卡死組件卸載未清理定時(shí)器/事件/連接檢查 onUnmounted清理長(zhǎng)生命周期資源大數(shù)據(jù)表格渲染卡死DOM 節(jié)點(diǎn)數(shù)量爆炸重排重繪成本過(guò)高虛擬滾動(dòng)、分頁(yè)加載、按需渲染打開(kāi)彈窗多次后頁(yè)面變重全局事件總線監(jiān)聽(tīng)器泄漏快照對(duì)比清理 $off視頻或圖片資源加載時(shí)卡死資源加載及解碼占用大量?jī)?nèi)存帶寬懶加載、壓縮資源、控制并發(fā)加載數(shù)定時(shí)輪詢接口期間頁(yè)面變卡后臺(tái)輪詢?nèi)蝿?wù)過(guò)多或響應(yīng)數(shù)據(jù)量過(guò)大檢查輪詢的取消邏輯考慮批量或條件輪詢避坑方面我有幾條原則想寫(xiě)在這里都是踩過(guò)坑之后總結(jié)出來(lái)的。第一不要相信“瀏覽器自己會(huì)優(yōu)化”這種話。瀏覽器會(huì)優(yōu)化很多東西但不會(huì)幫你優(yōu)化一個(gè)外層循環(huán)里每讀一次 offsetHeight 的代碼。該主動(dòng)優(yōu)化就主動(dòng)優(yōu)化別指望瀏覽器替你兜底。第二不要只依賴生產(chǎn)環(huán)境的報(bào)錯(cuò)。頁(yè)面無(wú)響應(yīng)很少會(huì)拋 JavaScript 異常它是性能問(wèn)題不是邏輯錯(cuò)誤。這就意味著你不能靠錯(cuò)誤監(jiān)控平臺(tái)來(lái)發(fā)現(xiàn)它。等用戶來(lái)反饋的時(shí)候問(wèn)題往往已經(jīng)存在好幾天了。如果你們項(xiàng)目線上數(shù)據(jù)量在增長(zhǎng)最好定期自己開(kāi) Performance 面板測(cè)一下關(guān)鍵路徑的性能。第三優(yōu)化完之后不要只測(cè)一次就收工。性能問(wèn)題有偶然性代碼改了測(cè)試環(huán)境未必能復(fù)現(xiàn)。我一般的做法是修復(fù)之后連續(xù)跑三到五輪相同的操作序列記錄每輪的耗時(shí)/內(nèi)存曲線看趨勢(shì)是否穩(wěn)定。如果第二三輪又出現(xiàn)內(nèi)存上漲那說(shuō)明還有隱藏的泄漏點(diǎn)沒(méi)有清理干凈。第四警惕第三方庫(kù)帶來(lái)的隱性問(wèn)題。有些組件庫(kù)和圖表庫(kù)在實(shí)現(xiàn)上本身就比較重比如某些老版本的高版本 ECharts每次 setOption 都要做全量 diff。如果你的頁(yè)面卡死發(fā)生在引入某個(gè)第三方庫(kù)之后可以先用注釋法把庫(kù)臨時(shí)去掉對(duì)比一下前后性能再?zèng)Q定是優(yōu)化用法還是換庫(kù)。7. 寫(xiě)在最后這個(gè)排查思路可以順帶走查一遍說(shuō)實(shí)話頁(yè)面無(wú)響應(yīng)這個(gè)問(wèn)題最難的永遠(yuǎn)是第一步——當(dāng)你打開(kāi) DevTools 面對(duì)滿屏的專業(yè)術(shù)語(yǔ)、一堆花花綠綠的火焰圖的時(shí)候你真的不知道該把鼠標(biāo)點(diǎn)在哪里。我自己一開(kāi)始也這樣后來(lái)發(fā)現(xiàn)只要先記住一句話無(wú)響應(yīng)等于主線程被堵住堵住主線程的只有三種可能——長(zhǎng)任務(wù)、內(nèi)存異常、渲染開(kāi)銷爆炸。然后按順序去 Performance 面板找長(zhǎng)任務(wù)再去 Memory 面板看內(nèi)存曲線最后再回到代碼里對(duì)著長(zhǎng)任務(wù)和內(nèi)存快照做定點(diǎn)優(yōu)化。把這三個(gè)步驟記熟基本能覆蓋 80% 以上的場(chǎng)景。再分享一個(gè)小技巧排查之前先給頁(yè)面做一次“最小化復(fù)現(xiàn)”。把無(wú)關(guān)的組件、分支邏輯先去掉只保留最可能出問(wèn)題的鏈路。我見(jiàn)過(guò)很多人在一個(gè)十幾 MB 的項(xiàng)目里到處找Bug其實(shí)只要把最小鏈路抽出來(lái)問(wèn)題瞬間就暴露了。這比任何工具都管用。最后提醒一句如果你負(fù)責(zé)的項(xiàng)目是那種數(shù)據(jù)量會(huì)持續(xù)增長(zhǎng)的后臺(tái)系統(tǒng)建議把性能排查也納入日常開(kāi)發(fā)流程。不要等用戶說(shuō)“頁(yè)面很卡”再排查那樣你大概率已經(jīng)背上了一個(gè)歷史包袱。定期的性能自測(cè)、給開(kāi)發(fā)規(guī)范里加上“清理事件監(jiān)聽(tīng)器”“避免強(qiáng)制同步布局”之類的紅線能幫你省下無(wú)數(shù)個(gè)加班的夜晚。