虚拟列表核心是只渲染可视区域DOM,通过动态复用+transform位置模拟实现;需固定容器高度、监听scroll、用getBoundingClientRect提升容错性,避免scrollTop异步问题。
浏览器卡顿、内存暴涨,往往不是数据量大,而是把几万条 全部塞进 DOM。虚拟列表不渲染全部项,只计算当前滚动位置对应的那几十个可见项,用 transform: translateY() 模拟整体滚动偏移。关键不是“懒加载”,而是“动态复用 + 位置模拟”。
scroll 或使用 IntersectionObserver 触发重算overflow-y: auto
requestIdleCallback + getBoundingClientRect 实现轻量版不依赖框架、不引入复杂状态管理时,这个组合足够应对中等规模(10w+ 条、固定行高)场景。重点是避免在滚动中同步计算,把定位逻辑交给空闲时段。
let startIndex = 0; let endIndex = 0;func
tion updateVisibleRange() { const container = document.getElementById('list-container'); const rect = container.getBoundingClientRect(); const scrollTop = container.scrollTop; const visibleHeight = rect.height;
// 假设每项高度为 48px const itemHeight = 48; startIndex = Math.max(0, Math.floor(scrollTop / itemHeight)); endIndex = Math.min(data.length, startIndex + Math.ceil(visibleHeight / itemHeight) + 2);
renderVisibleItems(); }
function renderVisibleItems() { const fragment = document.createDocumentFragment(); for (let i = startIndex; i < endIndex; i++) { const el = document.createElement('div'); el.style.position = 'absolute'; el.style.top =
${i * 48}px; el.style.width = '100%'; el.textContent = data[i]; fragment.appendChild(el); } listContainer.innerHTML = ''; listContainer.appendChild(fragment); }listContainer.addEventListener('scroll', () => { requestIdleCallback(updateVisibleRange); });
scrollTop 直接算,而要用 getBoundingClientRect?因为 scrollTop 在 iOS Safari 和部分安卓 WebView 中存在异步更新、抖动或延迟问题,尤其配合防抖时容易错帧。用 getBoundingClientRect 获取容器视口位置更稳定,再结合 container.scrollTop 计算逻辑起始索引,容错性更强。
scrollTop 是滚动容器自身的属性,但可能被 CSS transform、position: sticky 等干扰getBoundingClientRect 调用成本低,比反复读取 scrollTop 更可靠getBoundingClientRect 自动包含,无需手动修正框架自带 diff 和 key 机制,反而容易掩盖虚拟列表的关键约束——比如忘记清空未复用节点、误用 v-for 的索引作为 key、或在 style.top 中写死 px 却没加单位。
index 当 key:应改用数据唯一 ID,否则滚动时组件实例错乱v-for 必须配合 :key 和 style="transform: translateY(...)",不能依赖 margin-top 模拟位移getBoundingClientRect().height 可能为 0,导致 endIndex 算成 NaN滚动位置映射和 DOM 复用逻辑看似简单,但一旦数据结构嵌套、行高不一、或接入表头冻结/多列布局,边界条件会指数级增加。真正难的不是“怎么让它动起来”,而是“怎么保证它在各种缩放、字体加载、动态主题切换下都不错位”。