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