十萬級表格只靠虛擬滾動不夠？一篇掘金長文重述前端效能瓶頸的技術輪廓

一篇發布於2026年9月17日掘金平臺的技術長文，以「十萬級表格還只會虛擬滾動」為題，主張在大數據量表格場景中，虛擬滾動僅能解決渲染層的DOM冗餘問題，真正的卡頓瓶頸多數來自主執行緒的同步計算阻塞與勾選狀態設計不當。文章作者署名「秋天的一陣風」，閱讀時長標註約9分鐘。本臺以回顧角度整理該文的核心論點、技術方案與可核實的討論脈絡。

文章的核心主張：渲染沒問題，問題在計算

該文從前端工程面試的經典題目切入：大數據量表格如何優化渲染效能。作者觀察，多數開發者的標準答案是「虛擬滾動」，也就是只渲染可視區域內的數十行DOM，減少頁面節點數量。

作者隨後指出實務上的落差：不少專案確實實作了虛擬滾動，DOM數量也降下來了，但一旦疊加即時搜尋、多條件排序、批次篩選與全選反選等互動操作，頁面仍出現卡頓、掉幀，甚至勾選錯位與狀態錯亂。文章因此提出核心判斷：專案中約九成的表格卡頓與狀態異常，根本原因並非「DOM太多」，而是全量數據計算阻塞主執行緒、勾選狀態設計不合理，以及大量數據無條件常駐記憶體三者。

技術脈絡上，這個判斷對應瀏覽器渲染模型的基本限制：JavaScript以單執行緒運行，十萬級數據的遍歷、比對與排序會佔滿主執行緒，UI渲染與使用者操作在同一段時間內無法被處理。虛擬滾動解決的是「畫得快」，解決不了計算把主執行緒堵死的問題。

虛擬滾動的邊界：文章如何界定它的能力範圍

文章回顧了主流開源元件庫實作虛擬滾動的共同思路：固定表格容器高度、監聽滾動位置、即時計算當前可視區域的起止行號，只渲染該區間加上下緩衝行的內容，並以撐開滾動高度與位移變換模擬完整的滾動條效果。

作者認為，這套機制已完整解決DOM節點過多帶來的渲染與重排問題，但在三個實戰高頻場景中無能為力：全量搜尋篩選導致的主執行緒阻塞、虛擬DOM場景下的全選與半選狀態聯動異常，以及排序或篩選之後勾選狀態錯位錯亂。這三項都屬於數據計算與狀態管理範疇，超出渲染優化的能力邊界。

搜尋與篩選的三層方案：防抖、Web Worker、倒排索引

針對十萬級表格最常見的卡頓場景，即即時輸入搜尋，文章指出常見的粗暴寫法是監聽輸入事件後，使用者每敲一個字元就對全量數據執行一次過濾遍歷。十萬級數據單次遍歷可能耗時數百毫秒，高頻輸入直接堵死主執行緒，表現為輸入延遲與點擊無回應。

文章提出由低成本到高階的三層遞進方案。第一層是函數防抖，設定約300毫秒的延遲，只在輸入停頓後觸發檢索，過濾掉多數無效計算。第二層是將耗時的篩選與比對邏輯移入Web Worker背景執行，讓計算與UI渲染互不佔用，並在通訊上做輕量化處理，Worker不回傳完整數據物件，只回傳匹配成功的ID列表，以降低通訊開銷。第三層針對高頻檢索的後臺系統，建議預先建立「關鍵詞對應行ID」的倒排索引，後續搜尋不再全量遍歷，把O(N)的遍歷降級為近似O(1)的查詢。

這三層方案在瀏覽器平臺均有成熟的公開技術文件與規範支撐。Web Worker屬於WHATWG HTML規範定義的標準API，防抖與倒排索引則是通用的工程實踐，文章的貢獻在於將三者按成本與適用場景排序，構成一條可直接落地的優化路徑。

訊源與脈絡：一篇個人技術長文的定位

需要說明的是，該文屬於個人作者的經驗分享，文中「九成表格卡頓並非DOM過多」等比例表述為作者個人實務觀察，並非來自公開的產業調查或統計數據。文章亦未附上具體專案的基準測試數據，效能改善幅度缺乏可複現的量化驗證。

不過，文章所依據的技術事實本身有跡可循。瀏覽器的單執行緒模型、主執行緒長任務導致掉幀、虛擬滾動只處理渲染層等，都是前端效能領域長期以來的共識性內容。React、Vue等主流框架生態中的虛擬列表元件，其文件也多以「渲染優化」界定自身能力範圍，並未承諾解決數據層的計算問題。

與此同時，業界對大規模前端數據處理的關注並非新鮮事。Web Worker在數據密集型網頁應用中的使用、IndexedDB等本地儲存方案的演進，以及近年來以OPFS（來源私有檔案系統）為代表的新一代瀏覽器儲存API，都屬於同一條技術脈絡：把數據層的重量從主執行緒剝離出去。該文的論點可視為這條脈絡在表格元件這一具體場景下的重述與整理。

後續觀察

該文發布於掘金平臺，屬於中文前端社羣常見的技術長文形態。文章的論證結構由渲染層問題、計算層問題到狀態管理層問題層層推進，結尾處雖因原文截斷未能完整呈現勾選狀態與記憶體管理的後續章節，但已公開的部分足以勾勒其整體主張：虛擬滾動是基礎設施，而非完整解答。

對工程實務而言，文章提出的檢核方向具有可操作性：當表格卡頓時，先釐清問題發生在渲染層還是計算層；當搜尋延遲時，先確認是否對全量數據做同步遍歷；當勾選錯亂時，先檢查狀態是否與行數據綁定而非與渲染索引綁定。這些判準的價值不依賴文中具體比例數字成立，可由開發者在各自專案中直接驗證。