问题背景

在去年的一场面试中，面试官向我提了一个问题：

面试官：后端一次性给你一千万条数据，渲染到页面上发生卡顿，你该怎么优化？

我：我会问候后端（bushi）

实际上我的回答是：如果没办法改变后端的情况下，我会避免给这种大数据量赋予响应式，然后手动 分页渲染。

面试官：不对哈，用Object.freeze来优化。

我：？？？

这段时间突然想起这个问题，决定试一下实际遇到这种情况到底该怎么优化。

测试环境搭建

前端实现（Vue3）

复制 1<template>
 2  <div>
 3    <div class="user-info" v-for="user in userList" :key="user.id">
 4      我是 {{ user.name }}
 5    </div>
 6  </div>
 7</template>
 8
 9<script setup lang="ts">
10import { ref } from 'vue'
11
12const tableData = ref([])
13
14const getData = async () => {
15  const res = await fetch('/api/mock')
16  const data = await res.json()
17  tableData.value = data
18}
19getData()
20</script>
21
22<style scoped>
23.user-info {
24  height: 30px;
25}
26</style>

后端实现（NestJS）

复制 1getMockData() {
 2  function generateMockData(amount) {
 3    const data: any = []
 4    for (let i = 0; i < amount; i++) {
 5      data.push({
 6        id: i,
 7        name: `User${i}`,
 8        timestamp: Date.now(),
 9        metadata: {}
10      })
11    }
12
13    return data
14  }
15
16  const mockData = generateMockData(1000000)
17  return mockData
18}

初始效果： ⏳页面渲染耗时 30S 左右。

方案一：Object.freeze

面试官推荐的方案实现：

复制 1const getData = async () => {
 2  const res = await fetch('/api/mock')
 3  const data = await res.json()
 4  userList.value = data.map((item: any) => Object.freeze(item))
 5}

测试效果：

• ⏳渲染时间：仍需要 30s 左右
• ✅优点：能够避免后续数据变更的响应式消耗
• ❌缺点：无法解决初始渲染性能瓶颈

方案二：分块渲染（requestAnimationFrame）

通过分批渲染避免 主线程阻塞 ：

复制 1<script setup lang="ts">
 2import { ref } from 'vue'
 3
 4const userList = ref<any[]>([])
 5
 6const CHUNK_SIZE = 1000
 7
 8const getData = async () => {
 9  const res = await fetch('/api/mock')
10  const data = await res.json()
11
12  function* chunkGenerator() {
13    let index = 0
14    while(index < data.length) {
15      yield data.slice(index, index + CHUNK_SIZE)
16      index += CHUNK_SIZE
17    }
18  }
19
20  const generator = chunkGenerator()
21  const processChunk = () => {
22    const chunk = generator.next()
23    if (!chunk.done) {
24      userList.value.push(...chunk.value)
25      requestAnimationFrame(processChunk)
26    }
27  }
28
29  requestAnimationFrame(processChunk)
30}
31getData()
32</script>

测试效果：

• ⏳首屏时间：< 1s
• ❌缺点：随着数据的增加，DOM节点持续增加，最终仍影响性能

方案三：虚拟列表（终极方案）

只渲染可视区域内容：

复制 1<template>
 2  <div class="viewport" ref="viewportRef" @scroll="handleScroll">
 3    <!-- 占位元素保持滚动条高度 -->
 4    <div class="scroll-holder" :style="{ height: totalHeight + 'px' }"></div>
 5    <!-- 可视区域 -->
 6    <div class="visible-area" :style="{ transform: `translateY(${offset}px)` }">
 7      <div class="user-info" v-for="user in visibleData" :key="user.id">
 8        我是 {{ user.name }}
 9      </div>
10    </div>
11  </div>
12</template>
13
14<script setup lang="ts">
15import { ref, computed, onMounted } from 'vue'
16
17const userList = ref<any[]>([])
18
19const getData = async () => {
20  const res = await fetch('/api/mock')
21  const data = await res.json()
22  userList.value = data
23}
24getData()
25
26const viewportRef = ref<HTMLElement>()
27const ITEM_HEIGHT = 30
28const visibleCount = ref(0)
29const startIndex = ref(0)
30const offset = ref(0)
31
32// 计算总高度
33const totalHeight = computed(() => userList.value.length * ITEM_HEIGHT)
34
35// 计算可见数据
36const visibleData = computed(() => {
37  return userList.value.slice(
38    startIndex.value,
39    Math.min(startIndex.value + visibleCount.value, userList.value.length)
40  )
41})
42
43// 初始化可视区域数量
44onMounted(() => {
45  visibleCount.value = Math.ceil((viewportRef.value?.clientHeight || 0) / ITEM_HEIGHT) + 2
46})
47
48// 滚动处理
49const handleScroll = () => {
50  if (!viewportRef.value) return
51  const scrollTop = viewportRef.value.scrollTop
52  startIndex.value = Math.floor(scrollTop / ITEM_HEIGHT)
53  offset.value = scrollTop - (scrollTop % ITEM_HEIGHT)
54}
55</script>
56
57<style scoped>
58.viewport {
59  height: 100vh; /* 根据实际需求调整高度 */
60  overflow-y: auto;
61  position: relative;
62}
63
64.scroll-holder {
65  position: absolute;
66  left: 0;
67  right: 0;
68  top: 0;
69}
70
71.visible-area {
72  position: absolute;
73  left: 0;
74  right: 0;
75}
76
77.user-info {
78  height: 30px;
79}
80</style>

测试效果：

• ⏳首屏时间：< 1s
• ✅优点：只渲染 可视区域 内的DOM，减少不必要的消耗
• ❌缺点：实现相对麻烦，实际情况可能需要动态计算元素高度

方案对比总结

方案	首屏时间	内存占用	滚动性能	实现复杂度
原始渲染	30s+	高	差	简单
Object.freeze	30s+	高	差	简单
分块渲染	<1s	持续增长	逐渐变差	中等
虚拟列表	<1s	低	流畅	较高

彩蛋：为什么我只测了100万条数据？

当我试图测试 一千万 条数据时：

1. 第一次报错： FATAL ERROR: JS堆内存不足 🤔
2. 第二次报错（调高内存上限后）： RangeError: 字符串长度超标 💥响应体过大了，超出了V8引擎的字符串长度限制🤣，如果要返回只能使用SSE了，但这就违背了问题的“一次性返回”。(Java的JVM引擎响应限制比较大，应该是可以返回的)

总结

1. 响应式优化 ≠ 渲染优化： Object.freeze 只能解决响应式开销，不能解决渲染瓶颈。
2. 分块渲染算是折中方案： 也并不适合大量的数据渲染，性能开销依旧很大。
3. 虚拟列表是最佳实践： 能够应对大数据量的渲染，且不影响性能。
4. 实际情况： 还是应该避免后端一次性返回大量的数据。测试用例中，本地返回百万条数据（还是简单的json结构）接口都需要响应 1.7s~3s 。如果后端只能返回全量数据，那只能考虑 虚拟列表 解决方案。