## 问题背景在去年的一场面试中，面试官向我提了一个问题：面试官：后端一次性给你一千万条数据，渲染到页面上发生卡顿，你该怎么优化？我：我会问候后端（bushi）实际上我的回答是：如果没办法改变后端的情况下，我会避免给这种大数据量赋予响应式，然后手动 **分页渲染**。面试官：不对哈，用`Object.freeze`来优化。我：？？？这段时间突然想起这个问题，决定试一下实际遇到这种情况到底该怎么优化。 ## 测试环境搭建 ### 前端实现（Vue3） ```vue ``` ### 后端实现（NestJS） ```typescript 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 面试官推荐的方案实现： ```typescript 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）通过分批渲染避免 **主线程阻塞** ： ```typescript ``` **测试效果：** * ⏳首屏时间：**< 1s** * ❌缺点：随着数据的增加，DOM节点持续增加，最终仍影响性能 ## 方案三：虚拟列表（终极方案）只渲染可视区域内容： ```vue ``` **测试效果：** * ⏳首屏时间：**< 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** 。如果后端只能返回全量数据，那只能考虑 **虚拟列表** 解决方案。