登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  前端

前端长列表虚拟滚动实战:从可视区计算到滚动流畅

来源:17golang原创

时间:2026-06-17 12:35:30 111浏览 收藏

前端页面一次性渲染几千甚至几万行数据时,最明显的问题就是滚动卡顿、内存升高、页面响应慢。用户只是想看列表里的某一段数据,浏览器却要同时维护全部 DOM 节点,这对主线程和布局计算都很不友好。

虚拟滚动的核心思路很朴素:保持列表总高度不变,但页面里只渲染可视区域附近的一小段数据。本文按完整工作流讲解一个基础版虚拟列表怎么设计、怎么计算、怎么验证效果。

目录
  • 目标和边界:虚拟滚动解决什么问题
  • 全流程总览:虚拟列表从滚动到渲染
  • 阶段一:固定行高和滚动容器
  • 阶段二:计算可视区 start 和 end
  • 阶段三:用上下占位保持总高度
  • 阶段四:排查卡顿并验证优化效果
  • 我的推荐流程
  • 容易踩坑的地方
  • 落地速查表

目标和边界:虚拟滚动解决什么问题

本文示例假设列表有 10000 条数据,每行高度固定为 40px,滚动容器高度为 400px。也就是说,页面同一时间最多看到十几行内容,但完整列表总高度需要表现为 400000px。

先说结论:虚拟列表不是减少数据量,而是减少同一时间存在的 DOM 节点。它适合行高可控、列表项结构相对稳定、数据量很大的场景。如果每行高度完全不固定,需要额外维护高度缓存,这篇先不展开。

全流程总览:虚拟列表从滚动到渲染

完整流程可以拆成五步:监听滚动容器,计算当前可视区,设置顶部占位,只渲染窗口数据,再设置底部占位。

前端虚拟列表从滚动容器、计算区间、顶部占位、渲染窗口到底部占位的流程图

阶段 目标 关键动作 检查点
滚动容器 拿到滚动位置 读取 scrollTop 滚动时位置连续变化
计算区间 找出可见数据范围 计算 startend 可见行与滚动位置一致
顶部占位 撑开上方已滚过的高度 start * itemHeight 滚动条位置不跳动
渲染窗口 只创建少量节点 截取当前窗口数据 DOM 数量稳定
底部占位 撑开剩余高度 (total - end - 1) * itemHeight 列表总高度正确

阶段一:固定行高和滚动容器

先把基础参数定下来。固定行高能让区间计算非常简单,也更适合入门实现。

const total = 10000;
const itemHeight = 40;
const containerHeight = 400;
const buffer = 5;

滚动容器需要固定高度并允许纵向滚动。列表内部通过上下占位元素保持完整高度,而不是把 10000 行全部放进 DOM。

.list-container {
  height: 400px;
  overflow-y: auto;
}

.list-row {
  height: 40px;
  line-height: 40px;
}

阶段二:计算可视区 start 和 end

滚动时读取 scrollTop,用它除以行高得到开始索引。为了避免快速滚动时白屏,通常会在前后多渲染几行缓冲数据。

function getRange(scrollTop) {
  const visibleCount = Math.ceil(containerHeight / itemHeight);
  const rawStart = Math.floor(scrollTop / itemHeight);
  const start = Math.max(0, rawStart - buffer);
  const end = Math.min(total - 1, rawStart + visibleCount + buffer);

  return { start, end };
}

检查点:向下滚动时,start 应该逐步增大,end 跟着移动;滚到顶部时 start 应该回到 0。

阶段三:用上下占位保持总高度

拿到区间以后,只截取当前窗口里的数据,再计算上下两个占位高度。

function buildView(data, range) {
  const visibleItems = data.slice(range.start, range.end + 1);
  const topHeight = range.start * itemHeight;
  const bottomHeight = (total - range.end - 1) * itemHeight;

  return {
    visibleItems,
    topHeight,
    bottomHeight
  };
}

渲染结构可以理解成三段:顶部空白、真实列表项、底部空白。用户看到的列表仍然像完整高度一样滚动,但浏览器只维护当前窗口附近的少量节点。

当前窗口数据

阶段四:排查卡顿并验证优化效果

如果没有虚拟滚动,页面可能一次创建 10000 个列表节点。改成虚拟列表后,常见状态是只保留几十个节点,滚动时更新窗口数据。

前端长列表从全部渲染导致卡顿到只渲染窗口实现滚动流畅的前后对比图

可以用三个信号判断优化是否有效:

  • Elements 面板里列表项节点数量稳定,不再随着总数据量增长。
  • Performance 记录中长任务减少,滚动过程更连续。
  • 内存占用明显下降,快速滚动时没有大面积空白。

我的推荐流程

  1. 先确认列表项行高是否固定,能固定就先用固定行高方案。
  2. 给滚动容器设置明确高度,避免容器高度随内容变化。
  3. scrollTopitemHeight 计算可视区。
  4. 加入前后缓冲行,减少快速滚动时的空白感。
  5. 用上下占位撑开总高度,真实 DOM 只放窗口数据。
  6. 用浏览器性能工具确认 DOM 数量、长任务和内存变化。

容易踩坑的地方

  • 忘记底部占位:滚动条高度会变短,用户无法滚到真实末尾。
  • 缓冲行太少:快速滚动时可能出现短暂空白。
  • 缓冲行太多:DOM 节点又变多,优化效果下降。
  • 行高不一致却按固定行高算:滚动位置会越来越偏。
  • 每次滚动都做复杂计算:主线程仍然可能卡顿。

落地速查表

检查项 建议 通过标准
容器高度 固定高度加滚动 能稳定读取 scrollTop
行高 入门先固定行高 索引和可视行对应准确
渲染数量 可见行加少量缓冲 DOM 数量保持几十级别
占位高度 上下都要计算 滚动条总高度不跳变
性能验证 看长任务、内存和滚动连续性 滚动过程稳定流畅

总结一下:虚拟滚动的关键不是复杂算法,而是把“完整列表高度”和“真实渲染节点”分开。总高度用占位元素保留,真实节点只渲染当前窗口。按这个流程落地,前端长列表的卡顿问题通常会有非常明显的改善。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>