前端长列表卡顿怎么优化：从全量 DOM 到虚拟列表架构

前端长列表卡顿的根因通常不是“浏览器太慢”，而是页面一次性挂了太多 DOM 节点，导致滚动输入、JS 更新、布局计算和绘制互相排队。虚拟列表的思路是只渲染可见区域附近的少量行，用占位高度保持滚动条长度，再随着滚动复用节点。这样列表数据可以有几千、几万条，但页面实际维护的 DOM 节点仍然保持在几十个量级。

规模背景：为什么 5000 行就能拖慢页面

后台表格、日志面板、消息列表、搜索结果页都容易遇到长列表问题。数据量从 200 条涨到 5000 条后，DOM 数量、样式匹配、布局计算、绘制区域都会一起变大。用户滚动时，浏览器需要处理输入事件、更新滚动位置、计算布局、绘制像素；如果中间任何一步耗时太长，就会表现为滚动发粘、点击延迟、输入框打字慢。

一个常见误区是只盯接口耗时。接口返回很快，并不代表页面渲染快。前端长列表优化要看主线程是否被排满，以及每次滚动需要改动多少 DOM。

原架构瓶颈：全量 DOM 把主线程排满

最朴素的写法是把所有行一次性渲染出来：

第 1 条记录
  
第 2 条记录
  ...
  
第 5000 条记录

这在数据少时没有问题，但行数上来后，任何状态变化都可能牵动大量节点。比如勾选一行、展开详情、切换筛选、滚动到下一屏，浏览器都要在庞大的节点树里重新计算一部分样式和布局。

这条等待链可以这样理解：用户滚动输入进来后，JS 任务先占用主线程；如果列表节点多，布局和绘制继续排队；等这些任务结束，浏览器才能响应下一次输入。卡顿不是某一行代码单独造成的，而是全量节点让每一步都变重。

新架构：虚拟列表只保留可见窗口

虚拟列表把问题拆成三个部分：

• 可见窗口：只渲染视口内和上下缓冲区内的行。
• 占位高度：用一个总高度容器撑出真实滚动条。
• 位移容器：把当前可见行移动到正确位置，让用户感觉列表仍然完整。

旧架构维护 5000 个节点，新架构可能只维护 40 到 80 个节点。数据量仍然存在，但 DOM 工作量被限制在可见窗口附近，主线程就不容易被布局和绘制任务挤满。

关键取舍：滚动精度、动态高度和交互状态

虚拟列表不是无代价优化，常见取舍有三类：

• 固定行高更简单：适合日志、订单、基础表格。行高固定时，可以直接用 `scrollTop / rowHeight` 计算起始索引。
• 动态行高更复杂：聊天消息、富文本卡片、图片列表高度不固定，需要记录每行实际高度，维护前缀高度表。
• 状态不能绑在 DOM 上：输入框内容、勾选状态、展开状态要存在数据层，否则节点复用后容易串行。

如果列表行有复杂交互，虚拟列表的核心不是“少渲染几个节点”这么简单，还要把状态、焦点、键盘导航、可访问性一起设计好。

最小实现：固定行高虚拟列表

下面是一个固定行高版本，适合先理解核心结构：

.viewport {
  height: 420px;
  overflow: auto;
  border: 1px solid #ddd;
}
.spacer {
  position: relative;
}
.items {
  position: absolute;
  left: 0;
  right: 0;
  top: 0;
}
.row {
  height: 36px;
  line-height: 36px;
  padding: 0 12px;
  border-bottom: 1px solid #eee;
  box-sizing: border-box;
}

const total = 5000;
const rowHeight = 36;
const buffer = 8;
const data = Array.from({ length: total }, (_, i) => `记录 ${i + 1}`);

const viewport = document.querySelector('#viewport');
const spacer = document.querySelector('#spacer');
const items = document.querySelector('#items');
spacer.style.height = `${total * rowHeight}px`;

function render() {
  const scrollTop = viewport.scrollTop;
  const viewCount = Math.ceil(viewport.clientHeight / rowHeight);
  const start = Math.max(0, Math.floor(scrollTop / rowHeight) - buffer);
  const end = Math.min(total, start + viewCount + buffer * 2);

  items.style.transform = `translateY(${start * rowHeight}px)`;
  items.innerHTML = data.slice(start, end).map((text, offset) => {
    const index = start + offset;
    return `
${text}
`;
  }).join('');
}

viewport.addEventListener('scroll', () => {
  requestAnimationFrame(render);
});
render();

真实项目里不建议每次都用 `innerHTML` 重建所有可见行，可以按框架能力做列表组件，或复用节点减少创建成本。但这个最小版本足够展示虚拟列表的三件事：总高度、可见范围、位移。

上线结果：看哪些指标判断真的变顺了

上线后不要只凭“感觉顺了”。可以观察这些信号：

• DOM 节点总数是否明显下降。
• 滚动时长任务是否减少，主线程空闲时间是否增加。
• 低端设备上滚动帧率是否稳定。
• 展开、勾选、搜索、切页等交互状态是否没有串行。
• 首屏渲染和切换筛选后的可交互时间是否改善。

如果只是首屏快了，但快速滚动时空白、跳动、焦点丢失，就说明虚拟列表还没有处理好缓冲区、行高估算或状态管理。

后续改进

固定行高虚拟列表适合作为第一版。后续可以逐步补充动态行高、键盘导航、滚动位置恢复、服务端分页结合、列虚拟化、图片懒加载等能力。判断是否继续复杂化，要看业务压力：如果列表只是几百行，普通分页可能更简单；如果是日志、监控、订单、消息这类高频长列表，虚拟列表能把主线程从全量 DOM 的等待链里解放出来。