当你面对一个在 Vue 3 里滚动卡顿、更新掉帧的大数组页面时最直觉的做法是把列表替换成虚拟滚动组件。这个方案能解决视觉渲染压力却不一定能回答面试官的下一句追问如果数据源必须频繁整体替换比如每 3 秒刷新一次一万行表格虚拟滚动的渲染优化真的能抵消掉响应式系统内部不断累积的依赖追踪成本吗2026 年前端面试对 Vue 进阶能力的考察已经明显从“用对了哪些 API”转向“能不能说清底层机制”。一个候选人可以熟练编写 ref、computed、watch但不一定能解释清楚为什么一个大数组用 ref 包起来后访问其中任意行的一个字段可能把整条依赖链重新激活一遍也不一定能讲明白 Vue 3 的调度器如何把同一时间片内的多次更新合并成一次渲染。恰恰是这两块知识——响应式系统自身的结构复杂度以及更新任务在调度器里的执行顺序——决定了大数组优化的上限。本文的核心判断是真正值得掌握的 Vue 大数组优化不是绕开响应式而是把 Vue 的“自动依赖追踪”降级为“可控依赖追踪”并借助调度器的批处理机制减少无效渲染。我将从响应式分形架构、调度器抢占、shallowRef、triggerRef、v-memo 等方向逐层拆解同时给出一个可直接运行的 1 万行列表优化示例最后总结一套能用于面试回答和技术落地的排查路径。1. 为什么大数组在 Vue 中会“卡”先定位问题发生在哪个阶段很多开发者遇到大数组性能问题时第一反应是“DOM 太多了”。但实际上浏览器处理一万个普通 DOM 节点的代价并没有想象中那么不可接受真正的开销往往出现在 Vue 数据更新驱动视图重新渲染的完整链路里。这条链路大致可以分为三个阶段数据变更后的依赖通知、组件更新函数的重新执行、虚拟 DOM 的 diff 与真实 DOM 的 patch。第一个阶段最容易被忽略却恰恰是大数组场景中放大最严重的部分。假设你有一个包含一万个对象的数组每个对象有 10 个字段并且它们都被 ref 包裹成深层响应式数据。页面模板如果遍历了这些对象的多个字段Vue 在渲染函数执行时就会建立数以万计的依赖连接。后续一旦某一行数据发生了字段变化响应式系统需要去通知那些依赖该字段的组件。字段越多、对象越多、组件对模板字段的读取越分散这个通知网络就越庞大。第二个阶段是组件更新函数的重复执行。Vue 3 的组件级更新粒度比 Vue 2 更细它不像 Vue 2 那样每个数据字段绑定一个 Watcher而是由渲染函数创建组件副作用渲染函数。但组件内部仍然存在一个“最小更新单位”的概念如果你把整个大数组写在同一个组件模板里那么任何一行变化都会导致整个大循环组件重新执行渲染函数。第三个阶段则是 diff 和 patch。对于 1 万行列表Vue 需要先对比旧的虚拟节点树和新的虚拟节点树通过 key 找到对应节点再复用或新建真实 DOM。如果没有给 v-for 写 key或者在列表项内部绑定了很重的模板表达式这里的消耗会更加明显。所以回答“为什么卡”之前必须先分清卡顿发生在首次挂载、后续局部更新还是频繁全量替换。一次挂载一万行慢可能是渲染函数本身太重也可能是数据对象代理建立的初始成本。后续每 3 秒全量替换一次慢则大概率出在依赖通知和组件更新的重复执行上。本文讨论的重点是后者不是“能不能渲染一万行”而是“当一万行数据频繁变化时如何让 Vue 不把每一次变化都当成整张表重新开始”。2. 响应式分形架构Vue 依赖追踪为什么会随规模“分形”放大“响应式分形架构”并不是 Vue 官方文档里的术语而是对 Vue 3 深层响应式行为的一种形象概括但它能非常准确地解释大数组性能问题的根源。分形的特点是自相似整体结构和局部结构在形态上相似。Vue 3 中对嵌套数据的响应式处理就有这种特征——外层数组是响应式对象数组里的每个元素也是响应式对象元素里的子对象还是响应式对象。这里的设计基础是 Proxy。Vue 3 使用 Proxy 代替 Vue 2 的 Object.defineProperty 之后最大的优势之一是懒代理只有在你真正读取某个嵌套对象时Vue 才会对那个对象执行响应式转换。这避免了 Vue 2 初始化时就递归遍历所有嵌套属性的高额成本。但“懒代理”并不意味着大数组不需要付出代价。当一个组件模板在渲染时访问了数组的每一项以及每个对象的多个字段Vue 就必须为这些访问路径建立依赖关系。我们可以把一个数组里的每一项看作一棵微型的依赖树每一行对象有 id、name、status、score 等多个属性每个属性都对应一个 dep 依赖集合。一万个行对象叠加起来就是一万棵同类结构的依赖树。这就是分形放大的技术含义数据结构有多少层读取了多少层依赖追踪就会蔓延到多少层。表面上看你只是渲染了一个数组实际上 Vue 内存中建立的是一个与数据规模成正比、且按照属性字段进一步展开的依赖图。如果数据本身是嵌套的例如每行对象里还有一个日志列表访问路径更深依赖图也会更深。值得强调的是Vue 3 不是为每个属性都立即创建依赖收集器而是在数据被组件读取时才建立联系。这意味着如果一行数据只有前 3 个字段被模板使用后 7 个字段不会被这个组件追踪。这是很好的优化特性但它的前提是“模板读取范围必须足够收敛”。反过来如果模板里写了很多冗余表达式例如对整行数据做 JSON.stringify 然后展示依赖追踪就会被强制扩大到整行所有字段这正是把性能问题放大到不可控的常见写法。如果把“分形”这个词放到面试里去讲一个清晰的小结论是Vue 3 的深层响应式在处理中小型数据时非常优雅它的收集粒度能精确到字段但当数组规模达到上万行、字段几十个时组件渲染涉及的依赖连接数量会成倍膨胀这种“每个局部都自相似、每个层级都被追踪”的结构实际上就是响应式开销分形扩张的来源。对大数组优化而言方向因此变得明确要么减少被追踪的数据规模要么把深层响应式降级为浅层响应式要么把自动依赖收集变成更明确的“手动分发”。3. 从“数据变了立刻渲染”到调度器抢占Vue 3 是怎么收敛更新风暴的3.1 没有调度器的数据驱动世界假设 Vue 没有调度器每个响应式数据变化都会立刻触发它对应的组件更新函数。这是一个极端低效的设计一次事件处理函数里连续修改 10 个字段页面就要重渲染 10 次一次点击修改 100 个数据项页面就要重渲染 100 次。用户感知到的结果就是明显的卡顿和闪烁。Vue 3 引入了调度器scheduler的概念把所有更新任务收集到一个队列里并在合适的时机统一执行。这里的核心不是“减少必须要做的工作”而是“把任务排成一个更合理的执行批次”。理解这一点很重要因为调度器不能把一条数据修改凭空优化成不需要更新它优化的是重复、碎片化的多次更新。3.2 调度器抢占的语义队列里的任务合并与顶替在 Vue 3 调度器内部更新任务会以 Job 的形式入队。最容易让人混淆的是它和“抢优先级”的关系。熟悉 React 并发特性的开发者可能会把抢占理解成高优先级任务打断低优先级渲染但 Vue 3 调度器默认并不像 React 那样做时间切片和优先级抢占。Vue 3 调度器真正的优质特性是队列去重与批量合并。当一个组件已经有一个待执行的更新 Job 出现在队列中时后续触发的同组件更新不会再次创建新 Job而会把新的副作用状态合并到原有 Job 上。从宏观效果看后到达的更新“顶替”了队列中尚未执行的旧任务这就是大家在日常讨论中说的“调度器抢占”。举个例子更容易理解import { ref, nextTick } from vue const count ref(0) function handleClick() { count.value 1 // 第一次修改触发更新任务入队 count.value 1 // 第二次修改当前队列已有该组件任务合并 count.value 1 // 第三次修改仍然只保留一个待执行任务 console.log(同步代码执行完毕count , count.value) nextTick(() { console.log(微任务队列执行后DOM 已完成一次更新) }) }这段代码运行后组件并不会渲染三次而只会渲染一次。原因就在于三个连续的 ref 修改在同一个同步执行块内完成而 Vue 3 的默认更新是在微任务阶段刷新任务队列。同步代码执行完毕后任务队列里只有一个对应组件的更新 Job它会在当前执行栈清空后的微任务阶段被消费。3.3 pre、post、sync不同时机的 flush 选择Vue 3 调度器里还有一个高频考点就是 flush 时机。很多 API 都支持通过 flush 选项来定制副作用执行时机例如 watch 的 flush 选项分为 pre、post、sync 三种flush 时机行为典型场景pre在组件更新前执行数据变化后需要同步修改组件渲染所需的数据post在组件更新之后执行需要在 DOM 更新完成后读取新布局或触发第三方库sync数据变化时立即执行少数需要强制同步反馈的场景一般不推荐默认的 pre 会把 watch 回调放入同一个刷新任务队列在组件重新渲染前执行。post 则对应 Vue 3.3 之前版本从组件内部通过 onUpdated 钩子才能做到的效果后来很多 API 都补充了 post 支持。sync 因为放弃批处理优点通常在开发调试时才使用生产环境大规模使用时需要格外谨慎。nextTick 可以看作是调度器向使用者暴露的一个“队列清空完成”信号。面试官如果追问 nextTick 的原理可以答nextTick 本身不是去强制立即渲染而是把一个回调函数放到当前微任务刷新的后面确保回调执行时 Vue 已经完成了本轮组件更新。3.4 调度器对大数组优化的真正价值调度器和大数组优化到底有什么关系一个场景就能说明后端每 3 秒推来一万条新数据如果前端毫不在意地把这一万条数据逐条赋值给响应式数组理论上调度器可以帮你合并成一次组件更新从而避免一万次重复渲染。但要注意调度器应对的是“重复更新同一目标组件”的情况。它不能解决一万条数据全部变化后组件渲染函数本身需要重新计算一万行节点的问题。调度器负责把一万次敲击合并成一次钟声但钟声响起后的整个会场处理流程仍然需要你自己优化。因此在面试中讲完调度器机制后正确的落点是调度的批处理减少的是更新频率而不是单次更新成本。如果你的组件模板包含一万行列表且没有做任何渲染拆分那么一次更新仍然要跑一整轮大型 diff。调度器是优化链路上的第一道闸门不是终点。4. 环境准备与前置知识先搭一个可复现大数组问题的验证工程在展开优化策略之前需要先有一个能稳定复现大数组开销的实验环境。本文后面的示例基于 Vue 3 的 Script Setup 单文件组件写法不依赖复杂脚手架只用一个最小化的构建工程就能跑通。建议使用 Vite 创建一个 Vue 3 项目npm create vuelatest vue-large-array-demo如果不需要交互式选择可以用默认配置创建一个最小工程。进入项目目录后安装依赖并启动开发服务cd vue-large-array-demo npm install npm run dev这里要注意Node.js 版本需要满足 Vite 的基本要求一般建议使用 Node.js 18 及以上。如果本地没有对应的 Vue 3 工程经验也可以直接使用一个带 vue 编译器的在线代码沙箱但最好还是本地跑一遍方便后续通过 Performance 面板做性能观测。本文示例不依赖任何第三方状态管理库也不需要虚拟滚动插件。重点展示的是 Vue 3 响应式系统原生的 API 组合因此先确认工程里能正常导入 ref、shallowRef、triggerRef、nextTick、onUpdated、v-memo 等相关能力。v-memo 是 Vue 3.2 之后内置的指令如果你的项目版本过旧需要先升级到较新的 Vue 3 版本。需要特别说明不同 Vue 版本之间部分 API 的具体性能表现和源码实现细节会有变化但响应的核心机制在 Vue 3 大版本内保持稳定。下文给出的代码思路适用于 Vue 3 全系列不会指定某个精确小版本以避免版本差异带来的误导。5. 三层优化策略从数据层到渲染层逐步收敛大数组优化最好的做法是分层处理而不是一上来就上虚拟滚动。按照改动代价由小到大、风险由低到高我通常把优化分成数据层、响应式层和渲染层三步。5.1 数据层扁平化、裁剪获取范围和避免深拷贝数据层优化的核心是“让 Vue 不需要追踪那么多东西”。最直接的问题是后端接口是否真的需要一次返回一万条完整数据很多管理系统表格卡顿并不是 Vue 的问题而是接口返回了过多无关字段或者前端在拿到数据后做了深拷贝、字段清洗等额外工作。一个容易被忽略的性能陷阱是 JSON.stringify。有人为了比较两个对象的内容是否变化会在模板里直接写 JSON.stringify(item) JSON.stringify(prevItem)或者在 watch 回调里用 JSON.stringify 对 1 万条数据做快照比较。字符串化一万个对象会产生大量瞬时内存而且一旦 JSON.stringify 出现在渲染函数执行路径上它本身就会成为新的性能瓶颈。数据层正确做法包括后端接口支持分页或只返回表格需要展示的列前端过滤掉不被模板使用的字段列表数据保持扁平结构避免每行内嵌几十个深层对象在数据写入响应式容器之前把不需要响应式的静态字段用普通对象保存即可。5.2 响应式层用 shallowRef 和 triggerRef 控制依赖追踪边界当数据无法再继续裁剪、确实需要上万条对象同时呈现在前端列表时第二层优化就是响应式层。核心手段是把默认的“深层响应式数组”降级成“浅层响应式数组”。普通 ref 包裹一个数组时数组本身是响应式的数组中的每个对象也都会被递归转换成响应式代理。这个过程建立了一个庞大的“监控网络”。shallowRef 则仅仅把 .value 这一层变成响应式对象数组内部保持原生 JavaScript 对象不建立深层代理。这样做的一个明显代价是直接修改数组内部某个对象的属性时Vue 无法感知视图不会自动更新。为了让视图依然能够按需刷新需要显式调用 triggerRef。这是一种非常值得在面试中讨论的设计思想当自动依赖追踪的代价高于收益时就把自动收集改成手动发送信号。下面用一个小例子展示 shallowRef 和 triggerRef 的关系import { shallowRef, triggerRef, nextTick } from vue const rows shallowRef([]) function appendRow(row) { // rows.value 拿到的仍然是普通数组没有深层代理 rows.value.push(row) // 手动通知外界rows.value 已经发生变化 triggerRef(rows) } function updateRowById(id, patch) { const list rows.value const row list.find(item item.id id) if (row) { Object.assign(row, patch) // 由于 row 不是深层代理必须手动触发 triggerRef(rows) } }上面代码中rows 内部存储的是最普通的数组和普通对象。appendRow 和 updateRowById 在完成数组变更后调用 triggerRef 通知所有依赖 rows.value 的副作用执行。但这里有一个必须避免的坑如果业务代码非常分散到处直接调用 triggerRef每一次触发仍然可能造成不必要的更新。更好的方式是结合调度器把多次 triggerRef 收敛到一个微任务周期内执行。import { shallowRef, triggerRef, nextTick } from vue const rows shallowRef([]) let dirty false function markDirty() { if (dirty) return dirty true nextTick(() { dirty false triggerRef(rows) }) } function batchUpdate(updater) { updater(rows.value) markDirty() } function pushRow(row) { batchUpdate((list) { list.push(row) }) } function updateRows(newRows) { batchUpdate((list) { list.length 0 list.push(...newRows) }) }这种手动标记、延迟触发的模式把对数据的多次操作压缩到一次视图刷新本质上就是“数据层自己在调度器前面搭了一道小闸门”。由于 rows.value 内部不再是深层代理每次新增一万条普通对象时Vue 不需要递归代理一万个对象从而显著减少初始化时的 CPU 和内存开销。面试时可以总结为shallowRef 把响应式系统从“随数据规模自动扩张的深层代理”改成了“只有外界显式通知时才触发的可控信号源”。5.3 渲染层组件拆分、v-memo 和按需更新响应式层的优化能减少依赖追踪成本和数据初始化成本但组件模板中每次渲染 1 万行列表时仍然需要执行一次大型虚拟 DOM diff。渲染层的目标是在保持列表结构与样式的前提下降低 diff 的规模或跳过不需要更新的子树。第一个有效手段是列表项组件化。如果 1 万行都写在一个组件模板中的 v-for 里Vue 的 diff 范围就是这个大组件的全部子节点。如果把每一行抽取成独立的子组件例如 RowItem.vue并且给每一行传入稳定的 props那么当某一行数据变化时理论上只有该行的 RowItem 需要重新渲染其他行对应的组件可以复用上次的渲染结果。第二个手段是 v-memo。v-memo 接收一个依赖数组只有当数组内的值发生变更时当前模板片段才会被重新渲染。和 v-for 配合时v-memo 可以精细控制行级更新的条件template div v-foritem in rows :keyitem.id v-memo[item.id, item.status, item.score] {{ item.name }} - {{ item.status }} - {{ item.score }} /div /template这段代码表示只有当 item.id、item.status、item.score 三者中任一值改变时这一行才会被重新渲染。如果列表更新只是增加了几行数据而旧行的这三个字段保持不变旧行节点会被命中缓存不会重复执行模板更新逻辑。v-memo 的价值在于把更新单位从“整个 v-for 列表”细化为“按模板依赖字段判断的单行”。它和组件拆分的思路不同组件拆分是按组件边界隔离v-memo 是按内存依赖数组命中缓存。两者可以组合使用也可以按项目复杂度择优。但 v-memo 也有风险。它要求你列表项模板中读取的字段必须尽量完整地出现在 memo 数组中否则当某个字段变化但未包含在 v-memo 数组里时视图可能不会更新造成“页面看起来没变化”的过期数据问题。实际项目中如果列表行模板字段较多、更新逻辑复杂优先选择组件拆分必要时再用 v-memo 做局部兜底。第三层手段才轮到虚拟滚动。虚拟滚动解决的问题是“同时展示大量 DOM 节点导致浏览器的渲染和内存压力过大”它通过只渲染视口内的行从根本上减少 DOM 数量。它的缺点是滚动条模拟、列表项高度可变、键盘导航和辅助功能支持等都需要额外处理。因此一个清晰的结论是虚拟滚动适合数据量极大且行高较规律的场景但它不能替代响应式层和渲染层的优化。如果 1 万行数据中每一行都频繁变化虚拟滚动也无法避免那一万行状态计算的消耗。6. 完整示例将一万行全量响应式列表改造成可控响应式列表下面用一个接近真实业务的场景把优化串起来。假设有一个运行监控面板需要展示最近一小时内的任务列表。每个任务有 id、name、status、progress、score 等字段。后端每 3 秒推送一次最近 1 万条任务的最新状态用户还可能会对某一行的任务执行重启操作重启后这一行的状态发生局部变化。6.1 未优化版本全量 ref 加整表替换先看一个性能不太理想但最容易写出来的版本!-- src/components/MonitorListBad.vue -- script setup import { ref, onMounted, onUnmounted } from vue const rows ref([]) let timer null function fetchData() { return Array.from({ length: 10000 }, (_, index) ({ id: index 1, name: 任务-${index 1}, status: index % 4 0 ? running : idle, progress: Math.floor(Math.random() * 100), score: Math.floor(Math.random() * 10000), })) } function flushData() { // 全量替换数组会触发 ref 的深层代理与列表重渲染 rows.value fetchData() } function restartTask(id) { const row rows.value.find(item item.id id) if (row) { row.status running row.progress 0 } } onMounted(() { flushData() timer setInterval(flushData, 3000) }) onUnmounted(() { clearInterval(timer) }) /script template ul li v-foritem in rows :keyitem.id {{ item.name }} - {{ item.status }} - {{ item.progress }} - {{ item.score }} /li /ul /template这段代码的主要问题在于rows 是深层响应式 reffetchData 赋值一万个对象时Vue 需要递归转换一万个对象及其所有属性。每 3 秒整表替换整个 MonitorListBad 组件重新执行渲染函数并重跑一万行的 diff。restartTask 修改的是 row.status由于 row 是深层代理确实能触发视图更新但这种细节更新会和每 3 秒的全量替换混在一起不容易做局部控制。6.2 优化版本shallowRef triggerRef 行级组件改造后的数据结构使用 shallowRef第一层列表变化仍然可被通知但内部每一行只是普通对象不再被递归代理。为了控制触发时机加入 dirty 标记与 nextTick 批量刷新。同时把每一行拆成独立组件 MonitorRow.vue让单个任务行的状态更新只影响自己。先看数据容器部分!-- src/components/MonitorListGood.vue -- script setup import { shallowRef, triggerRef, nextTick, onMounted, onUnmounted } from vue import MonitorRow from ./MonitorRow.vue const rows shallowRef([]) let dirty false let timer null function markDirty() { if (dirty) return dirty true nextTick(() { dirty false triggerRef(rows) }) } function flushData() { const nextList Array.from({ length: 10000 }, (_, index) ({ id: index 1, name: 任务-${index 1}, status: index % 4 0 ? running : idle, progress: Math.floor(Math.random() * 100), score: Math.floor(Math.random() * 10000), })) // 直接替换 rows.value 内部数组内容保持 rows 本身同一引用 // 然后在下一个微任务统一触发一次更新。 rows.value.splice(0, rows.value.length, ...nextList) markDirty() } function restartTask(id) { const list rows.value const row list.find(item item.id id) if (row) { row.status running row.progress 0 } markDirty() } onMounted(() { flushData() timer setInterval(flushData, 3000) }) onUnmounted(() { clearInterval(timer) }) /script template ul MonitorRow v-foritem in rows :keyitem.id :rowitem restartrestartTask(item.id) / /ul /template对应的行组件!-- src/components/MonitorRow.vue -- script setup defineProps({ row: { type: Object, required: true } }) defineEmits([restart]) /script template li span{{ row.name }}/span span{{ row.status }}/span span{{ row.progress }}/span span{{ row.score }}/span button click$emit(restart)重启/button /li /template这里需要重点解释几个设计选择。第一为什么用 splice 而不是 rows.value nextList因为 shallowRef 只对 .value 的引用替换敏感如果改成 rows.value nextList会直接触发一次更新然后再手动 triggerRef 就会触发两次。用 splice 修改原数组内部的普通对象数组不会触发 shallowRef 的自动更新全部更新时机都交给我们自己的 markDirty 控制触发次数最可控。第二MonitorRow 组件接收的 row 是普通对象组件内部模板读取 row.name、row.status 等字段时不会在 MonitorRow 内部建立对深层响应式数据的依赖因此这行组件本身也不会因为字段变化而自动重渲染。那实际更新靠什么触发答案仍然是父组件的 triggerRef。triggerRef(rows) 会让所有依赖 rows.value 的组件副作用重新执行。在模板中父组件 MonitorListGood 依赖 rows.value因此父组件会重新执行渲染函数而每一行 MonitorRow 因为是子组件父组件重新渲染时会向 MonitorRow 传递新的 row 对象。由于每一行都通过 key 对标MonitorRow 的 props 是普通对象引用除非 row 对象被替换否则子组件不会因为 props 变化而被迫立刻重渲染。但当 restartTask 修改了同一个 row 对象的字段之后触发了父组件的 triggerRef实际上 Vue 仍需要走一轮父组件的 diff才能判断哪些子组件真正变化。在 1 万行数据整体替换的 3 秒周期里splice 把 old rows 替换成 nextList 后list 中的每个元素都是新对象。父组件 diff 时根据 key 找到对应 MonitorRow发现传入的 row 对象引用全部变化就会更新所有子组件。这是不可避免的因为后端推送的 1 万条数据本身就是新的状态快照。但如果需求只是“某一行重启”restartTask 修改的 row 对象仍然是旧对象父组件 triggerRef 后进入更新MonitorRow 的 key 相同、props.row 引用也没有变化此时 MonitorRow 是否更新取决于 Vue 对 props 的响应式追踪。因为 MonitorRow 模板读取了 row.status、row.progress而 row 是普通对象不等于响应式代理所以子组件这时不会追踪到字段变化也不会因字段变化自动重渲染。这一块如果想做到局部性能极致需要结合 v-memo 或者在行组件中包装 props 的监听属于更细粒度的控制这里先不展开。由此看出shallowRef triggerRef 模式下使用者的手动控制能力增强了但代价是“自动精确到字段的更新策略”需要自己维护。这是面试和工程实践中最需要想清楚的设计权衡。6.3 更进一步v-memo 在列表中的兜底效果如果不想把行级组件拆得太细也可以用 v-memo 来跳过未变化行的重渲染。在整表替换 newRows 的场景中如果新旧行只有 id 相同但内容全都变化了v-memo 命中不了缓存仍然要全部更新如果后端推送只是局部行的微调v-memo 帮助就很大。使用 v-memo 时依赖数组需要覆盖模板中所有会被动态读取的字段template ul li v-foritem in rows :keyitem.id v-memo[item.id, item.name, item.status, item.progress, item.score] classtask-row span{{ item.name }}/span span{{ item.status }}/span span{{ item.progress }}/span button clickrestartTask(item.id)重启/button /li /ul /templatev-memo 数组中每一项必须是一个“稳定且可比较”的值。如果把 item 本身放在数组里由于新数据的对象引用总是和旧对象不同v-memo 也就失去了跳过更新的意义。只有把字段值拆出来比较才有可能命中缓存。实际项目如果同时使用组件拆分和 v-memo要警惕重复优化导致的复杂度过高。一个常见的选择是当行内模板简单时优先 v-memo当行内交互复杂、内部有子组件状态时优先行级组件拆分。7. 验证优化效果如何科学评估大数组是否真的变快优化不是“感觉流畅了”就算完成。推荐通过浏览器 DevTools 做三个层面的验证。第一是 Vue Devtools 的性能时间线。打开 Vue Devtools 的 Performance 标签录制一次 3 秒推送周期观察 Components 列表中组件更新耗时。未优化版本里MonitorListBad 组件单次更新可能耗时几十毫秒甚至更多优化版本中如果后端是整表替换总耗时不会消失但数据初始化和代理创建成本会下降调度器触发的重复更新次数会明显减少。第二是浏览器 Performance 面板。在 Performance 录制中点击页面上的“重启”按钮或等待定时推送观察紫色 Reactivity 相关任务和灰色 Scripting 任务的时长。重点看是否存在“同一时间内连续多次组件更新”的 Evidence 分布。如果每次数据变更都导致大量连续的重渲染记录说明调度器没有很好地把任务合并到同一微任务周期。第三是 Console 里的手动测量给关键流程打点const start performance.now() flushData() nextTick(() { const cost performance.now() - start console.log(本次列表刷新耗时, cost) })这样测到的耗时包含了数据生成、splice 修改、调度器队列刷新和 DOM 提交近似等于用户能感知的一次完整更新周期。多次采样后取中位数或平均值再对比未优化版本的同类指标。注意不要在定时任务执行逻辑前后混入 console.log 的大量字符串拼接否则也会影响结果。判断是否成功的标准不是“跑分最低”而是更新过程中主线程长任务数量是否明显减少。快速连续多次修改数组时渲染次数是否被收敛为一次。页面滚动和操作时是否仍然保持稳定帧率。如果发现优化后反而出现某些行不更新的问题优先检查触发链路是否完整shallowRef 包裹的数据在字段变更后有没有调用 triggerRefv-memo 的依赖数组是否覆盖了模板动态读取的字段子组件拆分后父组件的传递 props 是否有意避开了响应式代理。8. 常见问题与排查思路问题现象可能原因排查方式解决方案使用 shallowRef 后修改行内字段页面不更新深层字段变更不会自动触发 shallowRef检查是否存在 triggerRef 调用在批量操作后调用 triggerRef或用 nextTick 合并触发连续两次 triggerRef 导致组件重复渲染每次 triggerRef 都会创建新的更新任务在同步代码中打印 triggerRef 调用次数引入 dirty 标记把多次手动触发合并到微任务v-memo 行内容显示陈旧v-memo 依赖数组没有包含模板中所有动态字段对比模板字段与 memo 数组字段把模板中读取的动态字段放入 memo 数组整表替换后所有行仍全部更新新对象引用与旧对象引用不同key 相同时 props 也不同查看 key 和 row 对象引用是否变化如果只是局部字段更新改为只更新变化行如果确实是全量快照属于合理开销数据量大时首次渲染很慢深层 ref 创建了数万个对象的代理在性能面板查看脚本初始化耗时改用 shallowRef或对静态字段使用 markRaw或减少首屏渲染行数使用 JSON.stringify 对比旧数据后卡顿明显JSON.stringify 对 1 万条对象做字符串化产生大量临时内存在代码中搜索 stringify 是否出现在渲染 / 监听路径上改用字段级比较、脏标记或 unique revision 计数虚拟滚动滚动条跳动、位置不稳定行高不一致或数据更新后容器高度变化检查每行实际渲染高度固定行高或在数据刷新时保持滚动位置这里要特别强调一个坑markRaw 的使用。如果数据对象中有一部分纯展示或静态配置可以在业务层做一个普通对象副本用 markRaw 标记避免 Vue 再做响应式代理。但不要把整个大数组直接放进 markRaw因为那样数组变化时 Vue 完全无法感知你会失去响应式更新能力。markRaw 适合“某一条数据中的图片静态 URL、主题配置、不需要更新的格式化函数”这类只有局部不需要代理的场景。9. 面试怎么答能出彩从响应式架构到调度器的回答路径如果你准备 2026 年前端面试当面试官抛出“Vue 里一万条数据更新为什么卡顿你怎么优化”时最好的回答不是背出几个 API 名称而是先用十秒把问题拆出层次。建议的回答路径如下第一步指出卡顿需要分阶段定位。大数组卡的三个阶段分别是数据初始化与代理创建、依赖通知与组件更新触发、虚拟 DOM diff 和 DOM patch。不同阶段的卡顿特征不同不应该混在一起讨论。第二步解释响应式分形结构。Vue 3 的深层响应式会对嵌套对象递归建立代理读取多少层依赖追踪就扩张多少层。数组大、字段多、模板读取面广都会让响应式依赖图成倍放大。这是大数组优化的底层瓶颈。第三步讲调度器的作用。Vue 3 调度器用任务队列收集更新 Job在微任务阶段统一 flush同一组件的多次任务会被合并也可以说后到达的更新“抢占”了尚未执行的渲染机会。调度器优化的是更新频率不优化单次更新成本。第四步讲优化方案。如果数据必须全量展示先裁剪字段然后用 shallowRef 降低代理成本用 nextTick 合并 triggerRef把自动依赖变成可控触发。渲染层按行拆分组件或使用 v-memo必要时再叠加虚拟滚动。每条方案都要说明它优化的是哪一段链路。第五步摆出风险。shallowRef 会失去深层自动更新能力v-memo 用错字段会造成过期数据虚拟滚动有滚动保真问题。工程里需要按数据特征选择二维组合而不是照搬模板。这套回答能在面试官面前展示出你对 Vue 的理解已经从 API 层深入到了机制层。后续如果想继续深入可以按推荐顺序阅读 Vue 源码中的 reactivity 模块和 runtime-core scheduler 部分也可以对比 React 调度器理解“时间切片”与“任务队列去重”的差异。如果面试官进一步追问 Vue 官方新版本在响应式方面的体验优化动作那时候你已经有了本文语境里的基础框架再去查证新版本 release notes会容易得多。把大数组优化当成一道知识串联题来准备比零散背十个技巧更有价值。它把响应式系统的实现思路、调度器行为、组件更新粒度、列表渲染策略和真实性能验证方法都串在一条主线里。等你真正掌握这条主线再遇到类似表格、长列表、实时数据面板的性能问题就不会轻易被“换一个虚拟滚动组件”这种表面解法带偏。
Vue 3大数组性能优化：响应式依赖与调度器机制深度拆解
当你面对一个在 Vue 3 里滚动卡顿、更新掉帧的大数组页面时最直觉的做法是把列表替换成虚拟滚动组件。这个方案能解决视觉渲染压力却不一定能回答面试官的下一句追问如果数据源必须频繁整体替换比如每 3 秒刷新一次一万行表格虚拟滚动的渲染优化真的能抵消掉响应式系统内部不断累积的依赖追踪成本吗2026 年前端面试对 Vue 进阶能力的考察已经明显从“用对了哪些 API”转向“能不能说清底层机制”。一个候选人可以熟练编写 ref、computed、watch但不一定能解释清楚为什么一个大数组用 ref 包起来后访问其中任意行的一个字段可能把整条依赖链重新激活一遍也不一定能讲明白 Vue 3 的调度器如何把同一时间片内的多次更新合并成一次渲染。恰恰是这两块知识——响应式系统自身的结构复杂度以及更新任务在调度器里的执行顺序——决定了大数组优化的上限。本文的核心判断是真正值得掌握的 Vue 大数组优化不是绕开响应式而是把 Vue 的“自动依赖追踪”降级为“可控依赖追踪”并借助调度器的批处理机制减少无效渲染。我将从响应式分形架构、调度器抢占、shallowRef、triggerRef、v-memo 等方向逐层拆解同时给出一个可直接运行的 1 万行列表优化示例最后总结一套能用于面试回答和技术落地的排查路径。1. 为什么大数组在 Vue 中会“卡”先定位问题发生在哪个阶段很多开发者遇到大数组性能问题时第一反应是“DOM 太多了”。但实际上浏览器处理一万个普通 DOM 节点的代价并没有想象中那么不可接受真正的开销往往出现在 Vue 数据更新驱动视图重新渲染的完整链路里。这条链路大致可以分为三个阶段数据变更后的依赖通知、组件更新函数的重新执行、虚拟 DOM 的 diff 与真实 DOM 的 patch。第一个阶段最容易被忽略却恰恰是大数组场景中放大最严重的部分。假设你有一个包含一万个对象的数组每个对象有 10 个字段并且它们都被 ref 包裹成深层响应式数据。页面模板如果遍历了这些对象的多个字段Vue 在渲染函数执行时就会建立数以万计的依赖连接。后续一旦某一行数据发生了字段变化响应式系统需要去通知那些依赖该字段的组件。字段越多、对象越多、组件对模板字段的读取越分散这个通知网络就越庞大。第二个阶段是组件更新函数的重复执行。Vue 3 的组件级更新粒度比 Vue 2 更细它不像 Vue 2 那样每个数据字段绑定一个 Watcher而是由渲染函数创建组件副作用渲染函数。但组件内部仍然存在一个“最小更新单位”的概念如果你把整个大数组写在同一个组件模板里那么任何一行变化都会导致整个大循环组件重新执行渲染函数。第三个阶段则是 diff 和 patch。对于 1 万行列表Vue 需要先对比旧的虚拟节点树和新的虚拟节点树通过 key 找到对应节点再复用或新建真实 DOM。如果没有给 v-for 写 key或者在列表项内部绑定了很重的模板表达式这里的消耗会更加明显。所以回答“为什么卡”之前必须先分清卡顿发生在首次挂载、后续局部更新还是频繁全量替换。一次挂载一万行慢可能是渲染函数本身太重也可能是数据对象代理建立的初始成本。后续每 3 秒全量替换一次慢则大概率出在依赖通知和组件更新的重复执行上。本文讨论的重点是后者不是“能不能渲染一万行”而是“当一万行数据频繁变化时如何让 Vue 不把每一次变化都当成整张表重新开始”。2. 响应式分形架构Vue 依赖追踪为什么会随规模“分形”放大“响应式分形架构”并不是 Vue 官方文档里的术语而是对 Vue 3 深层响应式行为的一种形象概括但它能非常准确地解释大数组性能问题的根源。分形的特点是自相似整体结构和局部结构在形态上相似。Vue 3 中对嵌套数据的响应式处理就有这种特征——外层数组是响应式对象数组里的每个元素也是响应式对象元素里的子对象还是响应式对象。这里的设计基础是 Proxy。Vue 3 使用 Proxy 代替 Vue 2 的 Object.defineProperty 之后最大的优势之一是懒代理只有在你真正读取某个嵌套对象时Vue 才会对那个对象执行响应式转换。这避免了 Vue 2 初始化时就递归遍历所有嵌套属性的高额成本。但“懒代理”并不意味着大数组不需要付出代价。当一个组件模板在渲染时访问了数组的每一项以及每个对象的多个字段Vue 就必须为这些访问路径建立依赖关系。我们可以把一个数组里的每一项看作一棵微型的依赖树每一行对象有 id、name、status、score 等多个属性每个属性都对应一个 dep 依赖集合。一万个行对象叠加起来就是一万棵同类结构的依赖树。这就是分形放大的技术含义数据结构有多少层读取了多少层依赖追踪就会蔓延到多少层。表面上看你只是渲染了一个数组实际上 Vue 内存中建立的是一个与数据规模成正比、且按照属性字段进一步展开的依赖图。如果数据本身是嵌套的例如每行对象里还有一个日志列表访问路径更深依赖图也会更深。值得强调的是Vue 3 不是为每个属性都立即创建依赖收集器而是在数据被组件读取时才建立联系。这意味着如果一行数据只有前 3 个字段被模板使用后 7 个字段不会被这个组件追踪。这是很好的优化特性但它的前提是“模板读取范围必须足够收敛”。反过来如果模板里写了很多冗余表达式例如对整行数据做 JSON.stringify 然后展示依赖追踪就会被强制扩大到整行所有字段这正是把性能问题放大到不可控的常见写法。如果把“分形”这个词放到面试里去讲一个清晰的小结论是Vue 3 的深层响应式在处理中小型数据时非常优雅它的收集粒度能精确到字段但当数组规模达到上万行、字段几十个时组件渲染涉及的依赖连接数量会成倍膨胀这种“每个局部都自相似、每个层级都被追踪”的结构实际上就是响应式开销分形扩张的来源。对大数组优化而言方向因此变得明确要么减少被追踪的数据规模要么把深层响应式降级为浅层响应式要么把自动依赖收集变成更明确的“手动分发”。3. 从“数据变了立刻渲染”到调度器抢占Vue 3 是怎么收敛更新风暴的3.1 没有调度器的数据驱动世界假设 Vue 没有调度器每个响应式数据变化都会立刻触发它对应的组件更新函数。这是一个极端低效的设计一次事件处理函数里连续修改 10 个字段页面就要重渲染 10 次一次点击修改 100 个数据项页面就要重渲染 100 次。用户感知到的结果就是明显的卡顿和闪烁。Vue 3 引入了调度器scheduler的概念把所有更新任务收集到一个队列里并在合适的时机统一执行。这里的核心不是“减少必须要做的工作”而是“把任务排成一个更合理的执行批次”。理解这一点很重要因为调度器不能把一条数据修改凭空优化成不需要更新它优化的是重复、碎片化的多次更新。3.2 调度器抢占的语义队列里的任务合并与顶替在 Vue 3 调度器内部更新任务会以 Job 的形式入队。最容易让人混淆的是它和“抢优先级”的关系。熟悉 React 并发特性的开发者可能会把抢占理解成高优先级任务打断低优先级渲染但 Vue 3 调度器默认并不像 React 那样做时间切片和优先级抢占。Vue 3 调度器真正的优质特性是队列去重与批量合并。当一个组件已经有一个待执行的更新 Job 出现在队列中时后续触发的同组件更新不会再次创建新 Job而会把新的副作用状态合并到原有 Job 上。从宏观效果看后到达的更新“顶替”了队列中尚未执行的旧任务这就是大家在日常讨论中说的“调度器抢占”。举个例子更容易理解import { ref, nextTick } from vue const count ref(0) function handleClick() { count.value 1 // 第一次修改触发更新任务入队 count.value 1 // 第二次修改当前队列已有该组件任务合并 count.value 1 // 第三次修改仍然只保留一个待执行任务 console.log(同步代码执行完毕count , count.value) nextTick(() { console.log(微任务队列执行后DOM 已完成一次更新) }) }这段代码运行后组件并不会渲染三次而只会渲染一次。原因就在于三个连续的 ref 修改在同一个同步执行块内完成而 Vue 3 的默认更新是在微任务阶段刷新任务队列。同步代码执行完毕后任务队列里只有一个对应组件的更新 Job它会在当前执行栈清空后的微任务阶段被消费。3.3 pre、post、sync不同时机的 flush 选择Vue 3 调度器里还有一个高频考点就是 flush 时机。很多 API 都支持通过 flush 选项来定制副作用执行时机例如 watch 的 flush 选项分为 pre、post、sync 三种flush 时机行为典型场景pre在组件更新前执行数据变化后需要同步修改组件渲染所需的数据post在组件更新之后执行需要在 DOM 更新完成后读取新布局或触发第三方库sync数据变化时立即执行少数需要强制同步反馈的场景一般不推荐默认的 pre 会把 watch 回调放入同一个刷新任务队列在组件重新渲染前执行。post 则对应 Vue 3.3 之前版本从组件内部通过 onUpdated 钩子才能做到的效果后来很多 API 都补充了 post 支持。sync 因为放弃批处理优点通常在开发调试时才使用生产环境大规模使用时需要格外谨慎。nextTick 可以看作是调度器向使用者暴露的一个“队列清空完成”信号。面试官如果追问 nextTick 的原理可以答nextTick 本身不是去强制立即渲染而是把一个回调函数放到当前微任务刷新的后面确保回调执行时 Vue 已经完成了本轮组件更新。3.4 调度器对大数组优化的真正价值调度器和大数组优化到底有什么关系一个场景就能说明后端每 3 秒推来一万条新数据如果前端毫不在意地把这一万条数据逐条赋值给响应式数组理论上调度器可以帮你合并成一次组件更新从而避免一万次重复渲染。但要注意调度器应对的是“重复更新同一目标组件”的情况。它不能解决一万条数据全部变化后组件渲染函数本身需要重新计算一万行节点的问题。调度器负责把一万次敲击合并成一次钟声但钟声响起后的整个会场处理流程仍然需要你自己优化。因此在面试中讲完调度器机制后正确的落点是调度的批处理减少的是更新频率而不是单次更新成本。如果你的组件模板包含一万行列表且没有做任何渲染拆分那么一次更新仍然要跑一整轮大型 diff。调度器是优化链路上的第一道闸门不是终点。4. 环境准备与前置知识先搭一个可复现大数组问题的验证工程在展开优化策略之前需要先有一个能稳定复现大数组开销的实验环境。本文后面的示例基于 Vue 3 的 Script Setup 单文件组件写法不依赖复杂脚手架只用一个最小化的构建工程就能跑通。建议使用 Vite 创建一个 Vue 3 项目npm create vuelatest vue-large-array-demo如果不需要交互式选择可以用默认配置创建一个最小工程。进入项目目录后安装依赖并启动开发服务cd vue-large-array-demo npm install npm run dev这里要注意Node.js 版本需要满足 Vite 的基本要求一般建议使用 Node.js 18 及以上。如果本地没有对应的 Vue 3 工程经验也可以直接使用一个带 vue 编译器的在线代码沙箱但最好还是本地跑一遍方便后续通过 Performance 面板做性能观测。本文示例不依赖任何第三方状态管理库也不需要虚拟滚动插件。重点展示的是 Vue 3 响应式系统原生的 API 组合因此先确认工程里能正常导入 ref、shallowRef、triggerRef、nextTick、onUpdated、v-memo 等相关能力。v-memo 是 Vue 3.2 之后内置的指令如果你的项目版本过旧需要先升级到较新的 Vue 3 版本。需要特别说明不同 Vue 版本之间部分 API 的具体性能表现和源码实现细节会有变化但响应的核心机制在 Vue 3 大版本内保持稳定。下文给出的代码思路适用于 Vue 3 全系列不会指定某个精确小版本以避免版本差异带来的误导。5. 三层优化策略从数据层到渲染层逐步收敛大数组优化最好的做法是分层处理而不是一上来就上虚拟滚动。按照改动代价由小到大、风险由低到高我通常把优化分成数据层、响应式层和渲染层三步。5.1 数据层扁平化、裁剪获取范围和避免深拷贝数据层优化的核心是“让 Vue 不需要追踪那么多东西”。最直接的问题是后端接口是否真的需要一次返回一万条完整数据很多管理系统表格卡顿并不是 Vue 的问题而是接口返回了过多无关字段或者前端在拿到数据后做了深拷贝、字段清洗等额外工作。一个容易被忽略的性能陷阱是 JSON.stringify。有人为了比较两个对象的内容是否变化会在模板里直接写 JSON.stringify(item) JSON.stringify(prevItem)或者在 watch 回调里用 JSON.stringify 对 1 万条数据做快照比较。字符串化一万个对象会产生大量瞬时内存而且一旦 JSON.stringify 出现在渲染函数执行路径上它本身就会成为新的性能瓶颈。数据层正确做法包括后端接口支持分页或只返回表格需要展示的列前端过滤掉不被模板使用的字段列表数据保持扁平结构避免每行内嵌几十个深层对象在数据写入响应式容器之前把不需要响应式的静态字段用普通对象保存即可。5.2 响应式层用 shallowRef 和 triggerRef 控制依赖追踪边界当数据无法再继续裁剪、确实需要上万条对象同时呈现在前端列表时第二层优化就是响应式层。核心手段是把默认的“深层响应式数组”降级成“浅层响应式数组”。普通 ref 包裹一个数组时数组本身是响应式的数组中的每个对象也都会被递归转换成响应式代理。这个过程建立了一个庞大的“监控网络”。shallowRef 则仅仅把 .value 这一层变成响应式对象数组内部保持原生 JavaScript 对象不建立深层代理。这样做的一个明显代价是直接修改数组内部某个对象的属性时Vue 无法感知视图不会自动更新。为了让视图依然能够按需刷新需要显式调用 triggerRef。这是一种非常值得在面试中讨论的设计思想当自动依赖追踪的代价高于收益时就把自动收集改成手动发送信号。下面用一个小例子展示 shallowRef 和 triggerRef 的关系import { shallowRef, triggerRef, nextTick } from vue const rows shallowRef([]) function appendRow(row) { // rows.value 拿到的仍然是普通数组没有深层代理 rows.value.push(row) // 手动通知外界rows.value 已经发生变化 triggerRef(rows) } function updateRowById(id, patch) { const list rows.value const row list.find(item item.id id) if (row) { Object.assign(row, patch) // 由于 row 不是深层代理必须手动触发 triggerRef(rows) } }上面代码中rows 内部存储的是最普通的数组和普通对象。appendRow 和 updateRowById 在完成数组变更后调用 triggerRef 通知所有依赖 rows.value 的副作用执行。但这里有一个必须避免的坑如果业务代码非常分散到处直接调用 triggerRef每一次触发仍然可能造成不必要的更新。更好的方式是结合调度器把多次 triggerRef 收敛到一个微任务周期内执行。import { shallowRef, triggerRef, nextTick } from vue const rows shallowRef([]) let dirty false function markDirty() { if (dirty) return dirty true nextTick(() { dirty false triggerRef(rows) }) } function batchUpdate(updater) { updater(rows.value) markDirty() } function pushRow(row) { batchUpdate((list) { list.push(row) }) } function updateRows(newRows) { batchUpdate((list) { list.length 0 list.push(...newRows) }) }这种手动标记、延迟触发的模式把对数据的多次操作压缩到一次视图刷新本质上就是“数据层自己在调度器前面搭了一道小闸门”。由于 rows.value 内部不再是深层代理每次新增一万条普通对象时Vue 不需要递归代理一万个对象从而显著减少初始化时的 CPU 和内存开销。面试时可以总结为shallowRef 把响应式系统从“随数据规模自动扩张的深层代理”改成了“只有外界显式通知时才触发的可控信号源”。5.3 渲染层组件拆分、v-memo 和按需更新响应式层的优化能减少依赖追踪成本和数据初始化成本但组件模板中每次渲染 1 万行列表时仍然需要执行一次大型虚拟 DOM diff。渲染层的目标是在保持列表结构与样式的前提下降低 diff 的规模或跳过不需要更新的子树。第一个有效手段是列表项组件化。如果 1 万行都写在一个组件模板中的 v-for 里Vue 的 diff 范围就是这个大组件的全部子节点。如果把每一行抽取成独立的子组件例如 RowItem.vue并且给每一行传入稳定的 props那么当某一行数据变化时理论上只有该行的 RowItem 需要重新渲染其他行对应的组件可以复用上次的渲染结果。第二个手段是 v-memo。v-memo 接收一个依赖数组只有当数组内的值发生变更时当前模板片段才会被重新渲染。和 v-for 配合时v-memo 可以精细控制行级更新的条件template div v-foritem in rows :keyitem.id v-memo[item.id, item.status, item.score] {{ item.name }} - {{ item.status }} - {{ item.score }} /div /template这段代码表示只有当 item.id、item.status、item.score 三者中任一值改变时这一行才会被重新渲染。如果列表更新只是增加了几行数据而旧行的这三个字段保持不变旧行节点会被命中缓存不会重复执行模板更新逻辑。v-memo 的价值在于把更新单位从“整个 v-for 列表”细化为“按模板依赖字段判断的单行”。它和组件拆分的思路不同组件拆分是按组件边界隔离v-memo 是按内存依赖数组命中缓存。两者可以组合使用也可以按项目复杂度择优。但 v-memo 也有风险。它要求你列表项模板中读取的字段必须尽量完整地出现在 memo 数组中否则当某个字段变化但未包含在 v-memo 数组里时视图可能不会更新造成“页面看起来没变化”的过期数据问题。实际项目中如果列表行模板字段较多、更新逻辑复杂优先选择组件拆分必要时再用 v-memo 做局部兜底。第三层手段才轮到虚拟滚动。虚拟滚动解决的问题是“同时展示大量 DOM 节点导致浏览器的渲染和内存压力过大”它通过只渲染视口内的行从根本上减少 DOM 数量。它的缺点是滚动条模拟、列表项高度可变、键盘导航和辅助功能支持等都需要额外处理。因此一个清晰的结论是虚拟滚动适合数据量极大且行高较规律的场景但它不能替代响应式层和渲染层的优化。如果 1 万行数据中每一行都频繁变化虚拟滚动也无法避免那一万行状态计算的消耗。6. 完整示例将一万行全量响应式列表改造成可控响应式列表下面用一个接近真实业务的场景把优化串起来。假设有一个运行监控面板需要展示最近一小时内的任务列表。每个任务有 id、name、status、progress、score 等字段。后端每 3 秒推送一次最近 1 万条任务的最新状态用户还可能会对某一行的任务执行重启操作重启后这一行的状态发生局部变化。6.1 未优化版本全量 ref 加整表替换先看一个性能不太理想但最容易写出来的版本!-- src/components/MonitorListBad.vue -- script setup import { ref, onMounted, onUnmounted } from vue const rows ref([]) let timer null function fetchData() { return Array.from({ length: 10000 }, (_, index) ({ id: index 1, name: 任务-${index 1}, status: index % 4 0 ? running : idle, progress: Math.floor(Math.random() * 100), score: Math.floor(Math.random() * 10000), })) } function flushData() { // 全量替换数组会触发 ref 的深层代理与列表重渲染 rows.value fetchData() } function restartTask(id) { const row rows.value.find(item item.id id) if (row) { row.status running row.progress 0 } } onMounted(() { flushData() timer setInterval(flushData, 3000) }) onUnmounted(() { clearInterval(timer) }) /script template ul li v-foritem in rows :keyitem.id {{ item.name }} - {{ item.status }} - {{ item.progress }} - {{ item.score }} /li /ul /template这段代码的主要问题在于rows 是深层响应式 reffetchData 赋值一万个对象时Vue 需要递归转换一万个对象及其所有属性。每 3 秒整表替换整个 MonitorListBad 组件重新执行渲染函数并重跑一万行的 diff。restartTask 修改的是 row.status由于 row 是深层代理确实能触发视图更新但这种细节更新会和每 3 秒的全量替换混在一起不容易做局部控制。6.2 优化版本shallowRef triggerRef 行级组件改造后的数据结构使用 shallowRef第一层列表变化仍然可被通知但内部每一行只是普通对象不再被递归代理。为了控制触发时机加入 dirty 标记与 nextTick 批量刷新。同时把每一行拆成独立组件 MonitorRow.vue让单个任务行的状态更新只影响自己。先看数据容器部分!-- src/components/MonitorListGood.vue -- script setup import { shallowRef, triggerRef, nextTick, onMounted, onUnmounted } from vue import MonitorRow from ./MonitorRow.vue const rows shallowRef([]) let dirty false let timer null function markDirty() { if (dirty) return dirty true nextTick(() { dirty false triggerRef(rows) }) } function flushData() { const nextList Array.from({ length: 10000 }, (_, index) ({ id: index 1, name: 任务-${index 1}, status: index % 4 0 ? running : idle, progress: Math.floor(Math.random() * 100), score: Math.floor(Math.random() * 10000), })) // 直接替换 rows.value 内部数组内容保持 rows 本身同一引用 // 然后在下一个微任务统一触发一次更新。 rows.value.splice(0, rows.value.length, ...nextList) markDirty() } function restartTask(id) { const list rows.value const row list.find(item item.id id) if (row) { row.status running row.progress 0 } markDirty() } onMounted(() { flushData() timer setInterval(flushData, 3000) }) onUnmounted(() { clearInterval(timer) }) /script template ul MonitorRow v-foritem in rows :keyitem.id :rowitem restartrestartTask(item.id) / /ul /template对应的行组件!-- src/components/MonitorRow.vue -- script setup defineProps({ row: { type: Object, required: true } }) defineEmits([restart]) /script template li span{{ row.name }}/span span{{ row.status }}/span span{{ row.progress }}/span span{{ row.score }}/span button click$emit(restart)重启/button /li /template这里需要重点解释几个设计选择。第一为什么用 splice 而不是 rows.value nextList因为 shallowRef 只对 .value 的引用替换敏感如果改成 rows.value nextList会直接触发一次更新然后再手动 triggerRef 就会触发两次。用 splice 修改原数组内部的普通对象数组不会触发 shallowRef 的自动更新全部更新时机都交给我们自己的 markDirty 控制触发次数最可控。第二MonitorRow 组件接收的 row 是普通对象组件内部模板读取 row.name、row.status 等字段时不会在 MonitorRow 内部建立对深层响应式数据的依赖因此这行组件本身也不会因为字段变化而自动重渲染。那实际更新靠什么触发答案仍然是父组件的 triggerRef。triggerRef(rows) 会让所有依赖 rows.value 的组件副作用重新执行。在模板中父组件 MonitorListGood 依赖 rows.value因此父组件会重新执行渲染函数而每一行 MonitorRow 因为是子组件父组件重新渲染时会向 MonitorRow 传递新的 row 对象。由于每一行都通过 key 对标MonitorRow 的 props 是普通对象引用除非 row 对象被替换否则子组件不会因为 props 变化而被迫立刻重渲染。但当 restartTask 修改了同一个 row 对象的字段之后触发了父组件的 triggerRef实际上 Vue 仍需要走一轮父组件的 diff才能判断哪些子组件真正变化。在 1 万行数据整体替换的 3 秒周期里splice 把 old rows 替换成 nextList 后list 中的每个元素都是新对象。父组件 diff 时根据 key 找到对应 MonitorRow发现传入的 row 对象引用全部变化就会更新所有子组件。这是不可避免的因为后端推送的 1 万条数据本身就是新的状态快照。但如果需求只是“某一行重启”restartTask 修改的 row 对象仍然是旧对象父组件 triggerRef 后进入更新MonitorRow 的 key 相同、props.row 引用也没有变化此时 MonitorRow 是否更新取决于 Vue 对 props 的响应式追踪。因为 MonitorRow 模板读取了 row.status、row.progress而 row 是普通对象不等于响应式代理所以子组件这时不会追踪到字段变化也不会因字段变化自动重渲染。这一块如果想做到局部性能极致需要结合 v-memo 或者在行组件中包装 props 的监听属于更细粒度的控制这里先不展开。由此看出shallowRef triggerRef 模式下使用者的手动控制能力增强了但代价是“自动精确到字段的更新策略”需要自己维护。这是面试和工程实践中最需要想清楚的设计权衡。6.3 更进一步v-memo 在列表中的兜底效果如果不想把行级组件拆得太细也可以用 v-memo 来跳过未变化行的重渲染。在整表替换 newRows 的场景中如果新旧行只有 id 相同但内容全都变化了v-memo 命中不了缓存仍然要全部更新如果后端推送只是局部行的微调v-memo 帮助就很大。使用 v-memo 时依赖数组需要覆盖模板中所有会被动态读取的字段template ul li v-foritem in rows :keyitem.id v-memo[item.id, item.name, item.status, item.progress, item.score] classtask-row span{{ item.name }}/span span{{ item.status }}/span span{{ item.progress }}/span button clickrestartTask(item.id)重启/button /li /ul /templatev-memo 数组中每一项必须是一个“稳定且可比较”的值。如果把 item 本身放在数组里由于新数据的对象引用总是和旧对象不同v-memo 也就失去了跳过更新的意义。只有把字段值拆出来比较才有可能命中缓存。实际项目如果同时使用组件拆分和 v-memo要警惕重复优化导致的复杂度过高。一个常见的选择是当行内模板简单时优先 v-memo当行内交互复杂、内部有子组件状态时优先行级组件拆分。7. 验证优化效果如何科学评估大数组是否真的变快优化不是“感觉流畅了”就算完成。推荐通过浏览器 DevTools 做三个层面的验证。第一是 Vue Devtools 的性能时间线。打开 Vue Devtools 的 Performance 标签录制一次 3 秒推送周期观察 Components 列表中组件更新耗时。未优化版本里MonitorListBad 组件单次更新可能耗时几十毫秒甚至更多优化版本中如果后端是整表替换总耗时不会消失但数据初始化和代理创建成本会下降调度器触发的重复更新次数会明显减少。第二是浏览器 Performance 面板。在 Performance 录制中点击页面上的“重启”按钮或等待定时推送观察紫色 Reactivity 相关任务和灰色 Scripting 任务的时长。重点看是否存在“同一时间内连续多次组件更新”的 Evidence 分布。如果每次数据变更都导致大量连续的重渲染记录说明调度器没有很好地把任务合并到同一微任务周期。第三是 Console 里的手动测量给关键流程打点const start performance.now() flushData() nextTick(() { const cost performance.now() - start console.log(本次列表刷新耗时, cost) })这样测到的耗时包含了数据生成、splice 修改、调度器队列刷新和 DOM 提交近似等于用户能感知的一次完整更新周期。多次采样后取中位数或平均值再对比未优化版本的同类指标。注意不要在定时任务执行逻辑前后混入 console.log 的大量字符串拼接否则也会影响结果。判断是否成功的标准不是“跑分最低”而是更新过程中主线程长任务数量是否明显减少。快速连续多次修改数组时渲染次数是否被收敛为一次。页面滚动和操作时是否仍然保持稳定帧率。如果发现优化后反而出现某些行不更新的问题优先检查触发链路是否完整shallowRef 包裹的数据在字段变更后有没有调用 triggerRefv-memo 的依赖数组是否覆盖了模板动态读取的字段子组件拆分后父组件的传递 props 是否有意避开了响应式代理。8. 常见问题与排查思路问题现象可能原因排查方式解决方案使用 shallowRef 后修改行内字段页面不更新深层字段变更不会自动触发 shallowRef检查是否存在 triggerRef 调用在批量操作后调用 triggerRef或用 nextTick 合并触发连续两次 triggerRef 导致组件重复渲染每次 triggerRef 都会创建新的更新任务在同步代码中打印 triggerRef 调用次数引入 dirty 标记把多次手动触发合并到微任务v-memo 行内容显示陈旧v-memo 依赖数组没有包含模板中所有动态字段对比模板字段与 memo 数组字段把模板中读取的动态字段放入 memo 数组整表替换后所有行仍全部更新新对象引用与旧对象引用不同key 相同时 props 也不同查看 key 和 row 对象引用是否变化如果只是局部字段更新改为只更新变化行如果确实是全量快照属于合理开销数据量大时首次渲染很慢深层 ref 创建了数万个对象的代理在性能面板查看脚本初始化耗时改用 shallowRef或对静态字段使用 markRaw或减少首屏渲染行数使用 JSON.stringify 对比旧数据后卡顿明显JSON.stringify 对 1 万条对象做字符串化产生大量临时内存在代码中搜索 stringify 是否出现在渲染 / 监听路径上改用字段级比较、脏标记或 unique revision 计数虚拟滚动滚动条跳动、位置不稳定行高不一致或数据更新后容器高度变化检查每行实际渲染高度固定行高或在数据刷新时保持滚动位置这里要特别强调一个坑markRaw 的使用。如果数据对象中有一部分纯展示或静态配置可以在业务层做一个普通对象副本用 markRaw 标记避免 Vue 再做响应式代理。但不要把整个大数组直接放进 markRaw因为那样数组变化时 Vue 完全无法感知你会失去响应式更新能力。markRaw 适合“某一条数据中的图片静态 URL、主题配置、不需要更新的格式化函数”这类只有局部不需要代理的场景。9. 面试怎么答能出彩从响应式架构到调度器的回答路径如果你准备 2026 年前端面试当面试官抛出“Vue 里一万条数据更新为什么卡顿你怎么优化”时最好的回答不是背出几个 API 名称而是先用十秒把问题拆出层次。建议的回答路径如下第一步指出卡顿需要分阶段定位。大数组卡的三个阶段分别是数据初始化与代理创建、依赖通知与组件更新触发、虚拟 DOM diff 和 DOM patch。不同阶段的卡顿特征不同不应该混在一起讨论。第二步解释响应式分形结构。Vue 3 的深层响应式会对嵌套对象递归建立代理读取多少层依赖追踪就扩张多少层。数组大、字段多、模板读取面广都会让响应式依赖图成倍放大。这是大数组优化的底层瓶颈。第三步讲调度器的作用。Vue 3 调度器用任务队列收集更新 Job在微任务阶段统一 flush同一组件的多次任务会被合并也可以说后到达的更新“抢占”了尚未执行的渲染机会。调度器优化的是更新频率不优化单次更新成本。第四步讲优化方案。如果数据必须全量展示先裁剪字段然后用 shallowRef 降低代理成本用 nextTick 合并 triggerRef把自动依赖变成可控触发。渲染层按行拆分组件或使用 v-memo必要时再叠加虚拟滚动。每条方案都要说明它优化的是哪一段链路。第五步摆出风险。shallowRef 会失去深层自动更新能力v-memo 用错字段会造成过期数据虚拟滚动有滚动保真问题。工程里需要按数据特征选择二维组合而不是照搬模板。这套回答能在面试官面前展示出你对 Vue 的理解已经从 API 层深入到了机制层。后续如果想继续深入可以按推荐顺序阅读 Vue 源码中的 reactivity 模块和 runtime-core scheduler 部分也可以对比 React 调度器理解“时间切片”与“任务队列去重”的差异。如果面试官进一步追问 Vue 官方新版本在响应式方面的体验优化动作那时候你已经有了本文语境里的基础框架再去查证新版本 release notes会容易得多。把大数组优化当成一道知识串联题来准备比零散背十个技巧更有价值。它把响应式系统的实现思路、调度器行为、组件更新粒度、列表渲染策略和真实性能验证方法都串在一条主线里。等你真正掌握这条主线再遇到类似表格、长列表、实时数据面板的性能问题就不会轻易被“换一个虚拟滚动组件”这种表面解法带偏。
