虚拟滚动原理与结构详解

虚拟滚动不解决“数据多”，而是绕过“全量渲染”——只让当前可视区 + 少量缓冲区的节点真实存在 DOM 中，其余用空白占位撑起滚动条高度。

• 典型症状：RangeError: Maximum call stack size exceeded 或滚动瞬间白屏、卡顿超过 200ms
• 关键判断点：列表项是否固定高度？是 → 用 transform + 总高度占位；否 → 必须引入测量/缓存机制，复杂度翻倍
• 不要试图在 v-for / map() 里直接遍历全部数据再过滤，那只是“假装虚拟”，DOM 还是全在

HTML 结构必须包含的三个 DOM 层级

虚拟滚动不是纯 JS 逻辑，HTML 结构本身要配合“撑高 + 截断 + 定位”三步走。漏掉任一层，滚动条就失效或内容错位。

• 外层容器：
  —— 必须设固定高 + overflow-y: auto，它是用户唯一可见的“窗口”
• 幽灵占位层：
  —— 高度 = data.length * itemHeight，里面空着，只为让滚动条有“总长度感”
• 真实内容层：
  —— 只放当前 slice(startIndex, endIndex) 的节点，用 style="transform: translateY(1280px)" 对齐位置

transform: translateY() 为什么比 top 或 paddingTop 更稳

滚动过程中频繁修改 top 或 paddingTop 会触发浏览器同步重排（reflow），尤其在低端设备上帧率直接掉到 10fps。而 transform 是合成层操作，走 GPU，不触发布局计算。

• 错误写法：el.style.top = scrollTop + 'px' → 每次滚动都强制重排
• 正确写法：el.style.transform = 'translateY(' + offset + 'px)' → 只更新图层位置
• 注意：offset 不是 scrollTop，而是 startIndex * itemHeight，它对应的是“这批数据本该在完整列表里的起始像素位置”

滚动监听必须加节流，且不能只靠 requestAnimationFrame

原生 scroll 事件在 Chrome/Firefox 中每秒可触发上百次，不做控制，slice() + innerHTML 或 appendChild 会疯狂执行，CPU 占用拉满。

• 推荐节流间隔：16ms（≈60fps），用 setTimeout 或 lodash.throttle(scrollHandler, 16)
• 别依赖 requestAnimationFrame 单独节流：它只保证“下一帧执行”，但无法限制调用频次，快速滚动时仍可能堆积多个未执行任务
• 边界检查必须做：当 scrollTop + viewportHeight >= totalHeight 时，endIndex 要取 data.length，否则最后一屏渲染不全

实际项目中最容易被忽略的，是缓冲区（buffer）大小与滚动速度的匹配关系。设缓冲区为 5 条，但用户猛划屏幕，scrollTop 瞬间跳变 20 行，就会漏掉中间数据、出现白屏。缓冲区至少要 ≥ 可视行数 × 1.5，并配合骨架屏兜底。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~