虚拟列表专为解决长列表滚动卡顿而生，通过控制挂载DOM数量（20–100个）、用transform模拟滚动、固定容器高度及使用稳定key等手段优化性能。

虚拟列表和长列表不是“有没有关系”，而是“专为长列表而生”——它不是可选项，是当 DOM 节点超过 500 个、滚动开始卡顿时，你必须考虑的渲染层解法。

虚拟列表解决什么问题：DOM 数量失控导致的滚动卡顿

长列表本身只是数据量大；卡顿的根源是浏览器要持续创建、布局、绘制成千上万个 <li> 或 <div>。一旦 DOM 节点数突破 3000，多数中端设备就会掉帧。虚拟列表不减少数据，只控制实际挂载的 DOM 数量（通常稳定在 20–100 个），靠 transform: translateY() 模拟滚动位置，避免重排。

• 错误认知：“加个 IntersectionObserver 懒加载就叫虚拟列表”——它不删 DOM，只控制 visibility，DOM 总数仍在增长
• 关键约束：容器必须有固定高度（height 或 max-height），且不能设 overflow: visible
• 滚动事件监听必须用 passive: true，否则主线程被阻塞，反而更卡

为什么不能直接用 key={index} 渲染虚拟列表

看似省事，实则埋雷：索引变化时 React/Vue 无法复用组件实例，每次滚动都触发完整 re-render + 重新挂载 DOM，失去虚拟列表意义。真实场景中应使用唯一、稳定的数据标识，比如 item.id。

• 典型后果：快速滚动时出现闪烁、白屏、甚至内存泄漏（旧节点未卸载）
• React 中若用 react-window，itemKey 属性必须传函数返回稳定 key，不能直接写 key={index}
• Vue 中 v-for 的 :key 同理，禁止绑定数组下标

动态高度怎么处理：缓存比实时测量更可靠

固定高度最简单，但业务中常需支持图文混排、多行文本等变高场景。此时不能每滚一帧就调用 getBoundingClientRect()——开销太大，会拖垮帧率。

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

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

• 推荐做法：首次渲染后用 ResizeObserver 记录每项真实高度，存入 Map 缓存（new Map<string, number>）
• 滚动时通过二分查找快速定位可视区间起止索引，再查缓存算偏移量
• 慎用 itemSize 回退策略：若缓存缺失，用预估均值撑开占位，而非强制 reflow 测量

容易被忽略的 CSS 细节：contain 和 transform 层级

即使逻辑正确，样式没配对也会让虚拟列表失效或变慢。

• 容器必须设 contain: strict 或至少 contain: layout paint，告诉浏览器该区域独立布局，减少全局重排影响
• 列表项不能有 position: relative 或 z-index 打破 transform 层级，否则 translateY 失效，触发回流
• 占位元素（.virtual-list-placeholder）要用 position: absolute; top: 0; left: 0; right: 0;，且 z-index: -1 避免遮挡交互

真正难的不是实现一个能跑的虚拟列表，而是让它的 DOM 卸载干净、缓存命中率高、滚动不抖动、图片不重复加载——这些细节不在 API 文档里，而在每一次滚动卡顿的 performance 面板中。