“頁面無響應”這個事做前端久了基本都會碰到。最氣人的不是它偶發(fā)一次而是你根本沒法穩(wěn)定復現(xiàn)用戶那邊隔三差五來一句“頁面又卡死了”你這邊打開DevTools怎么操作都好好的。一旦出現(xiàn)這種情況整個項目組都會陷入被動運營催、測試催、領導也催最后壓力全堆到前端頭上。我前陣子剛處理完一個線上的類似問題從接到反饋到最終修復前后折騰了差不多一周今天把整個排查思路、工具用法和優(yōu)化方案整理出來希望能幫遇到同樣問題的人少走點彎路。這篇文章我會圍繞“Web頁面頻繁無響應”這個主題講清楚三個層面的東西第一怎么區(qū)分不同類型的無響應建立自己的排查框架第二用什么工具、在什么時機去采集證據(jù)別靠肉眼猜第三定位到根因之后有哪些行之有效的優(yōu)化手段。內(nèi)容偏實戰(zhàn)適合有一定前端基礎、但遇到性能問題還不太知道怎么下手的同學也適合準備前端面試時想拿“性能優(yōu)化”這個點講出深度的人。1. 先搞清楚“頁面無響應”到底屬于哪一類很多人一聽到“頁面無響應”第一反應就是“主線程被阻塞了”然后趕緊打開Performance面板去錄一段結果錄了半天什么也沒抓到。這是因為“無響應”其實是一個很籠統(tǒng)的說法它可能對應好幾種完全不同的底層現(xiàn)象而不同現(xiàn)象對應的排查路徑是完全不一樣的。1.1 把現(xiàn)象拆開看白屏、卡頓、假死和崩潰我習慣把“無響應”拆成四類來看第一類是白屏。頁面打開后一片空白或者某個路由跳轉后內(nèi)容區(qū)域空白用戶點哪里都沒反應。這種情況通常是JS執(zhí)行報錯、資源加載失敗、或者渲染鏈路斷裂導致的。第二類是卡頓。用戶能操作但點擊之后要等很久才有反饋滾動頁面像幻燈片一樣一頓一頓的。這種情況一般是主線程上連續(xù)執(zhí)行了太多同步任務瀏覽器來不及渲染每一幀。第三類是假死。頁面還停留在上一個畫面但鼠標點擊、鍵盤輸入全部失效標簽頁標題變成“無響應”過幾秒又恢復或者一直恢復不了。這種情況是主線程被一個超長任務完全占住了瀏覽器的事件循環(huán)轉不過來連渲染都沒機會執(zhí)行。第四類是崩潰。標簽頁直接變成“頁面崩潰”提示刷新都沒用。這種情況往往是內(nèi)存占用過高、渲染進程直接被殺掉。從排查難度來講卡頓最容易錄到證據(jù)白屏其次假死最坑的是那種“偶發(fā)幾秒又恢復”的情況崩潰則需要重點看內(nèi)存曲線。1.2 建立自己的排查框架先看現(xiàn)象再定方向我在處理這類問題的時候會先跟反饋人確認幾個關鍵信息發(fā)生頻率次/天、發(fā)生場景首屏打開還是操作中、持續(xù)時長秒級還是永久、瀏覽器和系統(tǒng)版本、是否必現(xiàn)。這些信息看起來簡單但如果第一個反饋人說“經(jīng)常無響應”就埋頭開干很容易被偶發(fā)性帶到溝里去。以前我用過一個笨辦法讓用戶下次卡住的時候按一下刷新鍵問“刷新后能不能恢復”再問“卡住之前最后做的一個操作是什么”。這兩個問題的答案往往能直接縮小排查范圍。如果是刷新后恢復正常基本可以排除硬件和瀏覽器層面的問題重點考慮代碼里的資源占用或請求掛起如果是某個特定操作后必現(xiàn)那就直接審查那個操作的實現(xiàn)代碼。判斷完現(xiàn)象和觸發(fā)場景之后再去選工具就會很有針對性。比如卡頓類問題重點看Long Tasks和FPS假死類問題重點看主線程時間軸上的長任務崩潰類問題重點看Memory面板的內(nèi)存曲線和堆快照對比。2. 定位工具鏈別靠肉眼猜讓數(shù)據(jù)說話定位“頁面無響應”最忌諱的就是憑空猜。這里先分享一個真實例子我之前有個同事排查頁面卡死他懷疑是某個第三方庫的Bug花了三天時間翻那個庫的源碼最后發(fā)現(xiàn)根因根本不是這個庫而是自己業(yè)務代碼里一個無意間寫出的無限循環(huán)。所以工具和數(shù)據(jù)永遠比感覺靠譜。2.1 Performance面板的正確打開方式用Performance面板錄制的核心操作其實不復雜打開DevTools切到Performance面板點擊錄制按鈕然后讓頁面執(zhí)行出那個“無響應”的操作再點停止。錄制完成后主線程的時間軸圖會清晰地展示每一幀的工作狀態(tài)。我自己的習慣是這樣的錄制前清一下瀏覽器緩存控制變量如果頁面是首次打開就出問題就從刷新前開始錄制如果是操作中出問題就先把頁面恢復到出問題前的狀態(tài)再開始錄。錄制時間控制在10到20秒太短抓不到長任務太長數(shù)據(jù)冗余反而難分析。停止錄制后我優(yōu)先看三個東西第一個是紅色的“長任務”標記。Chrome會直接把超過50毫秒的任務標紅這些就是阻塞用戶交互和渲染的元兇。點開標紅的任務塊能直接看到這個任務在哪個腳本、哪個函數(shù)上消耗了最多時間。第二個是FPS曲線。如果錄制期間FPS頻繁掉到20以下說明渲染鏈路有問題。FPS低不一定是JS的問題也可能是樣式計算、圖層合并導致的。第三個是“Summary”板塊里各類型時間占比。如果Scripting占比超過60%那JS計算就是瓶頸如果Rendering和Painting占比高就要去檢查CSS和圖層策略。為了抓偶發(fā)的假死問題我還會開Performance Monitor面板它是實時監(jiān)控CPU占用、JS堆大小和DOM節(jié)點數(shù)量的。設置成常駐窗口等頁面卡住的那一瞬間趕緊切過去截圖能看到卡死前CPU是不是100%、堆內(nèi)存是不是一直在漲。2.2 用Performance API做自動監(jiān)控手動錄制只能解決“能復現(xiàn)”的問題線上偶發(fā)問題靠人工盯著根本不現(xiàn)實所以我把Long Tasks的監(jiān)控代碼直接埋到了項目里。核心是利用瀏覽器的PerformanceObserver接口去監(jiān)聽長任務事件代碼很簡單const observer new PerformanceObserver((list) { for (const entry of list.getEntries()) { if (entry.duration 100) { // 上報到日志平臺記錄時長和來源腳本 report({ type: long-task, duration: entry.duration, startTime: entry.startTime, name: entry.name || , attribution: entry.attribution || [] }); } } }); observer.observe({ entryTypes: [longtask] });這里有一個細節(jié)Long Task API返回的attribution里包含TASKS.SCRIPT_URL這樣的屬性能直接告訴你是哪個腳本文件執(zhí)行超過了閾值這對定位第三方腳本導致的主線程阻塞非常有幫助。我在實際項目里就把好幾個廣告SDK的腳本錄出來了實錘是他們的問題。除了Long Task我還會用performance.getEntriesByType(navigation)去采集頁面加載階段的各階段耗時把DNS查詢、TCP連接、請求響應、DOM解析、腳本執(zhí)行這幾個關鍵耗時數(shù)據(jù)上報到監(jiān)控平臺。這樣每次頁面打開耗時多少、哪一段耗時異常都有數(shù)據(jù)支撐不用等用戶反饋。另外我強烈推薦所有前端團隊都去用一下瀏覽器自帶的“任務管理器”。它不是DevTools里的那個Memory面板而是瀏覽器右上角菜單里的“更多工具-任務管理器”。它能實時顯示每個標簽頁的CPU占用率和內(nèi)存占用頁面卡住的時候這個標簽頁的CPU如果飆到100%以上那你基本可以確定問題出在主線程計算密集或者有死循環(huán)如果CPU不高但內(nèi)存一直漲那方向就要轉向內(nèi)存泄漏。這個工具在真機模擬和線上問題排查時效率特別高很多新手都不知道它的存在。3. 深挖根因常見導致頁面無響應的五類元兇排查工具掌握之后下一步就是識別根因。我接手過不少“無響應”類問題總結下來絕大多數(shù)都跑不出下面五類原因對號入座就能省下一大半時間。3.1 主線程被長任務霸占同步計算和大數(shù)據(jù)處理這是最常見的一類。頁面主線程本來就要承擔事件處理、樣式計算、渲染、布局、垃圾回收這些活一旦一個同步任務占了超過某個時間片段瀏覽器的整體響應就會變得不跟手。如果這個任務超過一兩秒頁面就直接進入“無響應”狀態(tài)。我處理過一個數(shù)據(jù)可視化的項目每次篩選數(shù)據(jù)都會卡死。最后定位到問題出在一段對兩三萬條數(shù)據(jù)進行多層filter和sort操作上。每次篩選都同步處理還要同時生成若干個圖表配置對象主線程直接被打滿。這種場景的優(yōu)化思路我后面會詳細講核心就是兩條把大任務拆成小任務或者把重計算挪到Worker線程。判斷一段代碼是不是長任務可以手動看執(zhí)行時間但更推薦用Performance面板錄制直接看標紅的區(qū)塊和對應的函數(shù)名。如果函數(shù)名是被壓縮過的比如上線后的代碼記得在Sources面板里開啟Source Map才能定位到源碼。3.2 渲染層頻繁重排重繪布局抖動和樣式風暴頁面“無響應”和“卡頓”經(jīng)常是疊加出現(xiàn)的其中渲染層的頻繁重排重繪是很重要的一環(huán)。有些操作本身不算重但如果在一個高頻觸發(fā)的流程里反復觸發(fā)強制同步布局整個頁面就會變得非?？?。最典型的反模式是在循環(huán)里不停地讀offsetWidth、clientTop這樣的布局屬性然后立刻修改樣式。瀏覽器為了返回正確的布局值只能中止當前的樣式計算和布局流程強制做一次同步重排這就是強制同步布局也叫布局抖動。一兩個還好循環(huán)里調(diào)幾千次渲染線程直接崩潰頁面表現(xiàn)為滾動卡成PPT、點擊延遲幾秒。3.3 內(nèi)存泄漏堆內(nèi)存越漲越高最終引發(fā)渲染進程崩潰內(nèi)存泄漏導致的“無響應”有一個顯著特征頁面剛打開的時候是好的用著用著越來越卡最后點什么都沒反應嚴重時標簽頁直接崩潰。這種問題你錄Performance面板還不夠得結合Memory面板的堆快照對比來排查。常見的泄漏源頭有幾個沒有清理的setInterval或setTimeout定時器、沒有被解綁的DOM事件監(jiān)聽器、全局變量引用、閉包意外持有的大對象、以及Vue或React里沒有正確銷毀的組件實例和watcher。我見過一個真實案例項目里用addEventListener注冊了滾動監(jiān)聽組件銷毀時忘了removeEventListener導致每次進出頁面都多一份監(jiān)聽器DOM節(jié)點和監(jiān)聽器越來越多最終頁面在低端機上徹底卡死。排查內(nèi)存泄漏我的建議是在Memory面板里連續(xù)采集三次堆快照加載完成時取一次、操作一段時間后取一次、觸發(fā)垃圾回收后再取一次。對比這三份快照如果一些對象的實例數(shù)只增不減那就是泄漏點。另外Chrome的Heap Snapshot里還支持按“Detached”來篩選被分離的DOM節(jié)點這些節(jié)點從文檔中摘除了但依然被JS引用著是最典型的泄漏對象。3.4 網(wǎng)絡層掛起有響應框但請求永遠在pending還有一種“無響應”比較迷惑頁面本身沒死按鈕也能點但所有請求都pending界面一直處于加載狀態(tài)。用戶感知就是“點哪兒都沒反應”。這類問題最常見的原因是后端接口過慢或者某個接口被并發(fā)請求拖垮前端沒有做超時控制。比如頁面上同時掛了十幾個接口其中有一個耗時30秒而這個接口阻塞了后續(xù)的關鍵內(nèi)容渲染用戶看到的就是一大片空白轉圈圈轉到懷疑人生。前端要做的優(yōu)化一方面是把必要的請求和可延后的請求分開核心鏈路先加載非核心模塊異步加載另一方面要給所有請求設置合理的超時時間配合統(tǒng)一的錯誤處理和重試策略。還有一個容易被忽視的坑是Service Worker如果你項目里注冊了Service Worker一旦它的緩存策略有問題會讓某些請求永遠處于pending狀態(tài)表現(xiàn)上跟“頁面無響應”一樣。我查過一個項目就是因為Service Worker的回調(diào)里Promise一直沒resolve導致頁面請求全部掛起。3.5 無限循環(huán)和異常遞歸代碼級Bug瞬間壓垮頁面最后這一類屬于硬核Bug型不是數(shù)據(jù)大也不是渲染復雜而是代碼寫錯了。最常見的是while循環(huán)條件寫反、遞歸沒有出口、或者一些不自知的高頻調(diào)用。比如我在項目里遇到過一個問題某個watch里監(jiān)聽了數(shù)據(jù)變化然后又修改了同一份數(shù)據(jù)觸發(fā)下一次watch形成了一個無限循環(huán)Vue還給了警告“You may have an infinite update loop in a component render function”但很多人忽略了。這種循環(huán)往往在幾秒內(nèi)就能讓CPU沖到極限頁面直接假死。排查這種問題最快的辦法是看Performance面板里長任務的調(diào)用棧如果在某個函數(shù)里反復循環(huán)跳不出來調(diào)用棧上看得很清楚。也可以用Node.js的--inspect調(diào)試遠程定位但前端場景還是DevTools性能錄制更直接。4. 優(yōu)化方案落地從一個長任務到一個順滑頁面通過前面幾步找到根因之后就到了真正動手優(yōu)化的階段。這一章我會把高頻用到的優(yōu)化方案拆開講每一類都可以直接“抄作業(yè)”式落地。4.1 拆解大任務時間切片和時間窗口“時間切片”的核心思想是把一個超過50毫秒的同步長任務拆成多個小于50毫秒的短任務讓瀏覽器有機會在每個任務間隙去響應事件和渲染頁面。這樣用戶的點擊不會等待太久頁面看起來就“有響應”。最簡單的一種拆分方式是用requestAnimationFrame分檔處理。比如要循環(huán)處理兩萬條數(shù)據(jù)可以每幀只處理一小部分代碼大致是這樣的function processLargeArray(items, processFn, batchSize 500) { let index 0; function nextBatch() { const end Math.min(index batchSize, items.length); for (; index end; index) { processFn(items[index]); } if (index items.length) { requestAnimationFrame(nextBatch); } } requestAnimationFrame(nextBatch); }這里用frames作為時間窗口每執(zhí)行完一批就讓出主線程讓頁面能處理用戶事件和渲染。如果任務不那么緊急可以用requestIdleCallback來執(zhí)行專門利用瀏覽器的空閑時間片避免阻塞關鍵交互。requestIdleCallback還帶一個超時參數(shù)可以控制它最多延遲多久“必要時可以等但不能無限等”。4.2 計算密集型任務交給Web Worker如果數(shù)據(jù)處理邏輯非常重比如解析大JSON、復雜計算、圖片處理、數(shù)據(jù)轉換前端的主線程真的不合適。這種場景最好把計算任務放到Web Worker里Worker運行在獨立的線程不會阻塞UI渲染。一個完整的Worker用法是這樣的主線程里通過new Worker(...)建一個子線程用postMessage傳參用onmessage接收結果。Worker內(nèi)部跑完計算后再把結果postMessage回主線程。核心代碼如下// main.js const worker new Worker(/workers/dataProcessor.js); worker.onmessage (e) { const result e.data; // 拿到計算結果再去更新渲染 renderList(result); }; worker.onerror (error) { console.error(Worker error:, error); }; // 把原始數(shù)據(jù)發(fā)給Worker worker.postMessage({ rawData, config }); // dataProcessor.js self.onmessage (e) { const { rawData, config } e.data; const result heavyProcess(rawData, config); self.postMessage(result); };這里要提醒兩件事第一Worker里拿不到DOM和window只能做純計算第二postMessage傳遞數(shù)據(jù)時會有結構化克隆的開銷如果數(shù)據(jù)特別大幾十MB級別能傳引用而不是全部拷貝就傳引用比如用Transferable對象。另外需要長駐的Worker記得在某個時機terminate()不然內(nèi)存管理也是個問題。4.3 大數(shù)據(jù)列表虛擬滾動是剛需列表渲染是前端性能問題的高發(fā)區(qū)。如果一個頁面要展示上千條、上萬條數(shù)據(jù)最簡單的v-for或者map生成DOM都會導致DOM節(jié)點爆炸首屏渲染就要很久滾動起來更新也很吃力。用戶操作起來就會明顯感覺“頁面無響應”。虛擬滾動的核心思路是不管總數(shù)據(jù)量有多大只渲染可視區(qū)域內(nèi)的那幾條DOM。監(jiān)聽滾動事件動態(tài)計算當前應該顯示的數(shù)據(jù)片段用一個上下偏移把真實滾動高度模擬出來。市面上現(xiàn)成的庫有vue-virtual-scroller、react-window等但我更推薦理解原理后自己寫一個輕量的因為在復雜業(yè)務里往往需要定制。核心思路很簡單容器固定高度內(nèi)容區(qū)的高度等于總條目數(shù)乘以每條目高度用來撐出滾動條根據(jù)容器的scrollTop計算出可視區(qū)域起始索引startIndex Math.floor(scrollTop / itemHeight)再根據(jù)容器高度算出endIndex真正渲染的只有startIndex到endIndex之間的那部分數(shù)據(jù)再絕對定位到正確位置。幾百行代碼就能實現(xiàn)一個夠用的版本性能提升是數(shù)量級的從幾萬個DOM節(jié)點直接降到幾十個。滾動的時候要注意配合防抖或requestAnimationFrame降低計算頻率不然監(jiān)聽器本身又是一個新的性能負擔。4.4 防抖和節(jié)流高頻事件的統(tǒng)一解法scroll、resize、mousemove、input輸入這類高頻事件如果handler里做的事情比較重都會給主線程增加大量壓力。這里防抖和節(jié)流的選用有一條經(jīng)驗法則如果目標事件是“用戶停止操作后再做一次”用防抖如果目標操作是“即使高頻觸發(fā)也要按固定頻率執(zhí)行”用節(jié)流。一個簡單的節(jié)流函數(shù)示例function throttle(fn, limit 100) { let inThrottle false; return function(...args) { if (!inThrottle) { fn.apply(this, args); inThrottle true; setTimeout(() { inThrottle false; }, limit); } }; } window.addEventListener(scroll, throttle(onScroll, 100));防抖函數(shù)核心是clearTimeout然后再setTimeout也是十幾行就能實現(xiàn)。不過我想強調(diào)的是不要為了用防抖而防抖而是要先量化一下handler到底消耗了多少資源。如果只是一個簡單的樣式切換防抖反而會降低交互響應速度得不償失。4.5 渲染優(yōu)化避免強制同步布局和長鏈式樣式更新要想頁面不卡渲染層的優(yōu)化同樣重要。首先要規(guī)避在布局信息讀取和樣式修改之間反復切換的問題。正確的做法是先批量讀取布局信息再批量修改樣式把讀寫分離。用一個例子說明// 不良寫法循環(huán)里讀一次改一次每次都觸發(fā)同步布局 for (let i 0; i items.length; i) { const width item.clientWidth; // 讀 item.style.width width 10 px; // 寫 } // 優(yōu)化寫法先統(tǒng)一讀再統(tǒng)一寫 const widths items.map(item item.clientWidth); items.forEach((item, i) { item.style.width widths[i] 10 px; });另外引起大面積重排的樣式屬性盡量避開。比如修改width、height、left、top這些會觸發(fā)布局的屬性如果動畫只需要視覺變化盡量用transform和opacity代替它們能走合成線程不觸發(fā)重排和重繪。如果頁面里有復雜的固定背景或遮罩層可以設置will-change屬性讓瀏覽器提前優(yōu)化但不要濫用否則內(nèi)存占用也會增加反而弄巧成拙。4.6 緩存與資源加載讓頁面最快進入可交互狀態(tài)從資源加載角度說頁面無響應也經(jīng)常和首屏加載時間過長有關。用戶在頁面白屏的那幾秒里反復點擊頁面還沒有綁定事件用戶的感覺就是“沒反應”。針對資源加載我會從三個層面去優(yōu)化第一代碼分拆把首屏不需要的代碼放到動態(tài)import里減少初始JS體積第二利用瀏覽器緩存策略對不常變的靜態(tài)資源和接口CDN做合理緩存第三關鍵渲染鏈路上的CSS同步加載非關鍵的CSS、JS全部異步或者延遲加載。這部分要特別注意一個反向優(yōu)化的坑緩存設置太久用戶更新不到新版頁面會反饋“頁面做這么爛點了都沒反應”。這種情況不是性能問題而是緩存策略和前端資源版本管理脫節(jié)了。我在nginx部署多個前端項目時就專門為不同項目設置了不同的資源路徑前綴配合文件指紋文件名加hash更新保證用戶既能享受緩存提速又能及時拿到新版本。這里可以看幾個核心的nginx配置思路location /project-a/ { alias /data/www/project-a/; try_files $uri $uri/ /project-a/index.html; location ~* \.(js|css|png|jpg|svg|woff2?)$ { expires 30d; # 帶hash的靜態(tài)資源可以放心長緩存 add_header Cache-Control public, immutable; } } location /project-b/ { alias /data/www/project-b/; try_files $uri $uri/ /project-b/index.html; location ~* \.html$ { add_header Cache-Control no-cache; # html入口不做長緩存 } }不明白Cache-Control的人很容易把“緩存”和“無響應”搞混。拿到一個“頁面無響應”的反饋先確認一下是渲染問題、數(shù)據(jù)加載問題還是緩存策略問題這一步很關鍵。5. 一次完整實戰(zhàn)線上偶發(fā)卡死的定位與修復記錄理論講了不少我再用一個實際處理過的案例把從接需求到一次修復的全流程串一遍。這個案例是一個后臺管理系統(tǒng)技術棧是Vue Element Plus用戶反饋在某個低配Windows電腦上打開某條列表數(shù)據(jù)詳情頁之后頁面頻繁進入“未響應”狀態(tài)每次持續(xù)幾秒到十幾秒不定運氣好能自己緩過來運氣差直接白屏。5.1 第一輪采集信息確認觸發(fā)條件我接到反饋后沒有直接動代碼先遠程到用戶的電腦上看了一下現(xiàn)場。排查后確認了幾個關鍵信息只在Windows上的Chrome低版本復現(xiàn)打開詳情頁之后點擊左側菜單切換路由時必卡頁面停留越久卡死概率越高刷新后能恢復正常但再點進詳情頁又會復發(fā)。這個信息里有幾個關鍵詞給了我方向“切換路由時必卡”意味著路由切換這個動作觸發(fā)了某個重操作“停留越久概率越高”意味著可能有狀態(tài)在累積或者內(nèi)存占用越來越高“刷新能恢復”說明不是瀏覽器層面的徹底崩潰而是運行時資源耗盡。當時我順手打開了瀏覽器自帶的任務管理器頁面卡住的時候看到Chrome的CPU占用率在120%到300%之間瘋狂波動。到這里我可以基本鎖定問題是主線程任務過重。5.2 第二輪性能錄制找到具體長任務接著我在本機開始復現(xiàn)。先在DevTools里打開Performance面板開始錄制然后模擬用戶一路進入詳情頁再切菜單10秒后停止錄制。時間軸上一片紅色長任務最長的幾個任務耗時在1200毫秒到3000毫秒不等。點開最長的那個任務調(diào)用棧指向了一個組件內(nèi)的computed屬性函數(shù)名字被壓縮過但順著Source Map就能定位到源碼。這個computed做的事情是把詳情頁里的一個幾千條元素的數(shù)組按若干維度做篩選、排序、再組裝成樹形結構。按設計它只在數(shù)據(jù)變化時重算一次但實際上詳情頁里還有一個定時器每5秒去輪詢一次后端接口刷新數(shù)據(jù)而輪詢回來的新對象會被直接賦值給響應式數(shù)據(jù)于是computed頻繁觸發(fā)每次都要重新算一遍幾千條數(shù)據(jù)的樹形結構主線程被徹底拖垮。定位到問題之后我給這次問題定了性業(yè)務定時輪詢觸發(fā)了全量重算復雜度是O(N^3)級別的多循環(huán)嵌套加上數(shù)據(jù)量本身不小導致單次計算超過1秒。路由切換時又把舊的組件銷毀、新組件渲染疊加在一起長任務就更加明顯。5.3 第三輪分步優(yōu)化最終穩(wěn)定平滑修復分了三步走。第一步把輪詢數(shù)據(jù)的更新方式從“整體覆蓋”改成“按需合并”。后端返回的新列表先跟當前列表做差異對比只有真正變化的字段和條目才觸發(fā)響應式更新。這里用一個Map以ID為鍵做映射判斷前后數(shù)據(jù)是否相同相同就跳過賦值。這個改動直接讓computed的觸發(fā)頻率降低了95%以上。第二步把樹形結構的組裝從computed里拿出來。因為這個計算確實是頁面展示依賴的不能省但計算成本太高所以我把它改成了懶計算加緩存只有用戶真正展開某棵子樹的時候才去計算那一層的結構并且用緩存存儲已展開的節(jié)點避免重復計算。這一步把單次計算時間從1000毫秒降到了180毫秒左右。第三步給渲染層加上虛擬滾動。詳情頁里展示樹形數(shù)據(jù)的區(qū)域一次最多只渲染可視區(qū)域內(nèi)的節(jié)點配合展開狀態(tài)做局部更新。這一步看著是渲染優(yōu)化其實是給整體交互“松綁”即使數(shù)據(jù)再多一些也不至于重新回到卡頓狀態(tài)。優(yōu)化完之后我又回到用戶那臺低配電腦上實測。優(yōu)化前打開詳情頁然后點菜單平均等待3到5秒才有反應優(yōu)化后點擊菜單到新的頁面渲染出來基本穩(wěn)定在200到300毫秒CPU占用率從峰值300%降到60%以下。后來再也沒收到過這個頁面的“無響應”反饋。整個過程走下來我的體感是定位這類問題核心不是會多少API而是能否一步一步縮小范圍用數(shù)據(jù)做決策。Performance錄制定位長任務、任務管理器看CPU、Memory對比堆快照這三板斧足夠應付90%的頁面無響應問題?，F(xiàn)在哪怕接到的反饋只有一句“頁面卡了”我也會先把這三個工具順手開起來等下次再犯的時候就能抓到現(xiàn)場后面的事情就好辦多了。再分享一個小技巧解決完一個問題之后不要急著關掉DevTools。順手把這次的復現(xiàn)路徑、長任務截圖、優(yōu)化前后數(shù)據(jù)對比整理到團隊的wiki或文檔里。以后再遇到類似問題先搜文檔很多坑前人已經(jīng)替你踩過了。另外如果有余力可以把5.2里那個PerformanceObserver的長任務監(jiān)控埋到生產(chǎn)環(huán)境里設置合理的上報閾值這樣線上問題就不再完全依賴用戶反饋了你甚至能在用戶感知之前就發(fā)現(xiàn)隱患。