👨面试官：后端一次性给你一千万条数据，你该如何优化渲染

#问题背景

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

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

我：我会问候后端（bushi）

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

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

我：？？？

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

#测试环境搭建

#前端实现（Vue3）

复制<template>
  <div>
    <div class="user-info" v-for="user in userList" :key="user.id">
      我是 {{ user.name }}
    </div>
  </div>
</template>

<script setup lang="ts">
import { ref } from 'vue'

const tableData = ref([])

const getData = async () => {
  const res = await fetch('/api/mock')
  const data = await res.json()
  tableData.value = data
}
getData()
</script>

<style scoped>
.user-info {
  height: 30px;
}
</style>

#后端实现（NestJS）

复制getMockData() {
  function generateMockData(amount) {
    const data: any = []
    for (let i = 0; i < amount; i++) {
      data.push({
        id: i,
        name: `User${i}`,
        timestamp: Date.now(),
        metadata: {}
      })
    }

    return data
  }

  const mockData = generateMockData(1000000)
  return mockData
}

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

#方案一：Object.freeze

面试官推荐的方案实现：

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

测试效果：

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

#方案二：分块渲染（requestAnimationFrame）

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

复制<script setup lang="ts">
import { ref } from 'vue'

const userList = ref<any[]>([])

const CHUNK_SIZE = 1000

const getData = async () => {
  const res = await fetch('/api/mock')
  const data = await res.json()

  function* chunkGenerator() {
    let index = 0
    while(index < data.length) {
      yield data.slice(index, index + CHUNK_SIZE)
      index += CHUNK_SIZE
    }
  }

  const generator = chunkGenerator()
  const processChunk = () => {
    const chunk = generator.next()
    if (!chunk.done) {
      userList.value.push(...chunk.value)
      requestAnimationFrame(processChunk)
    }
  }

  requestAnimationFrame(processChunk)
}
getData()
</script>

测试效果：

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

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

只渲染可视区域内容：

复制<template>
  <div class="viewport" ref="viewportRef" @scroll="handleScroll">
    <!-- 占位元素保持滚动条高度 -->
    <div class="scroll-holder" :style="{ height: totalHeight + 'px' }"></div>
    <!-- 可视区域 -->
    <div class="visible-area" :style="{ transform: `translateY(${offset}px)` }">
      <div class="user-info" v-for="user in visibleData" :key="user.id">
        我是 {{ user.name }}
      </div>
    </div>
  </div>
</template>

<script setup lang="ts">
import { ref, computed, onMounted } from 'vue'

const userList = ref<any[]>([])

const getData = async () => {
  const res = await fetch('/api/mock')
  const data = await res.json()
  userList.value = data
}
getData()

const viewportRef = ref<HTMLElement>()
const ITEM_HEIGHT = 30
const visibleCount = ref(0)
const startIndex = ref(0)
const offset = ref(0)

// 计算总高度
const totalHeight = computed(() => userList.value.length * ITEM_HEIGHT)

// 计算可见数据
const visibleData = computed(() => {
  return userList.value.slice(
    startIndex.value,
    Math.min(startIndex.value + visibleCount.value, userList.value.length)
  )
})

// 初始化可视区域数量
onMounted(() => {
  visibleCount.value = Math.ceil((viewportRef.value?.clientHeight || 0) / ITEM_HEIGHT) + 2
})

// 滚动处理
const handleScroll = () => {
  if (!viewportRef.value) return
  const scrollTop = viewportRef.value.scrollTop
  startIndex.value = Math.floor(scrollTop / ITEM_HEIGHT)
  offset.value = scrollTop - (scrollTop % ITEM_HEIGHT)
}
</script>

<style scoped>
.viewport {
  height: 100vh; /* 根据实际需求调整高度 */
  overflow-y: auto;
  position: relative;
}

.scroll-holder {
  position: absolute;
  left: 0;
  right: 0;
  top: 0;
}

.visible-area {
  position: absolute;
  left: 0;
  right: 0;
}

.user-info {
  height: 30px;
}
</style>

测试效果：

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

#方案对比总结

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

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

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

#总结

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