简介面向 Vue.js 开发者这份 PDF 文档深入讲解了如何结合 Vuex 与 keep-alive 实现 tab 标签页的页面缓存功能非常适合管理后台、数据看板等需要多页面快速切换并保持操作状态的场景。文档从 keep-alive 的 include 属性与 Vue Router 的 name 属性如何配合入手说明缓存组件的筛选原理随后基于 Vuex 设计 cacheView 与 toolBarData 两个状态数组分别保存需要缓存的组件名和已打开的标签信息借助 actions 与 mutations 完成添加标签、删除标签、清除缓存等操作。针对关闭标签时的边界情况例如关闭的标签刚好是当前激活页、是最后一个标签等情况文档梳理了对应的路由回退逻辑代码思路清晰。整份文档仅含 1 个 PDF 文件大小 68KB包含整体设计思路、核心 store 代码、App.vue 入口文件配置方便直接对照实践。目前已有 3186 人学习下载适合希望减少重复请求、提升后台系统流畅度的中高级前端开发者。1. 从一次“列表页状态丢失”说起做管理后台的朋友应该都有过这种体验在用户列表页筛选好条件、翻到第 3 页点进某个用户的详情再返回列表页时筛选项和页码全被重置了。如果这个操作一天重复几十次用户不骂街才怪。Vue 生态里解决这个问题的标准组合就是keep-alive加vuex前者负责把路由组件实例缓存下来后者负责动态地告诉keep-alive到底要缓存哪些页面。这篇文章要拆的就是这套组合的完整落地方式——不是简单地贴一个keep-alive的 include 静态数组而是做成一个带标签栏、可关闭、可清除缓存的管理系统通用方案。适合正在写后台管理系统、对路由缓存原理只停留在“用过但没搞懂”阶段的同学。2. keep-alive 的缓存机制与 include 匹配规则2.1 为什么是 include 而不是直接缓存所有页面keep-alive是 Vue 内置的抽象组件它在渲染子组件时会额外做一层“实例缓存”的动作。当一个被它包裹的组件被切换走时组件实例不会销毁而是被存放在一个缓存对象里下次再切回来直接复用内存里的实例mounted不会重新触发数据状态原样保留。但管理系统的页面不是全都需要缓存。比如登录页、404 页、表单填写页这些页面每次进入都应该是全新的状态。所以真实项目里几乎不会写一个裸的keep-aliverouter-view //keep-alive而是通过include属性来控制缓存白名单。规则很简单include接收一个组件name的数组数组里有谁就缓存谁没有的就不管。keep-alive :include[UserList, OrderList] router-view / /keep-alive这段代码的意思是只有组件name为UserList和OrderList的路由页面会走缓存逻辑其他页面每次进入都会重新创建实例。需要注意这里匹配的是组件自身的 name 字段不是路由配置里的 path 或者 name。2.2 组件 name 和路由 name 是两回事很多新手在这里会踩坑。路由配置里写name: user-list但页面组件里没有写name属性结果 include 写了一大串缓存一个都不生效。Vue Router 4.x 的官方文档也特别提过动态路由的name和组件的name是两个独立的东西火山口就出在这个理解偏差上。// router/index.js { path: /user/list, name: UserList, // 这是路由 namekeep-alive 不认它 component: () import(/views/user/List.vue) }!-- views/user/List.vue -- template div用户列表/div /template script export default { name: UserListPage // 这才是组件 namekeep-alive 的 include 匹配它 } /scriptkeep-alive的 include 匹配不到名字就老老实实走“销毁重建”的默认逻辑压根不会缓存。所以实现 tab 缓存方案的第一步不是在 store 里写代码而是去把项目里所有需要缓存的页面组件都补上name属性。如果用的是script setup语法需要通过defineOptions({ name: UserListPage })显式声明否则组件 name 是取不到的。2.3 为什么要把缓存数组放进 vuex静态 include 数组只能解决“固定的页面需要缓存”这种简单场景但我们要做的是带 tab 标签的管理系统。用户打开哪些页面是不确定的A 用户可能只打开“用户管理”和“订单管理”B 用户可能额外打开“商品管理”。这个“已打开的页面集合”是一个典型的全局共享状态它同时被路由视图区域、顶部标签栏、关闭按钮三方依赖。如果不用 vuex就得在 App.vue 里维护一个数组然后通过provide/inject传给 ToolBar 组件还要再想办法把路由变化同步进去——代码很快就会变成一团乱麻。vuex 的价值在于它是一个全局单例任何组件都能通过dispatch提交修改通过getters读取最新数据不需要关心组件层级关系。这是用 vuex 而不是用组件内data的核心理由不是因为它“流行”而是因为这个数据天然就是跨组件共享的全局状态。3. vuex store 设计两个数组各司其职3.1 toolBarData 和 cacheView 为什么必须分开这是这套方案里最容易被问到的设计决策。直观感受上标签页打开的页面和需要缓存的页面似乎是一一对应的为什么不合成一个数组如果合并成一个数组每个元素既要存路由路径、标签展示名又要在需要缓存时被keep-alive直接读取。但keep-alive的 include 只认字符串数组不管对象。每次状态更新都要做一次map转换而且关闭标签时还要判断“这个标签对应的组件是否还应该留在缓存里”——因为有 tab 固定不可关闭的情况比如首页。拆成两个数组cacheView是一个纯字符串数组直接绑定给 include语义干净利落toolBarData是对象数组负责 UI 层展示互不干扰。state: { toolBarData: [], // 标签栏数据元素格式 { detail, name, componentName } cacheView: [] // keep-alive 的 include 绑定数组元素是组件 name 字符串 }toolBarData里的detail是路由路径用于跳转和激活态判断name是标签上显示的中文名称componentName是组件 name它同时被两个数组使用——这是两个数组之间的隐形关联键。3.2 mutations 里的边界条件clearToolItem 的三种情况store 的核心代码里最复杂的逻辑是clearToolItem。这一步要处理关闭标签后的路由跳转而跳转方向取决于被关闭的标签是不是当前激活页以及它是不是最后一个标签。下面是把细节完全展开的版本clearToolItem(state, detail) { // 找当前要关闭的标签在数组中的位置 const index state.toolBarData.findIndex(item item.detail detail) // 被关闭的标签是否就是当前正在展示的路由 const isActive router.app.$route.path detail const len state.toolBarData.length - 1 // 从标签数组中移除该元素 state.toolBarData.splice(index, 1) // 关闭的是激活中的标签或者关闭的是数组最后一个——都要做跳转 if (index len || isActive) { const target state.toolBarData[state.toolBarData.length - 1] target router.push({ path: target.detail }) } }这个函数里有两个需要仔细品一下的设计。第一isActive的判断用的是router.app.$route.path这意味着用户物理点击浏览器刷新后就算当前路由是从地址栏直接输入进来的、不属于任何标签页关闭任意标签时也能拿到真实的当前路径。第二index len这个条件覆盖的是“关闭的是最后一个标签”的场景此时不管被关闭的是不是激活页都要退回到新的最后一个标签如果两个条件都不满足说明用户关的是历史标签当前页面不受影响不需要跳转。用表格可以更清晰地看出三种场景的走向场景isActiveindex len跳转行为关闭激活中的标签非最后一个truefalse跳到最后打开的标签关闭最后一个标签falsetrue跳转到新的最后一个标签关闭历史标签falsefalse不跳转留在当前页3.3 为什么 actions 里要同时提交两个 mutationcommitToolBar这个 action 是打开新页面时的统一入口它连续提交两个 mutation。第一个setToolData往标签数组里加新标签第二个setCacheView往缓存数组里加组件 name。这里有个“失败设计”值得多说一句setToolData里用find判断是否已存在而setCacheView用includes两者的标准不一样。setToolData(state, data) { // 用 detail路由路径判断标签是否已打开 const inToolbar state.toolBarData.find(item item.detail data.detail) !inToolbar state.toolBarData.push({ ...data }) }, setCacheView(state, data) { // 用 componentName组件名判断是否需要加入缓存 if (state.cacheView.includes(data.componentName)) return state.cacheView.push(data.componentName) }路径是唯一的一个路由不可能同时以两个路径存在于标签栏里所以用find精确匹配就能挡住重复添加。组件 name 可能被多个路由复用虽然不推荐但确实存在用includes是防御性的写法确保同一个组件名不会被重复塞进缓存数组导致 include 行为异常。两个 mutation 的幂等策略不同是因为它们各自面对的数据结构不同这个细节可以作为代码 review 时的一个讨论点。提示mutations里不建议直接router.push这种做法因为它会让 store 依赖路由实例测试和复用都变得困难。上面代码里写的是常见做法如果项目里用了 Vuex 4可以把路由跳转调用点放到组件里由 dispatch 的返回值或其他状态来驱动跳转。4. App.vue 的 watch $route 与 ToolBar 组件实现4.1 从 $route.matched 里捞组件 nameStore 骨架搭好之后接下来要在路由入口处把“路由变化”翻译成“store 数据更新”。这块的完整代码看起来是// App.vue 或 layout 的主内容区域 watch: { $route() { // 通过 matched 拿到当前路由匹配到的组件定义 const componentName this.$route.matched[0].components.default.name const detail this.$route.path const name this.$route.meta[0].name this.$store.dispatch(commitToolBar, { name, detail, componentName }) } }这里有几个关键坑需要说明。首先从matched[0].components.default.name取组件 name 是最保险的做法因为this.$route.name是路由 namethis.$route.matched里才能拿到被解析的组件定义。如果你的路由配置里用了多级嵌套matched[0]取到的是最外层路由的组件这会导致所有子路由都缓存同一个父组件。这种情况下应该遍历matched数组找到最后一级页面组件的 name。其次this.$route.meta[0].name是闭包陷阱的重灾区。如果某个路由没有配置 meta或者配置了多个 meta这里直接报错或者取到undefined。建议先判空const name this.$route.meta?.[0]?.name ?? this.$route.name ?? 未命名最后这个 watch 放在 App.vue 里还是布局组件里会影响matched的解析结果。放在 App.vue 里时this.$route是全局路由的响应式对象能拿到完整信息放在子组件里会因为组件层级问题拿不到顶层的 matched所以尽量放在最外层布局。4.2 keep-alive 和 router-view 的嵌套顺序模板层的写法直接决定了缓存是否生效以及过渡动画是否正常el-main styleposition:relative;margin-top:45px; ToolBar / div classrouteWrap transition namefade-transform keep-alive :includecachedViews router-view / /keep-alive /transition /div /el-maintransition在外层、keep-alive在内层、router-view在最内层这个嵌套顺序是官方推荐的组合方式。反向的话keep-alive作为 transition 的子元素仍然能工作但过渡动画的钩子函数可能拿不到完整的状态。include绑定的cachedViews是来自 vuex 的 gettercomputed: { ...mapGetters([getToolData, getCacheView]), cachedViews() { return this.getCacheView } }用 computed 的好处是当 vuex 里的cacheView数组变化时keep-alive会自动重新匹配。有一个细节值得注意keep-alive的 include 匹配是监听数组变化的你在 store 里push还是splice它都能感知到但如果你直接替换整个数组的引用比如state.cacheView newArr会导致所有缓存实例被清掉因为 keep-alive 会认为白名单全变了。4.3 ToolBar 组件与关闭、点击的交互闭环ToolBar 组件负责把toolBarData渲染成可视化的标签以及把用户操作抽象成 dispatch。核心模板和脚本template div classtoolbar el-tag v-for(item, index) in getToolData :keyitem.detail :closableitem.detail ! /dashboard :disable-transitionsfalse :class{ active: $route.path item.detail } clickredirect(item) closecloseToolItem(item) span v-if$route.path item.detail classdot/span {{ item.name }} /el-tag /div /template script import { mapGetters } from vuex export default { methods: { // 关闭标签同时清理标签数据和缓存数据 closeToolItem(item) { this.$store.dispatch(clearToolBar, item) this.$store.dispatch(clearCache, item.componentName) }, // 点击标签切换路由 redirect(item) { this.$router.push({ path: item.detail }) } }, computed: { ...mapGetters([getToolData, getCacheView]) } } /scriptclose 事件的细节是分两步 dispatch第一步处理标签数组第二步处理缓存数组。不要试图把两步合并成一个 action因为它们的语义不同——clearToolBar是关闭 tab 这个 UI 动作clearCache是销毁缓存实例这个数据动作下次打开同一页面时如果只清标签不清缓存include里还留着这个组件名但标签没了用户就再也无法通过 UI 进入这个页面缓存的实例成了“僵尸对象”。:closable的粒度控制很有用。实际项目里通常把首页固定为不可关闭上面的代码用item.detail ! /dashboard实现了这个效果不用专门给首页加 state 标记。如果需求是“某个角色不可关闭某些页面”可以在这里扩展判断条件比如根据当前用户的权限列表去匹配。5. 路由组件生命周期activated 与 deactivated 的正确用法5.1 缓存后 mounted 只执行一次数据刷新要靠 activated被keep-alive缓存的组件第一次进入时created和mounted会正常执行但之后切走再切回这两个钩子都不会再触发。能感知到路由切换的只剩下activated进入时触发和deactivated离开时触发。这正是缓存方案的双刃剑。好处是表单草稿、列表页的筛选条件都还在接口不会重复请求坏处是如果你的列表页每次进入都要拉最新数据mounted里的getList()不会替你执行了。标准做法是把“首次加载”放mounted把“每次重复进入的数据刷新”放activatedscript export default { name: UserListPage, data() { return { form: { name: , page: 1, pageSize: 10 }, list: [] } }, created() { // 只在组件实例创建时执行一次 this.initParamsFromQuery() }, mounted() { // 首次进入时加载数据 this.getList() }, activated() { // 从缓存中被重新激活时刷新列表 // 这里可以不重新请求直接用缓存数据 // 也可以根据业务需要决定是否强制刷新 this.getList() }, deactivated() { // 组件被缓存但页面切走时清空敏感数据 Object.keys(this.form).forEach(key { this.form[key] }) } } /script实际开发中可以根据页面性质决定activated里放什么。比如订单列表页用户很可能在详情页处理了订单状态返回列表时需要看到最新状态那activated里必须有getList()而一些基础资料页数据基本不变activated可以是空的直接读缓存的状态就够了。还有一种常见做法是给页面加一个isNeedRefresh标记只有被标记过的页面在activated里才重新请求避免所有 tab 来回切都刷接口。5.2 deactivated 里清数据的取舍很多人会忽略deactivated的应用场景。它做的最典型的一件事是把页面上不该长期驻留的数据还原。比如新建表单页用户填了一半切去别的 tab回来时希望表单还在但如果是“订单提交成功”后的详情页用户离开了就应该清掉关键信息避免下次误操作提交旧数据。在deactivated里清数据要注意一点这里的操作会直接修改组件的数据状态而这些状态变化不会被缓存实例“保存”因为组件实例本身还在内存里下次激活时数据就是你改动后的样子。所以如果你在deactivated里做了this.form {}回来时表单一定是空的。这个特性和keep-alive的缓存机制结合起来可以做出比“销毁重建”更细腻的交互控制。5.3 关闭标签时如何验证缓存真的被清掉了这里提供一个我常用的验证方案。当用户关闭 tab 时正确的预期是标签消失、include数组中移除该组件名、缓存实例被销毁。但 Vue 的内存回收是异步的不能光靠感觉判断。浏览器直接验证// 在 keep-alive 外层组件上加一个 mounted 钩子 mounted() { // 拿到 keep-alive 内部的 cache 对象 const keepAlive this.$refs.keepAlive console.log(keepAlive.cache) // 这里能看到被缓存的组件实例 }你可以在closeToolItem里关闭标签后输出一次keepAlive.cache正常情况下它包含了所有被缓存的组件实例的 VNode关掉的标签对应的组件 key 应该消失。如果发现 key 还在说明cacheView的清除没生效检查一下clearCacheView里面 splice 的索引是不是对的。同时打开 Vue Devtools切到 Vuex 面板观察cacheView数组的变化。关闭标签时两个 dispatch 是同步的Vuex 的 mutation 默认同步所以面板里应该同时看到toolBarData长度减一和cacheView数组里对应的组件名被移除。如果toolBarData变了但cacheView没变那一定是clearCache里传的componentName和setCacheView里存的不一致——最常见的原因就是某个路由页面组件忘了写name。6. 缓存应用的进阶处理include 的边界与多级路由前面几节解决了“能跑通”的问题但把时间再往后拨一点你会遇到更现实的挑战多级路由、动态路由、以及keep-alive的一个隐藏陷阱——include 匹配到组件名时缓存整个组件的所有实例但同一个组件名如果同时被多个路由复用缓存会错乱。6.1 多个路由共用一个组件时 include 会串数据假设你有/user/list和/user/recycle两个路由都加载UserList.vue组件name都是UserListPage。按 include 的匹配规则两个路由会被当成同一个组件来处理切走一个另一个也被缓存。表面上省了内存实际上数据会互相污染在回收站页面筛选了状态切到正常列表却发现筛选条件也被过滤了。解法有两个。一个是为相同组件写不同的包装组件让每个路由对应唯一的组件name另一个是放弃用keep-alive的 include 匹配组件名改用路由表配置来决定是否缓存。第二种方案的实现思路是这样的watch: { $route() { // 从路由 meta 里读取是否需要缓存 const needCache this.$route.meta.keepAlive const componentName this.$route.matched[0].components.default.name if (needCache) { this.$store.dispatch(commitToolBar, { detail: this.$route.path, name: this.$route.meta.name, componentName }) } } }哪条路由需要缓存直接去路由配置里看meta.keepAlive这个标签一眼就懂。但注意这种方案下如果两个路由指向同一个组件且都需要缓存还是会遇到上面说的实例冲突问题。真正的根治方法只有“一组件一 name”这是把控项目代码时值得坚持的一条红线。6.2 重新打开已关闭的标签数据为什么是旧的一个真实场景的排查记录用户关闭了“订单管理”标签cacheView也剔除了OrderListPage然后重新从菜单打开订单管理——数据竟然还是上次筛选出来的旧结果。如果遇到这个现象先确认一件事菜单跳路由用的方式是不是router.push到了同一个 path。如果路径没变、组件 name 没变keep-alive发现 include 重新包含了这个名字虽然会重建实例但这个“重建”发生在activated生命周期之后、mounted之前。如果组件里有activated钩子它会在新实例创建时也执行一次。排查顺序建议是看 Devtools 的 Vuex 面板确认cacheView真的被移除了再看控制台有没有组件报错最后在组件里加一个beforeRouteEnter钩子打日志。我遇到过的案例里十次有八次是这个组件在某个父组件里又被包了一层keep-alive导致结构变成了“keep-alive 套 keep-alive”内层的 include 清掉了外层还有一份缓存。6.3 明确 include 动态变化时的组件重建时机最后收在性能优化上。keep-alive的 include 绑定一个计算属性时Vue 会监听数组变化并对于移除的组件名调用destroy流程销毁实例。但这个销毁不是即时的——它被标记为需要销毁真正的内存回收要等垃圾回收机制来执行。频繁地添加、移除缓存会让内存中残留大量待回收的 VNode 和组件实例。一个可行的优化策略是不在closeToolItem里同时移除cacheView而是延迟到路由真正切换之后再做二次确认。不过这样代码复杂度会明显上升。更建议的做法是做完整个方案后用 Vue Devtools 的 Performance 面板记录一次“打开 10 个 tab 全部关闭”的操作观察内存曲线的下降趋势。如果下降曲线是阶梯状、每级之间有停顿说明 Vue 的异步回收在正常工作如果内存一直不掉再考虑用v-if控制 keep-alive 的渲染包裹层来强制整体刷新。提示不要为了“性能”过度设计。大多数中后台项目5 到 10 个 tab 同时开启的状态下keep-alive 的内存占用完全在可控范围内。先把“关闭标签后再次打开页面状态正确”这个行为做对再讨论内存优化。这套从 store 设计到生命周期再到排错验证的思路配合keep-alive的 include 机制能够支撑绝大多数管理后台的标签页需求。遇到边缘情况时先厘清“组件 name、路由 name、include 匹配、实例缓存”这四个概念之间的关系再动手调试大部分问题能在十分钟内定位到根因。本文还有配套的精品资源点击获取