虚拟列表是什么？为什么能优化长列表性能？

简化版

虚拟列表用完整滚动高度模拟全部数据，但 DOM 只保留视口附近的窗口项；滚动时根据偏移计算区间并复用或替换节点，从而降低初始化、样式布局、框架 diff 和内存成本。固定高度可直接用公式定位，动态高度需要测量、前缀高度索引、滚动锚定和误差修正。

详细版

固定高度列表可计算 start=floor(scrollTop/itemHeight)，再渲染可见数加 overscan，并把窗口平移到 start×itemHeight。overscan 太小容易快速滚动白屏，太大又削弱 DOM 收益。

动态高度列表要缓存实测高度，用累计高度查找 scrollTop 对应索引；图片加载、展开收起会改变高度，需要 ResizeObserver 等方式更新并保持用户视口锚点。

虚拟化只优化渲染，不减少后端数据量、网络和排序成本。它还影响浏览器查找、打印、SEO、无障碍、键盘导航和定位到未渲染项，短列表不应默认采用。

完整版教学

一、长列表成本不只来自 DOM 节点数量

渲染 10,000 行时，框架要创建元素或组件，浏览器要做样式、布局与绘制，更新时还要协调差异。即使屏幕只看见 20 行，未显示节点也可能参与部分计算并占内存。

假设每行含 8 个 DOM 节点，10,000 行约 80,000 个节点；虚拟窗口保留 40 行则约 320 个，相差 250 倍。真实收益取决于每行复杂度，不能把节点数直接当耗时比例。

记忆钩子：虚拟列表保留“滚动空间的假象”，删除“不可见 DOM 的现实成本”。

二、固定高度窗口怎样计算

已知每项高 h、滚动偏移 scrollTop 和视口高 V，起始项与可见数可直接计算。再在上下加入 overscan，避免滚动时来不及渲染。

start = floor(scrollTop / h)
visible = ceil(V / h)
from = max(0, start - overscan)
to = min(N, start + visible + overscan)
offset = from × h
totalHeight = N × h

例如 N=10000、h=40px、V=800px、scrollTop=12000px，start=300、visible=20；overscan=5 时大约渲染索引 295 到 324 的 30 项，总占位高度为 400,000px。

三、占位容器与窗口平移如何欺骗滚动条

外层容器设置总高度，让浏览器滚动条比例像完整列表；内层窗口只放实际节点，并用 transform: translateY(offset) 定位到正确区域。滚动发生时更新数据窗口和 offset。

总容器 400000px
├─ 上方空白 11800px
├─ [实际 DOM: 30 行]
└─ 下方空白 ...

更新必须稳定使用数据 key，避免节点复用错位导致输入框内容串行。滚动处理常按 rAF 合并，不能每个事件都同步做昂贵框架提交。

四、overscan 是白屏风险与 DOM 成本的平衡

overscan 在视口之外多渲染几项，快速滚动时更平滑；设为 0 最省 DOM，却更容易在低端机上露出空白。固定 5 项对每项 20px 与 300px 的列表意义完全不同，也可按像素或滚动速度动态调整。

overscan	优点	风险
小	DOM 最少、更新快	快滚白屏
中	常规平衡	需按行高调节
大	滚动命中高	内存与渲染成本回升

假设每行渲染 1ms，overscan 从每侧 5 增到 50，多出 90 行约增加 90ms 初次工作，可能直接制造长任务。参数必须以目标设备 trace 调整。

五、动态高度为什么难得多

每项高度不同后，scrollTop/h 失效。系统需要记录已测高度、估算未测项，并维护累计高度；查找某个偏移对应索引可用前缀和加二分，而不是从头遍历。

height: [40, 80, 50, 120]
prefix: [0, 40, 120, 170, 290]
scrollTop=130 → 位于第 3 项区间 [120,170)

图片加载或文本展开会把 50px 变成 150px，后续项整体移动。若变化发生在视口上方，应调整 scrollTop 保持当前锚点视觉位置，否则用户会感觉列表突然跳动。

ResizeObserver 可捕获尺寸变化，但回调更新仍要防循环和批量处理。初始估算越准，滚动条跳变越小；同时需要缓存失效策略，因为容器宽度改变也会让文本高度变化。

六、工程边界：数据、可访问性与功能完整性

虚拟化不等于分页。即使 DOM 只有 30 行，一次下载 100,000 条数据、排序和保存在内存中仍然昂贵；网络和数据计算要另用服务端分页、游标或增量加载解决。

未渲染内容不在 DOM，浏览器原生查找、全页复制、打印和 SEO 会受影响。键盘 PageDown、焦点移动和屏幕阅读器还需要维护总数、位置语义和焦点项，即使目标项暂时不可见。

场景	是否常适合	原因
后台日志/表格	是	大量连续浏览，SEO弱
聊天记录	是但复杂	动态高度与向上加载
文章正文	通常否	查找、SEO、选择文本重要
100 条简单列表	通常没必要	普通渲染更稳定

定位到第 8000 项不能先创建前 7999 项，应利用高度索引计算偏移，再渲染目标窗口。异步数据未到时还需处理加载、失败与滚动恢复。

七、常见误区与追问

误区：虚拟列表能解决长列表的所有性能问题。 它主要减少渲染窗口，网络、数据处理和后端查询要分别优化。
误区：数据有上千条就必须虚拟化。 行结构、设备和交互决定实际成本，短而简单的列表可能无需复杂方案。
误区：动态高度只要测量一次即可。 图片、字体、容器宽度和展开状态都会让高度失效。
追问：固定高度怎样计算起始索引？ 用 floor(scrollTop/itemHeight)，再加可见数和 overscan 截取窗口。
追问：为什么需要 overscan？ 为快速滚动预留已渲染内容，代价是更多 DOM 与更新工作。
追问：滚动时高度变化怎样避免跳动？ 记录视口锚点，对其上方累计高度变化补偿 scrollTop。
追问：虚拟列表为什么影响无障碍和浏览器查找？ 未渲染项不存在于 DOM，需要额外语义、焦点和搜索实现。

八、加强记忆

用“总高占位、窗口渲染、偏移定位、超扫缓冲、动态修正”记住机制：固定高度靠除法直接定位，动态高度靠测量、前缀累计与二分查找，并用滚动锚定吸收高度变化；虚拟化只减 DOM 和渲染成本，网络、数据、SEO、查找与无障碍必须单独评估。

简化版

详细版