纯CSS无法实现真正虚拟滚动，因其不能感知滚动位置、计算可视索引或动态更新渲染；核心逻辑必须由JS完成，CSS仅负责高效位移（如transform）与视觉优化。
纯 CSS 无法实现真正意义上的虚拟滚动——它没有能力感知滚动位置、计算可视索引或动态更新元素样式。所谓“CSS 虚拟滚动”，本质是用 CSS 配合 JS 做视觉优化，核心逻辑仍在 JS 中，CSS 只负责高效渲染和位移表达。
为什么不能只靠 overflow + height 实现虚拟滚动
设置 overflow: auto 和固定高度确实能出现滚动条，但这是浏览器原生滚动行为，不改变 DOM 渲染量。如果你把上万条数据全塞进 DOM 再设 height: 500px，页面照样卡死。这种写法只是“有滚动条”，不是“虚拟滚动”。
常见错误现象：
- 列表越长，内存占用越高，Chrome 任务管理器里进程 RSS 持续飙升
- 首次渲染耗时长，
DOMContentLoaded后仍卡顿数秒 - 滚动过程中频繁触发重排（reflow），尤其在低配设备上掉帧明显
transform: translateY() 是关键位移手段，但必须配合 JS 计算
虚拟滚动的视觉核心是：用一个固定高度的容器，内部只放当前可见的 N 个 <div>，再通过 <code>transform: translateY(${offset}px) 把它们“推”到正确位置。这个 offset 必须由 JS 实时计算：
立即学习“前端免费学习笔记（深入）”；
-
offset = startIndex * itemHeight—— 前提是每项等高；若高度不一，得维护一个位置映射数组（如positions[i]表示第 i 项顶部距首项距离） - 滚动监听要用
requestIdleCallback或节流（如 Lodash 的throttle(scrollHandler, 16)），避免高频触发重计算 - 务必给滚动容器加
position: relative，否则translateY会相对于视口定位，导致错位
示例片段（JS 计算 + 内联 style）：
const container = document.getElementById('list-container');
const itemHeight = 48;
container.addEventListener('scroll', () => {
const scrollTop = container.scrollTop;
const startIndex = Math.floor(scrollTop / itemHeight);
const offset = startIndex * itemHeight;
// 更新渲染区域 & 设置位移
listInner.style.transform = `translateY(${offset}px)`;
});
容易被忽略的 CSS 性能细节
即使位移逻辑正确，样式写法不当也会让 GPU 加速失效或触发重绘：
- 必须加
will-change: transform到被移动的元素（如.virtual-item），否则 Chrome 可能不升格为合成层 - 避免在
transform元素上同时写top/left或margin，这会导致 layout → paint → composite 全流程触发 - 占位元素（placeholder）高度要精确等于
totalItems * itemHeight，否则滚动条长度不准，用户拖动后实际位置和预期不符 - 移动端记得加
touch-action: none到滚动容器，禁用浏览器默认 touch 滚动干扰（尤其 iOS Safari）
第三方库（如 vue-virtual-scroller）封装了什么
以 RecycleScroller 为例，它帮你做了三件关键事：
- 自动维护
startIndex/endIndex，支持 variable-height 模式（通过itemSize函数） - 复用 DOM 节点（recycling），避免频繁
appendChild/removeChild，减少 GC 压力 - 内置防抖滚动监听 + requestIdleCallback 回调调度，不阻塞主线程
但它没帮你做的是：数据分片预加载、服务端排序/过滤后的偏移同步、键盘导航焦点管理——这些仍需你补全逻辑。
最易踩的坑是以为引入库就万事大吉，结果在 item 组件里写了 v-if 多层嵌套或未冻结响应式数据，导致每次 render 都触发大量依赖追踪，性能反而比手写还差。
