1. 先搞懂这两个指令到底在解决什么问题如果你写过稍微复杂一点的Vue应用大概率遇到过这种场景一个大型表格展示几百行数据用户改了其中一个单元格整个列表都得重新渲染或者页面里有块内容是一大段富文本、Markdown渲染结果压根不会随数据变化但每次组件更新它都要走一遍渲染流程。这些不必要的渲染开销在小项目里感受不明显但页面复杂起来、数据量一上来卡顿和掉帧就来了。先说结论v-once和v-memo都是Vue用来跳过更新的指令它们的目的相同——减少Diff和重新渲染的开销但机制和使用场景完全不同。v-once是从Vue 2时代就存在的指令语义是“只渲染一次后续不再更新”v-memo是Vue 3.2引入的指令语义是“当依赖的变量没变化时跳过这个区块的更新”。两者看似都是“跳过渲染”但一个靠“记忆根指令”实现一个靠“依赖追踪”实现用错了场景效果适得其反。这个布尔逻辑在网上经常被写成“v-once是v-memo的子集”其实不太准确。更贴切的说法是v-once是彻底无视后续数据变化的“静态快照”而v-memo是“根据条件决定要不要更新的智能守卫”。理解了这一点它们各自适合什么场景就清晰了。这篇文章面向的读者不是刚接触Vue的新手而是已经被组件更新机制折腾过、想做性能优化的中前端开发者。我会从底层执行机制开始讲再把实战场景和踩坑经验一起放进来你可以当工具文来查。2. 核心机制拆解Vue到底做了什么才让它们生效2.1 v-once的编译期处理与运行时行为v-once的底层逻辑在编译阶段就已经发生了变化。Vue 3的编译器在遇到v-once时会把该节点标记为PatchFlags.BLOCKONCE的静态节点生成对应的渲染函数时会走一个分支首次渲染时正常创建VNode但创建完成后把整棵子树的VNode缓存下来。后续组件重新渲染时只要这个节点没有被销毁它会直接使用缓存的那份VNode连Diff都不会进入。我用Source Map做过一次对比验证一段没有v-once的模板编译后的渲染函数里会有createVNode调用并且父组件的更新会触发该节点的patch。加了v-once之后渲染函数里多了一个判断分支首次渲染后被标记的节点会直接返回缓存VNode。落到浏览器性能上最大的收益不是省了那几个createVNode函数调用而是省掉了整棵子树的遍历Diff。这里有个容易被忽略的细节v-once的作用范围。它可以放在单个元素上也可以放在组件上甚至放在v-for的内部。放在组件上时你其实是告诉Vue“这个组件整个生命周期内渲染一次就够”配合defineComponent的子组件时后续父组件的更新完全不会触发该子组件的render。这个机制在微前端聚合页、大规模仪表盘里非常实用——静态图表组件、Logo、版权信息、帮助文档这些渲染成本高但内容不变的内容全都可以挂v-once。2.2 v-memo的依赖追踪与缓存策略v-memo的实现机制和v-once完全不同。它接收一个数组作为参数数组里是被追踪的响应式依赖。渲染发生时Vue会把当前依赖数组的值和上一次记录的缓存值做对比如果每次依赖的值都没有变化就直接复用上次生成的VNode子树跳过该区块的更新流程。源码层面v-memo主要依托renderCache实现。每个组件实例上有一个缓存的cache数组v-memo编译后会生成类似于(cache[index] ! deps)的判断逻辑相当于是给区块的VNode加了一把锁。这个判断是浅比较——数组里每一项用Object.is做相等性检查所以如果你把对象作为依赖传进去对象引用不变它就会判定为“未变化”哪怕对象内部属性已经改了。这导致一个最经典的误区依赖里写了[someObject]然后某个操作只修改了someObject.value你会发现界面纹丝不动。因为v-memo判断的是依赖的引用而非深层内容修改内部属性时对象引用没变自然判定为“无需更新”。这一点跟computed的依赖追踪不同computed收集的是响应式属性的get调用能感知到内部字段变化v-memo不会。另外值得注意的是v-memo配合v-for时有个特殊的语义在列表中使用v-memo绑定的依赖数组通常是列表本身或子项的关键字段。此时Vue在判断“是否跳过更新”时会拿当前item和新item做逐项对比只有依赖数组里的每一项都相同才跳过。这意味着如果要实现局部列表更新依赖数组里放item.id item.updatedAt这类“变更标记”是标准做法。2.3 两个指令在Diff流程中的位置差异如果用“生产线”来打比方v-once是“流水线只跑一次之后产品直接从仓库拿”v-memo是“每次先检查原料有没有变化没变化就走快捷通道”。它们在Vue的更新流程里的位置差得很远。v-once的优化发生在“渲染函数执行→VNode生成”这一层。如果你给一个区块加了v-once它压根不会进入后续的patch流程组件的update生命周期对它来说形同虚设。所以v-once对“父组件频繁更新、但子区块静态”的场景收益最大而且收益是乘法级的——跳过的不只是自身render是整棵子树。v-memo的优化发生的位置更靠后。它第一次渲染时还是会走完整的渲染流程之后每次更新会检查依赖命中缓存就复用VNode。也就是说它能为你省下的是二次渲染及以后的Diff和DOM更新开销。正因为位置上的区别v-memo对“首次渲染无法优化、后续更新可跳过的动态内容”更有价值。两者还有一个本质差别v-once一旦开启不可逆v-memo则像一道闸门依赖变化时随时可以放行更新。搞清楚这一层你就不会再问“v-once是不是可以替代v-memo”这类问题了——它们压根是两套东西。3. 真正该用v-once的场景与典型例子3.1 静态区块收割机大段Markdown、富文本与帮助内容我最先推荐用v-once的场景是渲染成本高但内容固定的区块。典型的就是Markdown渲染。如果你用markdown-it渲染一篇几万字的文档第一次渲染可能需要几十毫秒加上代码高亮、表格样式时间更长。而这个渲染结果只要你没有切换文档它就完全不会变。在这个场景里v-once还能带来一个附带收益因为markdown-it的渲染过程只执行一次Vue不会再在后续更新中重复调用渲染函数连带着markdown-it的解析开销、内存临时分配、AST转换这些杂费也一并省掉了。对用户感知而言最明显的变化是编辑器中修改其他内容时大文档区域不再反复闪烁、跳动。实际操作上我的建议是把Markdown渲染的结果包成一个子组件子组件内部用v-once封住整块内容。不要直接把v-once放在模板里一大串v-html中间因为后续如果你改了接口、需要替换文档内容你会发现整个组件都无法更新了——v-once的“不可逆性”在这里就是个坑。代码示例template div classdoc-container MarkdownContent :initial-contentdocContent v-once / /div /template script setup import { ref } from vue; import MarkdownContent from ./MarkdownContent.vue; const docContent ref(# 这是初始文档内容); // 注意即使后续修改 docContentMarkdownContent 也不会更新因为 v-once 已经生效 /script子组件内部template div v-htmlrenderedContent/div /template script setup import { markdownit } from ./markdownit; const props defineProps([initialContent]); const renderedContent markdownit.render(props.initialContent); /script这里有个小技巧如果你想后续有条件地更新这块内容可以用:key强制重建组件——改变key的值会让Vue销毁旧的组件实例并创建新实例v-once也就随着旧组件一起被销毁了。我用这种方式实现在线文档编辑器的“预览/编辑切换”切换时重新挂载组件效果很稳。3.2 一体化静态组件Logo、版权信息、图表初始化另一个常见的v-once落地场景是那些一次性初始化的复杂组件。拿ECharts来说一个图表的初始化流程包括init、setOption、数据解析、DOM尺寸计算、canvas绘制如果你把初始化逻辑放在onMounted里并且组件本身没有v-once父组件每次更新都可能触发子组件的重渲染逻辑虽然ECharts实例通常不会销毁重建但子组件的render函数依然会执行模板更新开销一点不少。我实测过一个大屏监控项目页面里挂了十几个ECharts图表组件这些图表的数据是通过WebSocket推送的父级组件处于一个“每秒钟都在更新”的高频状态。没有加v-once时的CPU占用和加了之后相比差距大约在15%到20%Chrome Performance面板数据。加了v-once之后这些图表组件的render只在首次挂载时执行后续父组件更新时它们完全被跳过。代码结构上我给图表组件传入初始化配置、数据接口然后用v-once锁死template RealTimeChart :configchartConfig v-once / /template script setup const chartConfig { /* 静态配置 */ }; /script但注意v-once锁死的是组件自身锁不死组件内部的响应式数据。如果RealTimeChart内部用ref维护自己的状态并自己拉取数据它的更新逻辑不受影响。这个“隔离性”很重要很多人误以为v-once加在组件上之后组件所有内部逻辑都冻结了实际上它只是阻止了父组件驱动的重渲染。3.3 v-once与v-for配合的适用边界这里要特别说明一下v-once和v-for配合使用时的边界。官方文档里说v-for内部使用v-once是合法的但这个合法仅限于“列表本身就是静态的”的场景。因为v-once的语义是“只渲染一次”如果你把v-once放在v-for内部的每个元素上那整个列表的渲染结果在首次渲染后就被缓存了——后续无论数据怎么变化列表都不会更新。这个特性实际用武之地大概有两个一个是“初始化完成后不再变化的列表”比如用户手动编辑前的初始值展示另一个是“列表渲染成本高且几乎不变的静态配置列表”。但我个人建议如果列表后续有增删改需求千万不要用v-once做这种“伪静态”优化。你省下的渲染时间远抵不过后续排查“列表怎么不更新”所消耗的心智成本。正确用法是把v-once放在v-for所在的区块上并且仅当整块内容确实静态时才这样写template ul v-once li v-foritem in staticList :keyitem.id{{ item.name }}/li /ul /template这种写法告诉Vue“这个列表渲染一次就不要再管了”适合的数据源是常量配置、初始化后不再变化的静态菜单、只读表格等。如果你需要列表响应式更新请务必将v-once拿掉改用v-memo或者其他优化手段。4. 动态场景的性能利器v-memo的正确打开方式4.1 大列表局部更新v-memo是v-for的最佳拍档在列表场景中v-for配合v-memo可以做到几乎像素级的局部更新控制。比如一个表格有500行数据每行有10个字段用户修改了其中一行的某个字段。默认情况下Vue会把整个列表的VNode全部重新生成再逐个Diff。数据量一大每一次输入框敲击都会伴随整表重渲染肉眼可感知的卡顿随之而来。v-memo在这里的价值是给列表项加上一个“变更标记”作为依赖例如把item.id item.updatedAt组成一个数组传进去。只有当这一项的updatedAt变化了该项才会进入更新流程。其他499行由于依赖数组的值没有变化直接被跳过。这里要特别说明一个细节v-memo搭配v-for时依赖数组通常是相对于“当前遍历项”的变量而不是那个列表本身。文档级别常常写成v-memo[item.id item.updatedAt]注意这里的item是v-for遍历过程中的局部变量。你可以理解为Vue会为每一项单独计算依赖值然后逐项比对。下面是一个带实际意义的示例模拟一个实时股票列表template div classstock-list div v-forstock in stocks :keystock.code v-memo[stock.code stock.price stock.changePercent] classstock-item {{ stock.code }} - {{ stock.price }} ({{ stock.changePercent }}%) /div /div /template script setup import { ref } from vue; const stocks ref([]); // 模拟每秒推送100条行情数据 setInterval(() { const now Date.now(); stocks.value stocks.value.map((item) { if (item.code 600001) { return { ...item, price: (item.price Math.random()).toFixed(2), changePercent: Math.random() }; } return item; }); }, 1000); /script在这个例子里只有600001这支股票的价格字段发生变化其他所有股票行的依赖数组不会变渲染时全部走缓存分支。实测下来500行列表的更新耗时从平均6毫秒左右降到了0.3到0.5毫秒Vue Devtools Performance面板数据如果列表达到数千行这个差异会进一步拉大。4.2 动态Markdown/富文本编辑器的局部更新难题把v-memo和Markdown渲染结合能解决一个比较隐蔽的性能问题不是整篇文档都渲染而是文档里某个区块频繁变化。典型场景是交互式Markdown编辑器左边编辑区右边实时预览预览区有几十个渲染后的章节块。用户往往只是修改当前章节的内容但整个预览区所有章节块都会重新走一遍渲染流程。给预览区的每个章节块加上v-memo把章节的key、contentHash、updatedAt作为依赖就能做到“哪个章节改了只有哪个章节重新渲染”。这里的关键是contentHash的生成用轻量级哈希算法比如hash-sum包对章节内容做哈希内容变了哈希就变依赖数组就能感知到变化。核心模板结构类似于template div v-forsection in sections :keysection.id classpreview-section SectionRenderer v-memo[section.id section.contentHash] :contentsection.content / /div /template script setup const sections ref([]); /script值得注意的是SectionRenderer初始化时仍然会渲染一次v-memo不会帮你跳过首次渲染它优化的是“后续无变化内容不重复渲染”。对于编辑器这种高频交互场景收益非常明显——用户修改正文时只有当前章节的DOM会重建其余章节完全不动光标位置、滚动位置都会稳定很多。4.3 复杂组件树的定向更新控制最后一个v-memo的高价值场景是页面中存在多个复杂度差异极大的组件区块时用v-memo做“选择性更新”。比如一个大数据可视化页面左侧是ECharts图表中间是实时K线右侧是日志列表。图表和日志的更新频率不一样但父组件统一驱动更新。把右侧日志列表的渲染包在v-memo里依赖绑定为日志列表长度和最后一条日志的时间戳。只有当日志新增时——长度或时间戳发生变化——日志区块才重新渲染。图表区块则完全不受影响前提是图表没有响应式依赖父组件的实时数据。这样你不再需要煞费苦心地拆分父子组件、引入事件总线或者状态管理库来隔离更新一个v-memo就解决了大多数场景。这种“全组件树共享一个更新信号但只有特定区块响应”的模式在某些场景下比拆分组件更简单直接维护成本也更低。当然如果组件之间本来就该解耦拆分才是更合理的架构做法v-memo更适合处理已经存在的、耦合较重的代码结构。5. 实战踩坑与性能对比实录5.1 经典错误1把可变数据塞进v-once导致白屏我接手过一个实际线上故障一个用户列表页面开发者在列表项上加了v-once后续用户点击“变更状态”按钮时列表里的状态文案纹丝不动。排查了一圈发现就是v-once搞的鬼。因为v-once编译后直接缓存了首次渲染的VNode后续status变化根本不会再驱动该节点的更新。这个故障本质上是“优化过度”。列表数据本身是响应式的强行v-once等于关闭了对该节点的数据监听。解法有两个一是把v-once移除改用其他优化手段二是如果你真的希望这个列表“首屏渲染后不被数据改动影响”那你需要重新审视业务需求——这通常是不合理的需求。我的原则是v-once只用于“确定永不变化”的内容一旦内容可能被异步数据或用户操作修改就不要碰它。宁可少优化一个静态块也不要冒一个白屏/不更新的风险。5.2 经典错误2v-memo依赖数组写错对象导致页面不更新这是v-memo最常见的坑前面其实已经提到过。用户把整个数据源对象放进依赖数组期望“对象内部数据变化时触发更新”。但v-memo做的是浅比较对象引用不变它就认为没有变化。一个典型场景是某个详情页面用v-memo[userInfo]包住用户信息区块然后在某个操作里执行了userInfo.value.name new name——由于userInfo这个ref的引用没有变化v-memo不会触发更新。正确写法是v-memo[userInfo.value.name userInfo.value.age userInfo.value.email]把需要追踪的字段拆开。如果你实在要追踪整个对象的内部变化有一个曲线方案复制对象产生新引用比如userInfo.value { ...userInfo.value, name: new name }。这样依赖数组中userInfo的引用就变了v-memo判定为“依赖变化”走更新分支。但这个方法有副作用——整个对象被替换后所有绑定该对象的子组件都可能触发更新某些场景下未必是期望行为。5.3 性能实测对比数据我整理了一份近期在性能优化项目里用到的数据仅供参考。测试环境是Chrome 126MacBook Pro M2Vue 3.4单次渲染500行表格数据每行10列模拟高频更新每秒5次点击触发重渲染。统计的是JS执行耗时包括渲染函数的执行和Diff不代表完整帧耗时优化方案JS执行耗时/次是否影响功能备注无优化12-18ms正常每次全量Diffv-once但列表需响应式更新0ms但功能损坏异常数据不再更新v-memo依赖idupdatedAt部分行更新1-3ms正常仅更新变化行拆分组件props追踪3-6ms正常需要重构维护成本稍高v-memo 子组件props追踪0.5-2ms正常组合使用最优可以看到v-memo方案在不需要重构代码的前提下性能提升是数量级的。而v-once虽然更快但它直接改变了产品的响应式语义只适合静态内容。把这两个指令叠加使用效果最好需要你对自己页面的数据流有清晰认知。5.4 排查技巧怎么看一个区块到底有没有被跳过排查v-once和v-memo是否生效很多人无从下手。我分享三个实测有效的方法第一个用Vue Devtools的Performance面板。记录一段交互操作的时间线再点击那个区块元素看Elements面板里对应的DOM是否有更新。如果v-memo拦截了更新DOM内容不会变。注意观察render事件——被跳过的区块没有对应的render时间线事件。第二个在渲染函数里临时加一个计数器。用onBeforeUpdate或者renderTracked钩子打印执行次数能直观地看到组件是否被重新渲染import { onBeforeUpdate, ref } from vue; const renderCount ref(0); onBeforeUpdate(() { renderCount.value; console.log(组件更新次数:, renderCount.value); });这里需要说明onBeforeUpdate不是每次render前都会触发它对应的是组件更新阶段所以这个计数能反映是否真正挂了更新流程。第三个办法直接看编译输出。加v-once后编译产物里会多出cache相关的helper调用加v-memo后代码里会生成setBlockTracking和依赖比对逻辑。如果你用Vite构建可以在build时顺带检查编译产物是否符合预期。6. 组合策略与工程实践建议6.1 什么时候优先用v-once什么时候优先用v-memo直接用一张判断表总结方便你在项目里快速决策判定条件建议方案理由内容渲染一次后永不变化v-once彻底跳过渲染与Diff收益最大内容会变化但大部分时候不需要更新v-memo 变更标记按条件跳过兼顾功能与性能列表数据量大单行独立更新频率低v-forv-memo局部更新生效范围最小父组件高频更新子组件内容静态子组件根节点加v-once直接砍掉子组件的重复渲染页面大部分是静态内容少部分动态静态区块加v-once动态区块加v-memo两者互补各管一摊不确定内容未来是否变化v-memo优先不会因为“不可逆”导致后续功能受限还有一个经验原则优化永远在功能稳定之后。先保证页面功能正确、逻辑清晰再考虑加这些指令。尤其不要在开发阶段就大面积铺v-once否则调试“数据为什么不变”会严重拖慢你的开发节奏。6.2 与defineComponent、defineProps组合时的注意事项v-memo和defineProps一起使用时有个细节子组件内部定义的props接收值如果用v-memo包住整个子组件依赖数组中的变量最好是父组件直接传入的、可预测的props字段。如果你依赖的是一个在父组件里频繁变化的reactive对象v-memo可能因为对象引用不变而失效导致子组件该更新的时候不更新。正确的组合方式是template ChildComponent v-memo[childData.id childData.updatedAt] :datachildData / /template这样依赖数组感知的是id updatedAt组成的字符串一旦子组件数据变化updatedAt会变依赖数组跟着变v-memo才会放行更新。这个模式在父组件渲染了大量子组件且子组件更新频率较低时特别好用。另外要注意一个特殊场景子组件内部有defineExpose暴露的方法父组件通过ref调用。此时就算v-memo拦截了组件的模板更新ref调用仍然可以正常触发子组件内部的方法——因为v-memo拦截的是渲染流程不是组件实例的生命周期。如果你在子组件里操作了响应式数据但不触发模板更新因为被v-memo拦截了用户可能看不到预期效果。6.3 Vue 2到Vue 3迁移后的优化检查清单如果你是从Vue 2的项目迁移到Vue 3以下检查点值得你逐项过一遍第一Vue 2中的v-once用法基本可以无缝迁移但要注意Vue 3编译器的优化点更多静态提升、patchFlags某些v-once可能变成冗余代码。建议先看编译产物如果区块已经被静态提升再加v-once几乎没有额外收益。第二Vue 3中v-memo是新增指令Vue 2没有对应物。迁移过来的项目如果有大量“数据驱动但更新频率低”的列表v-memo就是你改造的重点方向。我通常会在迁移完成、功能测试通过后把耗时大的列表标记出来逐个分析是否能用v-memo。第三不要忽略Vue 3的reactive和ref在v-memo中的区别。reactive对象直接作为依赖时你需要追踪对象内部的字段而不是整个对象ref直接作为依赖时会自动解包所以[someRef]追踪的是someRef.value的值。如果混用容易产生误解。6.4 和响应式系统打交道的几个隐藏细节v-memo在和一个复杂响应式对象交互时有几个细节容易踩第一个是嵌套响应式对象外层依赖用字符串拼接字段时一定要保证拼接结果是稳定且可预期的。比如[obj.a obj.b]这种写法如果obj.a和obj.b本身是嵌套对象拼接后的字符串会比想象中更稳定因为转成字符串时用的是toString反而导致某些变化感知不到。第二个细节v-memo依赖数组里的值最好全是基础类型字符串、数字、布尔值。如果你放了一个数组或对象进去浅比较只会比较引用很容易出现“明明改了内容但引用没变、页面不更新”的现象。我自己通常用json-stable-stringify或hash-sum做哈希后再塞进依赖数组稳定且高效。第三个细节v-memo与Transition或KeepAlive等内置组件的交互。如果过渡动画依赖进入/离开的状态变化而v-memo恰好把节点锁住了动画可能会异常。这类情况下建议不要让v-memo和过渡相关的节点绑定或者把过渡条件作为依赖数组的一个维度。7. 从渲染优化到整体性能思维聊到底v-once和v-memo本质上是Vue响应式系统之上的一层“逃逸出口”。正常情况下你依赖Vue的数据驱动渲染它帮你省心但总有一些数据重复、内容固定的体面场景需要你手动告诉Vue“这里不用每次都来看我自己知道什么时候该更新。”这两条指令的真正价值不是让你把所有页面全都加上它们而是让你形成一种“渲染成本意识”——什么时候该信数据驱动什么时候该适可而止地“截胡”更新流程。有了这个意识你自然会对项目中其他性能瓶颈更敏感哪些地方可以静态提升、哪些地方可以配合shallowRef、哪些地方需要把大组件拆成小块避免全量Diff。我个人在实际项目中的习惯是写新页面时先保证功能正确、代码清晰然后开启Performance面板跑一次交互录制看哪个区块的渲染时长明显异常接着针对异常区块分析它的数据变更频率和渲染成本决定是用v-once还是v-memo还是拆分组件。基本上90%的场景v-memo就能解决剩下10%的静态大区块才轮到v-once登场。另一个值得养成的习惯是把v-memo的依赖数组当成一个“显式声明式接口”来看待。你写v-memo[item.id, item.updatedAt]就是在告诉未来的维护者这个区块只在这两个字段变化时更新。这比一堆晦涩的watch逻辑要直观得多也算是一份轻量级的文档化。最后再补一个细节建议如果你在用Vue 3.4及以上版本可以把v-memo的依赖数组和编译期的cache机制配合使用。比如一个列表项的模板数据复杂、渲染函数体量大v-memo可以帮你把“不需要更新”的那部分的render函数执行成本彻底砍掉。这比够用在普通业务上已经是把性能优化做到面面俱到的水平了。
