前端虚拟列表实战：10 万条数据如何只渲染可视区域

后台系统、日志平台、订单列表、监控告警页，经常会遇到几万甚至十几万条数据。接口返回数据不是最慢的，真正把页面拖卡的往往是一次性创建太多 DOM 节点。

虚拟列表的思路很直接：页面看得到多少，就渲染多少；用户滚动到哪里，再换成那一段数据。本文用固定行高场景实现一个可落地的虚拟列表，先把原理跑通，再聊生产环境里的坑。

摘要

本文会从 10 万条数据全量渲染为什么卡讲起，逐步实现一个固定行高虚拟列表：根据滚动位置计算起止索引，用占位高度维持滚动条长度，只渲染可视区和缓冲区内的行，最后补充滚动抖动、动态高度和交互状态的注意点。

适合人群

• 正在做后台表格、日志列表、消息列表的前端同学。
• 想理解虚拟列表核心算法，而不是只会调用组件库的开发者。
• 已经掌握基础 JavaScript、CSS 布局和滚动事件的读者。

目录

1. 全量渲染为什么会卡
2. 虚拟列表的三个关键量
3. 实现固定行高虚拟列表
4. 加上缓冲区减少白屏
5. 生产环境常见坑
6. 总结

一、全量渲染为什么会卡

假设有 10 万条日志，如果直接用循环把每一条都插入页面，浏览器需要创建大量 DOM 节点，还要计算样式、布局、绘制。用户只是看到屏幕里的几十行，却让浏览器为看不到的 99900 多行付出成本。

这段代码看起来简单，但它会把压力集中到三个环节：DOM 节点数量暴涨、布局计算变慢、滚动时绘制成本变高。数据量继续上去后，页面可能出现首屏慢、滚动掉帧、输入框响应变迟钝等问题。

二、虚拟列表的三个关键量

固定行高虚拟列表的核心不是复杂算法，而是三个关键量：

• rowHeight：每一行高度，比如 40px。
• viewportHeight：滚动容器可视高度，比如 600px。
• scrollTop：当前滚动距离，用它推算用户看到了哪一段。

有了这三个量，就可以算出开始索引和结束索引：

const start = Math.floor(scrollTop / rowHeight);
const visibleCount = Math.ceil(viewportHeight / rowHeight);
const end = start + visibleCount;

页面不再渲染全部数据，只渲染 rows.slice(start, end)。为了让滚动条长度看起来仍然代表 10 万条数据，需要用一个总高度容器撑开滚动区域。

三、实现固定行高虚拟列表

下面是一个最小可用版本。外层负责滚动，内层用总高度撑开滚动条，真正的行列表通过 transform 移动到正确位置。

这段代码里，真正存在于 DOM 中的行数大约是可视行数加两侧缓冲。即使总数据有 10 万条，页面也只维护几十个行节点，滚动压力就会小很多。

四、加上缓冲区减少白屏

如果只渲染屏幕里刚好可见的行，快速滚动时容易出现短暂白屏。缓冲区就是在可视区上下各多渲染几行，让用户滚动一点点时不用立刻换 DOM。

const buffer = 5;

const start = Math.max(0, rawStart - buffer);
const end = Math.min(
  rows.length,
  rawStart + visibleCount + buffer
);

缓冲区不是越大越好。它的本质是用少量额外 DOM 换更顺滑的滚动体验。后台系统常见的固定行高列表，可以先从 5 到 10 行试起，再结合设备性能和行内容复杂度调整。

五、生产环境常见坑

1. 行高必须稳定

固定行高方案依赖 rowHeight。如果每一行高度不同，滚动距离和索引的换算就会不准。这类场景要么限制行内容高度，要么引入动态高度缓存。

2. 不要在滚动回调里做重活

滚动事件触发频率很高，回调里尽量只做索引计算和必要渲染。复杂格式化、远程请求、统计上报都应该拆出去。

3. 注意选中、展开、输入状态

虚拟列表里的行会被反复创建和移除，状态不能只存在 DOM 上。比如复选框选中、行展开、输入框内容，都应该放到数据状态里，渲染时再还原。

4. 表格列宽要单独处理

如果虚拟列表用在表格里，横向滚动、固定列、表头对齐会增加复杂度。建议先把纵向虚拟滚动跑稳，再处理表格特性。

六、总结

虚拟列表解决的是一个很朴素的问题：用户只能看见一小段，页面就不应该渲染全部数据。固定行高场景下，只要掌握 scrollTop、rowHeight、viewportHeight 三个量，就能算出可视窗口，并通过占位高度保持滚动体验。

落地时记住三点：总高度负责滚动条，偏移量负责定位当前片段，缓冲区负责减少快速滚动时的白屏。这个基础版本吃透之后，再上组件库或处理动态高度，会更容易判断问题出在哪里。