当你往一个表格组件里塞进几万行数据时，最先出现的问题往往不是报错，而是滚动条的拖动开始变得迟钝，CPU占用率飙升，内存持续增长，最后整个页面失去响应。造成这种现象的根本原因并不是数据本身太大，而是浏览器一次性创建了过多的DOM节点。每个单元格背后都是真实的元素对象，布局计算、样式匹配、绘制合成的工作量会随着节点数量线性增长。虚拟列表正是针对这个问题的解法：既然用户某一时刻只能看到屏幕上那几十行，那就只渲染这几十行，其余的用空白占位撑起滚动条。
为什么长列表会卡：先搞清楚渲染瓶颈
浏览器渲染一帧的预算大约是16毫秒，超过这个时间用户就能感知到明显卡顿。一个包含100列、10000行的表格意味着百万级别的DOM节点，光是把它们全部插入文档就可能耗费数秒。更糟的是，滚动事件触发时浏览器需要对可视区域重新计算布局和绘制，节点越多这个过程越慢。
其次要考虑内存成本。每个DOM节点在V8和浏览器内核中都有不小的开销，节点属性、事件监听、样式规则匹配都会占用内存。React和Vue这类框架还有额外的虚拟DOM树需要维护，diff计算的规模同样与节点数成正比。所以直接用分页组件的思路硬扛全量数据，无论怎么调参数都救不回来。
最后一个容易被忽视的因素是reflow的连锁反应。滚动容器的高度计算、行高不一致导致的动态测量，都会触发强制同步布局，这种抖动会让滚动帧率进一步下降。虚拟列表通过把节点数压缩到百级以内，从源头上消除了这三类问题。
虚拟列表的核心原理与原生实现
虚拟列表的实现由三个关键部分组成：一个有确定总高度的滚动容器、一块在滚动时做位移补偿的可视层、以及根据滚动位置动态计算出的渲染区间。整体高度通常用一个空的占位元素撑起，让滚动条长度与全量数据匹配；可视层使用绝对定位，通过transform或top偏移把当前应该显示的行移动到屏幕内。
下面是一个原生JavaScript的实现骨架，行高固定时逻辑最简单，先用占位div撑起总高度，再监听scroll事件计算起始索引：
function VirtualTable({ rows, rowHeight = 40, viewportHeight = 600 }) {
const totalHeight = rows.length * rowHeight;
const container = document.getElementById('vt-viewport');
const content = document.getElementById('vt-content');
container.style.height = viewportHeight + 'px';
content.style.height = totalHeight + 'px';
container.addEventListener('scroll', () => {
// 计算当前滚动位置对应的数据起点，上下多渲染几行做缓冲
const buffer = 5;
const scrollTop = container.scrollTop;
const startIndex = Math.max(0, Math.floor(scrollTop / rowHeight) - buffer);
const endIndex = Math.min(
rows.length,
Math.ceil((scrollTop + viewportHeight) / rowHeight) + buffer
);
const visible = rows.slice(startIndex, endIndex);
renderRows(visible, startIndex);
});
function renderRows(visible, startIndex) {
// 可视层整体位移，避免逐行设置位置
content.style.transform = `translateY(${startIndex * rowHeight}px)`;
// 只替换可视区域的行，innerHTML仅为示意
content.innerHTML = visible
.map(row => buildRowHtml(row))
.join('');
}
}这个实现的关键点有两个：一是用translateY做整体位移而不是给每行单独设置top，前者只触发合成层动画，性能远好于后者；二是预留buffer缓冲行，避免快速滚动时上下边缘出现空白闪烁。
行高不固定的情况要复杂一些。常见做法是先估算高度并缓存真实高度，滚动后用ResizeObserver或getBoundingClientRect测量实际值，再修正缓存和总高度。如果不想自己处理这些细节，可以直接使用成熟库，下一节的方案对比会给出选择建议。
主流方案对比：自研、Vue与React生态库怎么选
原生实现的优点是完全可控、零依赖，适合对包体敏感或需要深度定制的项目。缺点是动态行高、横向虚拟化、表格列冻结这些需求都要自己写，工作量不小。如果项目已经使用框架，优先考虑生态内的成熟库。
Vue项目推荐vue-virtual-scroller，它由Vue核心团队成员维护，支持动态高度、支持RecycleScroller回收复用组件实例，配合表格使用时可以把每一行封装成组件：
<template>
<RecycleScroller
class="scroller"
:items="rows"
:item-size="40"
key-field="id"
v-slot="{ item }">
<div class="table-row">
<span class="cell">{{ item.name }}</span>
<span class="cell">{{ item.amount }}</span>
<span class="cell">{{ item.date }}</span>
</div>
</RecycleScroller>
</template>
<script>
import { RecycleScroller } from 'vue-virtual-scroller';
import 'vue-virtual-scroller/dist/vue-virtual-scroller.css';
export default {
components: { RecycleScroller },
data() {
return { rows: [] }; // 异步加载十万行数据
}
};
</script>React生态可选的库更多。react-window是轻量级首选，作者同时也是react-virtualized的作者，react-window可以看作它的精简重写版，体积只有几KB，API简单，适合绝大多数场景：
import { FixedSizeList } from 'react-window';
function Row({ index, style }) {
const item = rows[index];
return (
<div style={style} className="table-row">
<span className="cell">{item.name}</span>
<span className="cell">{item.amount}</span>
</div>
);
}
function VirtualTable() {
return (
<FixedSizeList
height={600}
itemCount={rows.length}
itemSize={40}
width="100%"
>
{Row}
</FixedSizeList>
);
}三者的取舍可以这样判断：需求简单、行高固定，react-window足够；需要动态高度和组件回收，vue-virtual-scroller或react-virtualized更合适；表格需要列冻结、可编辑单元格等复杂交互，可以考虑TanStack Virtual这类更底层的headless方案，它只负责计算不负责渲染，配合Element Plus或Ant Design的表格定制自由度最高。
落地时的常见坑与优化建议
第一个坑是滚动监听没有做节流或requestAnimationFrame调度。scroll事件触发频率可能高于帧率，直接在回调里重渲染会造成抖动，建议用rAF把渲染合并到下一帧执行。
第二个坑是key设置不当。列表项必须用稳定的业务id作为key，用数组索引当key会导致复用错乱，行内输入框的内容可能串行。另外要避免在行组件里做昂贵计算，必要时用memo缓存行渲染结果。
第三个坑是白屏问题。快速滚动到很远处时，同步计算加渲染来不及完成。除了加大buffer，还可以在数据侧做按需加载，结合分页接口分段拉取，配合IntersectionObserver预加载下一段数据。
资源方面值得关注的几个方向：TanStack Virtual的官方文档对虚拟化原理讲解得非常透彻；Chrome DevTools的Performance面板可以录制滚动帧，帮助定位是脚本耗时还是布局耗时；Lighthouse的trace模式适合做优化前后的量化对比。把这些工具用起来，基本就能覆盖大数据量表格从诊断到落地的完整链路。