动态组件缓存失效你可能漏了这行关键配置上周排查一个生产环境 bug管理后台的标签页切换时每次都会重新请求接口明明用了 打开 Chrome 性能面板才发现被缓存的组件实例在切换路由时被销毁了。你一定也遇到过类似的场景——明明加了缓存为什么还会重复渲染根因Vue 的 只缓存匹配的组件名或路由名。如果动态组件没有显式声明name选项或者路由配置缺少name字段缓存就会失效。在源码层面 内部通过cache对象用组件名作为 key 来存储 vnode没有 name 时就会用随机生成的 key。错误写法!-- 动态组件场景 -- keep-alive component :iscurrentComponent / !-- 子组件未定义name -- /keep-alive !-- 路由场景 -- keep-alive router-view / !-- 路由配置未定义name -- /keep-alive正确写法!-- 方案1显式定义组件名 -- script export default { name: UserList // 必须与keep-alive的include/exclude匹配 } /script !-- 方案2路由meta标记 -- const routes [ { path: /users, component: UserList, name: UserList, // 关键 meta: { keepAlive: true } } ]性能对比在一个包含复杂表格的页面中启用正确缓存后二次渲染时间从 1200ms 降到 200ms测试数据量 500 行。避坑清单动态组件的name必须与 的include/exclude完全匹配区分大小写使用 时路由配置必须同时设置name和meta.keepAlive被缓存的组件中如果用到了activated钩子注意避免重复执行初始化逻辑缓存过多组件可能导致内存泄漏建议用include/exclude精准控制用 v-for 渲染大型列表这行配置让你的性能翻倍在运维管理后台渲染 3000 节点的树形菜单时页面直接卡死。你以为用虚拟滚动就万事大吉Vue 的v-for在默认情况下会给每个节点添加响应式劫持对于纯展示型大数据量场景这完全是性能浪费。根因Vue 会对v-for的每个元素进行Object.defineProperty代理Vue 2或Proxy包装Vue 3。当数据量达到千级时初始化耗时呈指数增长。通过Object.freeze冻结数据可以跳过响应式转换但会丧失数据变更检测能力——这正是展示型列表需要的取舍。优化前template !-- 3000条数据直接渲染 -- ul li v-foritem in hugeList :keyitem.id {{ item.name }} /li /ul /template script export default { data() { return { hugeList: fetchData() // 返回3000条未冻结的数组 } } } /script优化后script export default { data() { return { hugeList: Object.freeze(fetchData()) // 关键 } } } /script实测数据在 5000 条数据的渲染测试中默认模式初始化 4200ms内存占用 1.2GB冻结数据后初始化 600ms内存占用 200MB注意事项冻结后的数据不能再使用Vue.set/vm.$set修改嵌套数据需要深冻结可用lodash.deepFreeze如果列表需要局部更新应该拆分为多个v-for小块结合v-memoVue 3可进一步避免无关 diff自定义指令的内存泄漏陷阱还记得那个因为忘记清理事件监听导致整个 SPA 内存泄漏的夜晚吗我们有一个全局的v-click-outside指令在模态框、下拉菜单等 30 组件中使用。用户反馈浏览器标签开久了就卡顿用 Memory 工具快照后发现卸载的组件中仍有大量的document事件监听未被移除。根因Vue 的自定义指令有完整的生命周期钩子但开发者往往只关注bind/inserted而忽略unbind。当指令绑定到 DOM 事件、定时器或第三方库实例时如果不手动清理这些引用会阻止垃圾回收。危险写法Vue.directive(click-outside, { inserted(el, binding) { el._clickOutside e { if (!el.contains(e.target)) { binding.value() } } document.addEventListener(click, el._clickOutside) // 潜在泄漏点 } })安全写法Vue.directive(click-outside, { inserted(el, binding) { const handler e { if (!el.contains(e.target)) binding.value() } document.addEventListener(click, handler) el._clickOutside handler // 存储引用用于清理 }, unbind(el) { document.removeEventListener(click, el._clickOutside) // 必须清理 } })排查技巧在 Chrome DevTools 的 Memory 面板对比组件卸载前后的EventListener数量使用performance.memoryAPI 监控 JS 堆大小变化WeakMap 比直接挂载到 DOM 元素更安全Vue 3 推荐总结Vue 的高阶玩法就是与框架机制共舞当你遇到反直觉的现象时别急着 hack先问三个问题Vue 的响应式系统此刻在做什么虚拟 DOM 的 diff 策略是什么当前的生命周期处于哪个阶段我在处理表单动态校验规则时就因为没搞明白watch的 immediate 和 deep 的触发时机白花了半天调试。你在项目中是怎么处理 Vue 性能问题的欢迎在评论区分享你的实战案例。 
长河君 · 2026/10/15 2:53:31 · 阅读 1.2k Vue实战技巧总结
动态组件缓存失效你可能漏了这行关键配置上周排查一个生产环境 bug管理后台的标签页切换时每次都会重新请求接口明明用了 打开 Chrome 性能面板才发现被缓存的组件实例在切换路由时被销毁了。你一定也遇到过类似的场景——明明加了缓存为什么还会重复渲染根因Vue 的 只缓存匹配的组件名或路由名。如果动态组件没有显式声明name选项或者路由配置缺少name字段缓存就会失效。在源码层面 内部通过cache对象用组件名作为 key 来存储 vnode没有 name 时就会用随机生成的 key。错误写法!-- 动态组件场景 -- keep-alive component :iscurrentComponent / !-- 子组件未定义name -- /keep-alive !-- 路由场景 -- keep-alive router-view / !-- 路由配置未定义name -- /keep-alive正确写法!-- 方案1显式定义组件名 -- script export default { name: UserList // 必须与keep-alive的include/exclude匹配 } /script !-- 方案2路由meta标记 -- const routes [ { path: /users, component: UserList, name: UserList, // 关键 meta: { keepAlive: true } } ]性能对比在一个包含复杂表格的页面中启用正确缓存后二次渲染时间从 1200ms 降到 200ms测试数据量 500 行。避坑清单动态组件的name必须与 的include/exclude完全匹配区分大小写使用 时路由配置必须同时设置name和meta.keepAlive被缓存的组件中如果用到了activated钩子注意避免重复执行初始化逻辑缓存过多组件可能导致内存泄漏建议用include/exclude精准控制用 v-for 渲染大型列表这行配置让你的性能翻倍在运维管理后台渲染 3000 节点的树形菜单时页面直接卡死。你以为用虚拟滚动就万事大吉Vue 的v-for在默认情况下会给每个节点添加响应式劫持对于纯展示型大数据量场景这完全是性能浪费。根因Vue 会对v-for的每个元素进行Object.defineProperty代理Vue 2或Proxy包装Vue 3。当数据量达到千级时初始化耗时呈指数增长。通过Object.freeze冻结数据可以跳过响应式转换但会丧失数据变更检测能力——这正是展示型列表需要的取舍。优化前template !-- 3000条数据直接渲染 -- ul li v-foritem in hugeList :keyitem.id {{ item.name }} /li /ul /template script export default { data() { return { hugeList: fetchData() // 返回3000条未冻结的数组 } } } /script优化后script export default { data() { return { hugeList: Object.freeze(fetchData()) // 关键 } } } /script实测数据在 5000 条数据的渲染测试中默认模式初始化 4200ms内存占用 1.2GB冻结数据后初始化 600ms内存占用 200MB注意事项冻结后的数据不能再使用Vue.set/vm.$set修改嵌套数据需要深冻结可用lodash.deepFreeze如果列表需要局部更新应该拆分为多个v-for小块结合v-memoVue 3可进一步避免无关 diff自定义指令的内存泄漏陷阱还记得那个因为忘记清理事件监听导致整个 SPA 内存泄漏的夜晚吗我们有一个全局的v-click-outside指令在模态框、下拉菜单等 30 组件中使用。用户反馈浏览器标签开久了就卡顿用 Memory 工具快照后发现卸载的组件中仍有大量的document事件监听未被移除。根因Vue 的自定义指令有完整的生命周期钩子但开发者往往只关注bind/inserted而忽略unbind。当指令绑定到 DOM 事件、定时器或第三方库实例时如果不手动清理这些引用会阻止垃圾回收。危险写法Vue.directive(click-outside, { inserted(el, binding) { el._clickOutside e { if (!el.contains(e.target)) { binding.value() } } document.addEventListener(click, el._clickOutside) // 潜在泄漏点 } })安全写法Vue.directive(click-outside, { inserted(el, binding) { const handler e { if (!el.contains(e.target)) binding.value() } document.addEventListener(click, handler) el._clickOutside handler // 存储引用用于清理 }, unbind(el) { document.removeEventListener(click, el._clickOutside) // 必须清理 } })排查技巧在 Chrome DevTools 的 Memory 面板对比组件卸载前后的EventListener数量使用performance.memoryAPI 监控 JS 堆大小变化WeakMap 比直接挂载到 DOM 元素更安全Vue 3 推荐总结Vue 的高阶玩法就是与框架机制共舞当你遇到反直觉的现象时别急着 hack先问三个问题Vue 的响应式系统此刻在做什么虚拟 DOM 的 diff 策略是什么当前的生命周期处于哪个阶段我在处理表单动态校验规则时就因为没搞明白watch的 immediate 和 deep 的触发时机白花了半天调试。你在项目中是怎么处理 Vue 性能问题的欢迎在评论区分享你的实战案例。