直接渲染10万条数据会卡死浏览器，因DOM节点超量引发内存飙升与高频重排；虚拟滚动仅渲染可视区+缓冲区节点，用占位层撑高滚动条、transform定位内容，避免同步布局计算。
为什么直接渲染10万条数据会卡死
浏览器渲染性能瓶颈主要来自 DOM 节点数量和重排（reflow）频率。10万条 <li> 意味着至少 10 万个真实节点，内存占用飙升，滚动时每帧都要计算样式、布局、绘制，GPU 都救不回来。
虚拟滚动不解决“数据多”，而是绕过“全量渲染”——只让当前可视区 + 少量缓冲区的节点真实存在 DOM 中，其余用空白占位撑起滚动条高度。
- 典型症状：
RangeError: Maximum call stack size exceeded或滚动瞬间白屏、卡顿超过 200ms - 关键判断点：列表项是否固定高度？是 → 用
transform+ 总高度占位；否 → 必须引入测量/缓存机制，复杂度翻倍 - 不要试图在
v-for/map()里直接遍历全部数据再过滤，那只是“假装虚拟”，DOM 还是全在
HTML 结构必须包含的三个 DOM 层级
虚拟滚动不是纯 JS 逻辑，HTML 结构本身要配合“撑高 + 截断 + 定位”三步走。漏掉任一层，滚动条就失效或内容错位。
- 外层容器：
<div class="viewport" style="height: 500px; overflow-y: auto;"> —— 必须设固定高 + <code>overflow-y: auto，它是用户唯一可见的“窗口” - 幽灵占位层：
<div class="phantom" style="height: 800000px;"></div>—— 高度 =data.length * itemHeight，里面空着，只为让滚动条有“总长度感” - 真实内容层：
<div class="list-items"></div>—— 只放当前slice(startIndex, endIndex)的节点，用style="transform: translateY(1280px)"对齐位置 - 错误写法：
el.style.top = scrollTop + 'px'→ 每次滚动都强制重排 - 正确写法：
el.style.transform = 'translateY(' + offset + 'px)'→ 只更新图层位置 - 注意：offset 不是
scrollTop，而是startIndex * itemHeight，它对应的是“这批数据本该在完整列表里的起始像素位置” - 推荐节流间隔：
16ms（≈60fps），用setTimeout或lodash.throttle(scrollHandler, 16) - 别依赖
requestAnimationFrame单独节流：它只保证“下一帧执行”，但无法限制调用频次，快速滚动时仍可能堆积多个未执行任务 - 边界检查必须做：当
scrollTop + viewportHeight >= totalHeight时，endIndex要取data.length，否则最后一屏渲染不全
transform: translateY() 为什么比 top 或 paddingTop 更稳
滚动过程中频繁修改 top 或 paddingTop 会触发浏览器同步重排（reflow），尤其在低端设备上帧率直接掉到 10fps。而 transform 是合成层操作，走 GPU，不触发布局计算。
立即学习“前端免费学习笔记（深入）”；
滚动监听必须加节流，且不能只靠 requestAnimationFrame
原生 scroll 事件在 Chrome/Firefox 中每秒可触发上百次，不做控制，slice() + innerHTML 或 appendChild 会疯狂执行，CPU 占用拉满。
实际项目中最容易被忽略的，是缓冲区（buffer）大小与滚动速度的匹配关系。设缓冲区为 5 条，但用户猛划屏幕，scrollTop 瞬间跳变 20 行，就会漏掉中间数据、出现白屏。缓冲区至少要 ≥ 可视行数 × 1.5，并配合骨架屏兜底。
