纯CSS无法实现真正的虚拟列表，因其缺乏滚动监听、动态索引计算和DOM按需挂载能力；核心逻辑必须由JS承担，CSS仅负责样式布局与定位。

纯 CSS 无法实现真正的虚拟列表——它没有滚动监听、无法动态计算可见索引、也不能按需挂载/卸载 DOM。所谓“CSS 实现虚拟列表”，本质是误传或混淆概念；真正可行的，是用 CSS（如 flex）配合 JS 动态控制渲染范围与定位，而核心逻辑必须由 JS 承担。

为什么不能只靠 Flex 布局实现虚拟列表

Flex 容器本身不具备「只渲染可视区域」的能力：flex-wrap 或 display: flex 仍会将全部子元素纳入文档流，浏览器照样创建全部 DOM 节点、计算全部样式、触发全部 layout。哪怕你用 visibility: hidden 或 transform: translateY() 移走元素，节点仍在内存里，性能瓶颈照旧。

常见错误现象：

• 写了 display: flex; flex-direction: column; 就以为“自动虚拟化”了
• 给所有 .item 加 opacity: 0 + pointer-events: none，但滚动依然卡顿
• 用 flex: none + height: 0 隐藏项，结果 layout 触发频繁，CPU 占用飙升

Flex 布局在虚拟列表中能做什么

Flex 可以作为「渲染容器」的样式层，但它只负责三件事：对齐、尺寸约束、子项顺序排列。它不参与数据切片、不决定哪些该 render、也不响应 scroll 事件。

立即学习“前端免费学习笔记（深入）”；

实操建议：

Wjs Localizing Video

用于端到端视频本地化流程的轻量编排器，路由至四个专注子技能——/wjs-transcribing-audio、/wjs-translating-subtitles...

下载

• 外层容器设固定 height 和 overflow-y: auto，这是滚动触发前提
• 内层列表容器用 display: flex; flex-direction: column;，便于线性堆叠和 translateY 定位
• 每个真实渲染的 .item 必须设明确 height（定高场景），否则无法精确计算偏移量 translateY
• 禁用 flex-wrap 和 align-items: stretch 等可能干扰高度计算的属性

JS 必须承担的核心计算逻辑

虚拟列表的“虚拟”二字，全靠 JS 在滚动时实时算出三组关键值：

• startIndex：当前可视区第一个应显示的数据索引
• endIndex：最后一个应显示的索引（含缓冲区）
• offset：整个渲染块相对于容器顶部的偏移（单位 px），用于 style.transform = `translateY(${offset}px)`

这些值依赖：

• scrollTop（来自 containerRef.scrollTop）
• itemHeight（必须是固定值，否则需预估或测量）
• containerHeight（容器 clientHeight）
• buffer（缓冲行数，通常 2–5 行）

示例片段（定高场景）：

const startIndex = Math.max(0, Math.floor(scrollTop.value / itemHeight));
const visibleCount = Math.ceil(containerHeight / itemHeight) + buffer * 2;
const endIndex = Math.min(items.length - 1, startIndex + visibleCount);
const offset = startIndex * itemHeight;

容易被忽略的 DOM 操作细节

即使逻辑算对了，DOM 更新方式不对，照样白搭：

• 不要每次滚动都 .innerHTML = '' 再拼接字符串——重排重绘开销极大
• 推荐用 DocumentFragment 批量 append，或复用已存在的 .item 元素（更新 textContent + dataset.index）
• 避免在滚动回调里直接操作 style.top，改用 transform: translateY()（触发 GPU 加速且不触发 layout）
• 务必节流 scroll 事件（requestIdleCallback 或 throttle），否则高频触发导致丢帧

定高虚拟列表的性能天花板，取决于 JS 计算是否轻量、DOM 复用是否彻底、以及 transform 是否稳定生效——CSS 只是舞台布景，演员永远是 JS。