01

60 秒回答模板

列表优化要先定位瓶颈是接口慢、数据量大、DOM 节点多、列表项渲染重，还是频繁更新导致重渲染。常见方案是服务端分页或游标分页控制数据规模，前端用虚拟列表只渲染视口附近元素，列表项保持稳定 key 并拆成轻量组件，媒体和重资源懒加载，搜索输入做防抖，滚动和 resize 做节流。对频繁变化的数据，要控制响应式粒度和状态更新范围。最终要用 Performance、Profiler 或线上指标验证，而不是看到列表就直接上虚拟滚动。

考点 核心机制与工程取舍
难度 中高频面试题
回答目标 按定义、机制、场景讲清楚
02

深入解析

01

先定位瓶颈类型

接口慢要看网络和后端查询，数据过多要分页或裁剪，DOM 过多要虚拟列表，单项渲染重就拆组件和缓存计算，频繁更新要控制状态范围。不同瓶颈对应的解法不同。

02

控制数据规模

优先从源头减少一次性数据量，比如分页、游标加载、服务端筛选、只返回必要字段、接口缓存和增量更新。前端拿到几十万条后再优化渲染，通常已经错过了最有效的优化点。

03

虚拟列表的核心

虚拟列表通过总高度占位，只渲染可视区和少量缓冲区的列表项。固定高度实现简单，动态高度要维护高度缓存、偏移量和滚动修正。它适合超长列表，但会增加定位、键盘访问和 SEO 复杂度。

04

减少无效渲染

稳定 key 能帮助框架正确复用节点。列表项组件要避免在模板或 render 中做重计算，复杂派生值可以缓存。React 中可局部使用 memo，Vue 中要避免不必要的深层响应式和全量数组替换。

05

资源和交互优化

媒体资源用懒加载、占位尺寸和合适格式，避免滚动时布局跳动。搜索、过滤、排序等输入链路要防抖；滚动监听要节流或用 IntersectionObserver；批量 DOM 更新要合并到同一帧。

06

验证优化效果

优化前后要比较首屏时间、长任务、滚动帧率、内存占用和交互延迟。小列表上过度虚拟化可能让代码更复杂、可访问性更差，却没有明显收益。

03

易错点

  • 没定位瓶颈就直接说虚拟列表，忽略接口、数据规模和单项渲染成本。
  • 用数组 index 当 key，导致插入删除后组件状态或输入框内容错位。
  • 只优化渲染节点数，不处理媒体尺寸、懒加载和滚动监听带来的卡顿。
  • 优化后不看 Performance、Profiler、长任务和内存数据，无法证明收益。
04

面试官追问

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

它把 DOM 数量从全部数据量降到视口内元素加缓冲区，减少布局、绘制、事件绑定和框架 diff 成本。

动态高度虚拟列表难在哪里？

难在滚动偏移依赖历史高度。需要测量并缓存每项高度，未知高度要估算，实际高度变化后还要修正后续偏移，避免滚动跳动。

为什么稳定 key 很重要？

稳定 key 让框架识别同一业务项，减少错误复用和无效重建。用 index 做 key 在插入、删除、排序场景下可能导致状态错位。

什么情况下不该用虚拟列表？

数据量不大、需要完整页面搜索或 SEO、列表高度复杂且交互密集、可访问性要求高时，要先评估收益和复杂度。