老实说，

上周面试。我被问到一个看似简单却极具挑战性的题目——“页面上要渲染10万条数据，不能分页，怎么做？”那一刻，我感到一种莫名的压力：如果手写失误，白屏、卡顿都会被现场评判。

我立即想到了虚拟列表。面试官点头示意，却又严肃地说：“那你手写一个。”我心里暗自嘀咕：这不是小菜一碟吗？于是打开编辑器，用AI生成了一版代码——它能跑，看起来没问题。但当面试官快速滚动时页面竟闪现白屏。我彻底懵逼了，

先看AI生成的版本——能跑，但有坑

AI给出的代码大致如下：

function VirtualList {
const = useState;const startIndex = Math.floor;const endIndex = Math.min(
startIndex + Math.ceil + 1,items.length
);const visibleItems = items.slice;const totalHeight = items.length * itemHeight;const offsetY = startIndex * itemHeight;return (

setScrollTop}
>


{visibleItems.map => (

第 {items} 行

))}



);}

至于逻辑无误。可见范围，只渲染几十个 DOM，用 transform 位移到正确位置。只是当快速拖动滚动条时却出现了白屏。

说到原因很直观，onScroll 是异步触发。浏览器已将视口滚动到新位置，但 React 尚未完成状态更新和重渲染。旧节点被滚出视口，新节点尚未挂载——导致空白。

说到手写版。加一个缓冲区就够了

解决白屏的主要思路是overscan——在可视区域上下预渲染若干行，让快速滚动时仍有“存货”可展示。

function VirtualList {
const = useState;按理说，const overscan = 5;// 上下各预渲染5行
const visibleCount = Math.ceil;const startIndex = Math.max(
overscan,Math.floor - overscan
);话说回来，const endIndex = Math.min(
Math.floor + visibleCount + overscan。items.length
);const visibleItems = items.slice;const totalHeight = items.length * itemHeight;const offsetY = startIndex * itemHeight;return (

setScrollTop}
>


{visibleItems.map => (

第 {startIndex + i + 1} 行

))}



);}

主要变化仅三行：

+const overscan = 5;-const startIndex = Math.floor;+const startIndex = Math.max-oversca​n);-const endInd…其实，

上下各多渲染5行后即使快速滑动。也不会出现空白，因为这些行已经在 DOM 中准备好。

面试官的6个追问

追问1的观点是，为什么用transform而不是padding-top？话说回来，

// ❌ padding-top方案

// ✅ transform方案

区别：

• padding-top: 会触发布局重排。浏览器需重新计算所有元素的位置。
• transform: 则只触发合成。GPU直接移动图层，不经过 Layout 和 Paint。

追问2这方面，如果每行高度不固定怎么办？

This is toughest part of virtual lists.

• Avoid using fixed math like scrollTop/itemHeight.
• Create an estimated baseline and refine after rendering.

function useDynamicVirtualList{
...
}

The gist is to keep a map of measured heights and recompute offsets on demand.

再看追问3，onScroll会不会触发太频繁？

• Avoid re-rendering every scroll event.
• Cleverly throttle via requestAnimationFrame:

const rafRef=useRef;按理说，const handleScroll==>{
if cancelAnimationFrame;rafRef.current=requestAnimationFrame=>setScrollTop);}，老实说，

&‌&;requestAnimationFrame aligns updates with browser repaint cycles。preventing frame tearing that plain throttle/setTimeout might cause.
javascript

再看追问4，key应该用什么？


普通列表常用索引键，但虚拟列表中同一键可能映射不同数据导致内容错乱。按理说，**必须使用数据唯一 ID 或绝对索引**。tsx
// ❌ 用 index
{visibleItems.map=>))}
// ✅ 用真实ID或绝对索引
{visibleItems.map=>))}



至于追问5，虚拟列表和时间分片哪个更适合？


维度 
虚拟列表 
时间分片 



DOM数量 
始终很少 
全部挂载后才完成 

内存使用 
低 
高 

首屏速度 
快 
慢 

滚动体验 
需要处理白屏、需缓冲区才能平滑 | 原生滚动实现更丝滑 | 场景适配性强 | 支持无限加载等高级需求 | 对性能影响较小 | 高度动态化需要额外处理 | 必须自行实现复杂逻辑与调优 | 对开发者掌握深度要求高 | 在大型项目中不可避免使用第三方库 |
。因为数据量增加，时间分片会因为所有 DOM 均挂载导致内存爆炸。
虚拟列表通过动态渲染保持低内存使用，是大规模数据展示必选方案。
当你想把 UI 分块更新以提高响应性时也可以考虑时间分片。但要注意最终所有 DOM 都会存在于页面中，会显著影响内存与性能。老实说，简单看，大型项目推荐采用成熟库如 @tanstack/react‑virtual。它们已将上述细节封装并提供可靠 API，使开发者专注业务，而非细节实现。如果你的业务涉及动态高度、横向滚动或无限加载等边界情况。一定要选择专业库，否则自行实现几百行代码难免产生 bug。
 您是否在生产环境中遇到过因缺少缓冲而导致的闪退或卡顿问题？您是否曾尝试过自定义时间分片来调整首屏加载？您如何判断是选用哪种技术更合适？考虑到当前技术栈和团队经验，请权衡一下两种方案，再决定是否需要底层实现。

小结


主要原理只渲染可见区，scrollTop 得到起止索引。

白屏原因onScroll 异步、无缓冲区导致旧节点消失、未挂新节点。

解决方法加 overscan 缓冲区、使用 transform 位移、请求动画帧节流、关键值正确、动态高度预估+修正。

进阶比较超5000条建议使用虚拟列表；小于5000条可考虑时间分片，但记住其最终会挂载所有 DOM。


手写能力在 AI 时代还有用吗？

面试官最终说的一句话让我印象深刻：

"AI 能生成虚拟列表，但它生成的版本会出现白屏。如果你知道原因并能修复，那才是真正体现你的价值。"*

虽然现在有成熟库如 @tanstack/react‑virtual 可以直接拿来使用，但真正了解其内部工作方式才能在生产环境里精准定位并解决 bug。当你面对未知错误时没有理论支撑只能盲目猜测，而有深厚基础就能快速定位根源。

You have seen this problem?You tried to fix it?How did you solve it?

如果你曾被问过“手写虚拟列表”。那说明面试官正想验证你对细节和性能把控的能力，而不仅仅是代码产出。别只满足于让 AI 写出来更要理解每一步背后的原理与调整技巧。