大列表性能优化 · 面试精讲 · 一

📘 本系列定位 ：面试突击 · 认知框架

🔧 如果需要完整代码、监控降级、Worker+虚拟滚动联动 ，请移步姊妹篇：

《大列表性能优化 · 工程实战》（四篇完整方案）

标题：别再只会说虚拟列表了，大列表真正的难点在哪里？

前言

以前在面候选人时，我几乎必问一个问题：

"如果一个列表有 10 万条数据 ，还要支持 全选、筛选、排序，你会怎么做？"

大部分同学的答案都很标准：

✅ 用 react-window
✅ 用 vue-virtual-scroller

听起来没错，对吧？

但我只要补一句：

"那 全选卡不卡？内存爆不爆？用户滚动的时候会不会白屏？"

这时候，空气突然安静了。

大列表 ≠ DOM 多

绝大多数人以为：

大列表慢，是因为 DOM 太多了。

所以用虚拟列表，只渲染可视区域的 DOM。

问题解决了吗？

并没有。

因为大列表的真正瓶颈，从来不在 DOM。

四个你一定会踩的坑

1️⃣ 内存爆炸

10 万条数据，每条数据哪怕只有 5 个字段：

js 复制代码

{
  id: 100000,
  name: 'xxx',
  age: 18,
  status: 1,
  remark: '...'
}

直接塞进内存，轻松吃掉 几百 MB 。

低端机直接 OOM。

2️⃣ 主线程阻塞

排序、筛选、搜索，全是 CPU 密集型操作。

js 复制代码

list.sort((a, b) => a.value - b.value)

一旦数据量大，主线程直接被锁死。

用户点个按钮，页面卡 2 秒。

3️⃣ 勾选状态失控

最经典的一道题：

"全选 10 万条，怎么做？"

很多人第一反应是：

js 复制代码

const selected = new Set()

看起来很优雅，对吧？

但你知道 10 万个布尔值，在 JS 里占多少内存吗？

几 MB 起跳，还不包括对象引用开销。

4️⃣ 滚动体验崩塌

虚拟列表解决了 DOM 数量，但解决不了：

滚动白屏
快速拖动卡顿
滚动后状态丢失

尤其是 筛选后再回到列表，用户心态直接炸裂。

优化的目标不是"快"，而是"稳"

很多同学追求极限性能，其实是不对的。

我们真正要的是：

指标	目标
滚动	60fps
内存	< 200MB
操作	即时反馈
极端	不崩

✅ 稳，才是工程能力。

面试官到底在看什么？

你以为面试官在考 API？

错了，他在看你属于哪一层。

层级	表现
初级	会说虚拟列表
中级	懂分片加载
高级	懂 Web Worker / 位图
架构	能从系统层面解决问题

小结

大列表从来不是：

"用个虚拟列表就行了。"

而是：

内存怎么控
计算怎么拆
状态怎么存
极端怎么退

它是前端工程能力的试金石。

下一篇预告

下一篇，我会带你从 工程角度 拆解一套 生产级的大列表优化方案：

✅ Web Worker 解放主线程
✅ IndexedDB 存冷数据
✅ BitSet 存勾选状态
✅ 虚拟滚动只干一件事

敬请期待 👋