ARTICLE · 软件编程
2026 年了，十万级表格还只会「虚拟滚动」？难怪你的页面照样卡顿
一语总结本文指出大数据表格卡顿的根源在于主线程计算阻塞与状态管理不当，并提出通过 Web Worker 异步计算、倒排索引、Set 状态存储及 IndexedDB 分层架构，构建支撑百万级数据的表格系统。
文章指出，仅依赖「虚拟滚动」无法解决十万级数据表格在搜索、排序、筛选及全选操作下的卡顿与状态错乱问题。核心瓶颈在于 JS 主线程被全量数据同步计算阻塞，以及不合理的勾选状态设计。作者提出了一套分层优化方案：在计算层，通过 Web Worker 剥离耗时逻辑，利用倒排索引优化检索性能；在状态层，摒弃数组存储，采用 Set 实现 O(1) 读写，并利用标志位推导全选/半选状态，避免全量遍历；在架构层，建议引入 IndexedDB 实现按需加载，避免全量数据常驻内存。通过这些手段，可将渲染、计算与存储解耦，实现复杂交互下的丝滑体验。
- 虚拟滚动仅解决渲染层 DOM 冗余，无法解决计算阻塞问题。
虚拟滚动通过减少 DOM 节点提升渲染速度，但搜索、排序等操作若在主线程进行全量遍历，仍会导致 UI 掉帧与交互卡顿。
- 将耗时计算剥离至 Web Worker，是保证主线程流畅的关键。
通过将筛选、排序等 CPU 密集型任务移至后台线程，并仅回传 ID 列表等轻量数据，可彻底消除主线程阻塞。
- 勾选状态应基于数据推导而非 DOM 操作。
在虚拟滚动场景下，DOM 节点是动态变化的，必须使用 Set 存储选中 ID，并利用全选标志位与排除集（Excluded Set）推导状态，以防排序或筛选后的勾选错位。
- 采用分层架构应对百万级数据挑战。
通过 IndexedDB 存储全量数据，计算层异步化，渲染层按需读取，实现存储、计算、渲染三层解耦，避免内存溢出。
2026 年了，十万级表格还只会「虚拟滚动」？难怪你的页面照样卡顿
文章指出，仅依赖「虚拟滚动」无法解决十万级数据表格在搜索、排序、筛选及全选操作下的卡顿与状态错乱问题。核心瓶颈在于 JS 主线程被全量数据同步计算阻塞，以及不合理的勾选状态设计。作者提出了一套分层优化方案：在计算层，通过 Web Worker 剥离耗时逻辑，利用倒排索引优化检索性能；在状态层，摒弃数组存储，采用 Set 实现 O(1) 读写，并利用标志位推导全选/半选状态，避免全量遍历；在架构层，建议引入 IndexedDB 实现按需加载，避免全量数据常驻内存。通过这些手段，可将渲染、计算与存储解耦，实现复杂交互下的丝滑体验。
文章金句
"虚拟滚动只管 "画得快"，解决不了计算把主线程堵死的问题。
"所有耗 CPU 的纯计算，一律不准占用主线程。
"虚拟列表的勾选，只能靠数据推导，绝对不能靠 DOM 操作。
"勾选状态永远绑定唯一稳定 rowId，绝对不要绑定数组下标。