企业官网建设流程全解析

不知道你有没有遇到过这种情况：在若依后台里打开一个表单页面，填了一半内容，临时切到别的菜单看个数据，再切回刚才的页面，发现整个页面重新加载了，填好的内容全没了；或者是在列表页好不容易筛好条件翻到第三页，切出去再回来，列表重置回第一页，接口唰唰唰又重新请求了一遍。这种体验在基于若依框架的后台项目里太常见了。

先说结论：并不是若依框架做不到页面保持，而是多数人对它自带的标签页缓存机制只知其一不知其二。框架其实已经在 AppMain 组件里挂好了 keep-alive，也建好了缓存列表 cachedViews，但默认情况下很多页面的路由 meta 里根本没有开启 keepAlive 这个开关，所以页面一切走，组件实例就直接销毁，里面的数据自然归零。

这篇我就围绕"若依Vue版切换tab页签时页面保持不重新加载"这件事，把底层机制讲透，再给你可以直接抄的配置步骤、验证方法、排查链路，以及不同业务场景下的按需缓存做法。文章以若依Vue3版为主线，Vue2版原理一致，对照着改也能用。

1. 先搞明白：若依的tab页签为什么会"忘记"你的页面

1.1 点击tab切换本质上是一次路由跳转

很多人第一次看若依的标签页，会觉得它是类似桌面软件那样的"多窗口"，各切各的互不影响。其实不是，若依的标签导航组件 just 是一个可视化的快照，你每点一个tab，背后就是一次 router.push 跳转。

也就是说，从"用户管理"切到"角色管理"，再做一次路由跳转把当前路由切换过去。这个过程中，原先路由对应的页面组件会经历一次卸载（ unmount 或 destroyed ），新路由对应的页面组件重新挂载（ mount ）。如果没有额外的缓存机制，你在"用户管理"页面里维护的所有状态——表单内容、下拉选中值、列表分页、搜索条件——都会随着组件销毁被回收。

我见过不少朋友试图用 keep-alive 去解决这个问题，去百度搜"若依 页面不刷新"，得到的结果是先打开 AppMain.vue 把 keep-alive 加上。实际上，若依框架早就把这层封装做完了，大多数人缺的不是 keep-alive 本身，而是让页面进入缓存名单的配置。

1.2 若依自带的缓存机制是怎么设计的

在若依Vue3版里，框架已经做好了这么几件事：

• AppMain.vue 中的 router-view 外层包了 keep-alive，include 绑定的是缓存名单。
• 缓存名单存在 Pinia 的 tagsView store 中，核心是 cachedViews 数组。
• 每次路由跳转前，全局路由守卫 permission.js 里会调用 tagsViewStore.addView(to) 方法。
• addView 方法会判断当前路由的 meta.keepAlive 是否为 true，如果是，就把当前路由的 name 字符串 push 进 cachedViews。

所以整个链路是：你访问了一个路由，路由守卫发现这个路由标记了需要缓存，就把组件名字加入缓存名单。之后你切走再切回来，keep-alive 发现当前正要渲染的组件 name 在缓存名单里，就直接从缓存里把之前那个实例捞出来给你用，不再创建新实例，也不再走 created / mounted。

你可以把 keep-alive 理解成给组件开了一个"省电模式"：切走时不销毁，而是把整个实例冻结在内存里；切回来时直接唤醒恢复现场。没有开启缓存时，每次切换都像关掉App再重新打开一样，数据自然留不住。

1.3 "没配置"和"框架做不到"是两码事

我为什么要强调这一点？因为我在不少技术群里看到有人问"若依能不能让页面不重新加载"，下面有人回复"可以自己改造 keep-alive"或者是"用 sessionStorage 把数据存下来"。这两种说法都有点误导。

若依框架本身就已经实现了tab页签缓存的能力，你要做的不是重新发明轮子，而是把某个页面"纳入缓存体系"。具体就是两件事：路由 meta 里开 keepAlive，组件 name 和路由 name 对得上。这两步做完，页面状态保持就生效了，根本不需要改框架源码。

当然，如果你遇到了"配置完还不生效"的情况，那多半是某个细节卡住了，后面我在第4章专门讲排查链路。

2. 让缓存真正生效的三个关键步骤

2.1 路由meta里开启keepAlive开关

首先打开你的路由配置文件，若依Vue3版一般在 src/router/index.ts 里。找到你要缓存的那个页面路由，在 meta 对象里加上 keepAlive: true。

比如"用户管理"页面的路由配置原本是这样：

{ path: 'user', component: () => import('@/views/system/user/index.vue'), name: 'User', meta: { title: '用户管理', icon: 'user' } }

改成：

{ path: 'user', component: () => import('@/views/system/user/index.vue'), name: 'User', meta: { title: '用户管理', icon: 'user', keepAlive: true } }

这里有个很容易忽略的点：keepAlive 这个字段必须是布尔值 true，而不是字符串 "true"。如果你在动态菜单里从后端返回 meta 配置，后端字段经常会把 true 变成字符串，就会导致判断失败，页面加了缓存开关但实际没进去。

另外注意，台架路由如果是嵌套的，你需要在真正渲染页面的那一级路由上配 keepAlive，而不是配在父级 Layout 上。若依后台中，Layout 作为父级路由永远不应该加 keepAlive，否则会影响所有子页面的渲染逻辑。

2.2 组件name必须和路由name保持一致

这是整个机制里最容易踩的坑。路由 meta 里加了 keepAlive 之后，tagsViewStore.addView 会把路由的 name 存进 cachedViews 数组。比如路由 name 是 'User'，cachedViews 里就会多一个字符串 'User'。

但 keep-alive 的 include 属性在做匹配时，比较的并不是前端路由的 name，而是组件实例内部的 name，也就是你在 Vue 组件里通过 name 选项注册的那个标识。很多新手在这里栽了跟头：路由 name 叫 'User'，组件里却忘了写 name，或者写成了 'user'、'UserManager'，include 匹配不上，缓存自然失效。

如果你用的是若依官方生成的页面模板，组件里通常长这样：

<script setup name="User"> import { listUser, getUserId } from '@/api/system/user' // ... </script>

在 script setup 语法下，直接在标签上写 name 属性，其实是依赖了若依工程里集成的 unplugin-vue-define-options 这类插件的能力。如果你自己新建页面，或者你的工程里没有这个插件，就必须用传统方式同时声明：

<script> export default { name: 'User' } </script> <script setup> // 你的逻辑 </script>

或者用 Vue3.3 之后的 defineOptions：

<script setup> defineOptions({ name: 'User' }) // 你的逻辑 </script>

不管你用哪种方式，结论都一样：组件内部声明的 name 字符串，要和路由配置里的 name 字符串完全一致，大小写、空格都不能差。

2.3 cachedViews数组的维护时机要心里有数

路由守卫 addView 的调用时机是"访问过才加入名单"，所以如果你的页面是从菜单里第一次点进去，它一定会被加进去。但有些情况下，页面还没访问过，你却期望它已经被缓存，这是不可能的。

正常流程是这样的：

1. 首次访问"用户管理"，permission.js 路由守卫执行 tagsViewStore.addView(to)，cachedViews 变成 ['User']。
2. 切到"角色管理"，Role 路由如果也配了 keepAlive，cachedViews 变成 ['User', 'Role']。
3. 再切回"用户管理"，include 命中 'User'，keep-alive 直接复用旧实例。
4. 如果你点击标签栏上的关闭按钮关掉"用户管理"，若依的 delView 方法会把该视图从 cachedViews 中移除，下次再打开这个页面就是全新实例。

第4点特别重要。很多人说"我明明配了缓存，为什么关闭tab再打开又重置了？"——因为关闭tab时清理缓存是若依框架的默认行为，这个不是bug，是设计。

另外我建议你不要手动去改 cachedViews 数组做增删，容易和标签栏的 visitedViews 状态不一致。后面第5章会讲怎么在业务代码里安全地清理某个页面的缓存。

3. 用生命周期钩子验证缓存是否生效

3.1 created、mounted、activated 的区别

配置完成后，怎么确认页面真的被缓存了？最直接的办法是看生命周期钩子的触发情况。

未开启缓存的组件，生命周期顺序是：

首次进入：created -> mounted 切走：unmounted / destroyed 再次进入：created -> mounted

开启了缓存的组件，生命周期顺序是：

首次进入：created -> mounted -> activated 切走：deactivated 再次进入：activated

看到了吗？区别非常明显：有缓存的情况下，切换tab时组件实例没有被销毁，只触发 deactivated 和 activated，created 和 mounted 只在第一次进入时触发一次。

这里有一个新手经常搞混的点：activated 在首次进入时也会触发。不是"激活了就等于切换回来了"，而是"从缓存中被重新激活"这个动作会触发 activated。首次进入时，组件挂载完成后紧接着也会激活一次，所以如果你在 activated 里写了请求逻辑，首次进入和后续切回都会执行。

3.2 在页面上加一行console.log做实测

我给你的验证方案很简单：在目标页面的 script 里加上几个生命周期钩子的打印，切换两次tab，看控制台输出。

以Vue3 + script setup 为例：

<script setup> import { onActivated, onDeactivated, onMounted } from 'vue' onMounted(() => { console.log('%c[User] mounted 执行了', 'color: green') }) onActivated(() => { console.log('%c[User] activated 执行了', 'color: orange') }) onDeactivated(() => { console.log('%c[User] deactivated 执行了', 'color: blue') }) </script>

保存后，打开"用户管理"页面，控制台会输出：

[User] mounted 执行了 [User] activated 执行了

然后切到其他tab再切回来，控制台只输出：

[User] deactivated 执行了 [User] activated 执行了

如果切回来时看到了 mounted 输出，说明组件被重新创建了，keep-alive没有命中你的页面，直接跳到第4章排查。

我用这个方案帮不止一个同事定位过问题，每次只需要30秒就能确认"有没有缓存生效"这一层，比看半天代码高效得多。

3.3 数据请求到底放哪个钩子

验证完缓存生效之后，你马上会面临一个新的问题：原本写在 created / mounted 里的请求，现在不会在每次切回时都执行了，列表数据可能会"过期"。这时候需要根据业务诉求，决定数据请求的放置位置。

我的经验是这样的：

• 如果你的诉求是保留列表状态，比如搜索条件、分页、已勾选项，那初始化数据请求就应该放在 created 里，只请求一次，切回时不刷新。
• 如果你的诉求是每次切回tab都要拿最新数据，比如待办数量、实时告警，那就要放到 activated 里。
• 如果你希望"切回时如果条件变了就刷新，没变就别动"，那就需要在 activated 里做条件判断。

一个常见的误区是：把所有页面的请求都从 created 挪到 activated，理由是"这样每次切回来都能刷新"。这其实就把缓存的意义抹掉了一半——组件实例是保留了，但数据每次都在重新请求，tab切换的流畅感没了，而且用户之前看到的搜索结果列表也会瞬间被新查询覆盖掉。

正确的姿势是区分数据性质。列表页的搜索参数属于"用户操作状态"，跟着组件走，放在 created 就行；如果有些数据必须保证实时，单独在 activated 里补一个轻量请求，比如刷新一下消息数量。没必要把所有东西都重新拉一遍。

如果你担心 activated 里重复触发导致首次进入请求两次，可以用一个 flag 或者判断已有数据来控制。下面是一个简单的示例：

let firstEnter = true onActivated(() => { if (firstEnter) { firstEnter = false return } // 这里是切回tab时需要执行的动作 fetchUnreadCount() })

这个写法我第一次用的时候也被惊艳到了，代码不复杂，但把"首次进入"和"切回进入"区分得明明白白，后面的人看到也不会误会。

4. 配了keepAlive还是不生效？排查链路在这里

4.1第一站：确认addView到底有没有把这个页面拉进缓存名单

如果你配置都做了，页面切走再切回来还是重新加载，第一步不是改代码，而是看看缓存名单里到底有没有这个页面的 name。

打开浏览器的开发者工具，在控制台里执行：

// Vue3 + Pinia 环境下 useTagsViewStore().cachedViews

如果是在组件内部，你也可以打印：

import useTagsViewStore from '@/store/modules/tagsView' const tagsViewStore = useTagsViewStore() console.log(tagsViewStore.cachedViews)

重点看数组里有没有你配了 keepAlive 的那个路由 name。如果没有，说明 addView 根本没把它加进去，或者 addView 执行时读取到的 meta 里没有 keepAlive 字段。

嗯，这一步定位了很多问题。比如有的页面是通过 keepalive 动态组件加载的，路由 meta 配置在父级路由上，子路由读取不到；还有的是在路由守卫里加了白名单，页面被 beforeEach 拦下来直接 next()，跳过了 addView。这些情况都会导致 cachedViews 里根本没有这个页面。

4.2 第二站：检查组件name和路由name是否真的完全一致

cachedViews 有你的页面，但 keep-alive 依然不生效，那十有八九是 include 匹配阶段出了问题。

打开目标 Vue 页面组件文件，看它声明的 name，然后和路由配置里的 name 对比。很多项目里路由 name 用的是大驼峰 'User'，组件 name 却因为复制粘贴写成了 'user' 或者 'User '（末尾多了个空格），或者干脆没有声明 name。

这里我提供一个快速自检清单：

• 组件里是否有 name 字段？script setup 下是否通过 defineOptions 或额外 script 声明？
• name 字符串是否和路由 name 完全匹配？大小写敏感吗？空格呢？
• 如果同一个组件被多个路由复用，这几个路由的 name 是否不同？

我见过最隐蔽的一个案例：组件 name 写的是中文，路由 name 是英文，两个放在一起根本看不出哪里不对，但缓存就是死活不生效。后来我在组件里打印 this.$options.name（Vue2）才发现组件 name 被自动推断成了文件名，而那个文件名恰好是中文拼音。所以用 defineOptions 显式声明 name，是避免这类玄学问题最稳的方式。

4.3 第三站：区分"切换tab"和"关闭tab再打开"两种操作

前面提到了，若依关闭标签页时会主动清理缓存，很多人排查问题时没有意识到这一点，把"关闭tab再打开"和"切换tab"混为一谈。

• 切换tab：从标签A切到标签B再切回A，此时A的缓存还在，应该复用实例。
• 关闭tab：在标签A上点右键选"关闭"，或者点标签上的x，此时A从 visitedViews 和 cachedViews 中都被移除，重新打开A会重建实例。

所以当你发现"页面数据丢了"，先确认是哪种操作：如果是关闭再打开，那数据丢失是正常行为；如果是单纯切换也丢失，再走前面的排查步骤。

如果你希望"关闭tab再打开"也能保留数据，那已经超出了 keep-alive 的职责范围，需要用 sessionStorage 或者 Pinia 把表单数据持久化，等页面重新创建后再回填。这个方案一般在列表页或表单页有"暂存"需求时才会用到，不要动不动就上。

另外，若依标签栏右键菜单里的"关闭其他"操作，默认会清掉当前激活页之外的所有缓存的标签，但如果某个标签设置了 affix: true（固定在标签栏），它在"关闭其他"时会被保留，同时它的缓存也会被保留。这个特性在业务上很实用，比如把工作台首页设为 affix，用"关闭其他"时首页不会被清掉。

4.4 动态菜单场景下容易踩的坑

如果你用的是若依的RBAC动态菜单，菜单路由通常不是写死在代码里的，而是用户登录后从后端拿到菜单列表，再通过 router.addRoute 动态挂载。这时路由的 meta 可能来自数据库或后端配置，问题就更容易出现了。

常见的坑是后端返回的菜单配置里没有 keepAlive 字段，或者返回的类型是字符串 "true" 而不是布尔值 true，导致 addView 判断失败。还有一种是后端配置的组件路径指向了某个组件文件，但这个组件文件里没有声明 name，导致 include 匹配时找不到同名组件。

我的处理方式是在前端做一层统一兜底：动态生成路由时，强制给每个路由的 meta 补默认值，把 keepAlive 字段规范成布尔类型。类似这样：

function createDynamicRoute(menu) { return { path: menu.path, name: menu.name, component: loadView(menu.component), meta: { title: menu.title, icon: menu.icon, keepAlive: menu.keepAlive === true || menu.keepAlive === 'true' } } }

这一层兜底解决了大部分"动态菜单缓存不生效"的问题。你在项目里如果遇到类似场景，可以照这个思路加一个 meta 格式化函数。

5. 进阶：按需缓存不同业务场景

5.1 列表页缓存，详情页不缓存

后台管理系统里最典型的组合是"列表页 + 编辑详情页"。列表页通常需要保留搜索条件和分页，所以建议开启缓存。编辑详情页则每次打开都要展示最新数据，而且同一个详情页可能被多条记录复用，开缓存反而容易显示脏数据，所以详情页不建议缓存。

具体配置就是：列表页路由 meta 加 keepAlive: true，详情页路由 meta 不加 keepAlive。这样从列表页进入详情页，切回列表页时列表状态保留；详情页每次打开都会重新走 created / mounted，拿到最新数据。

这里有一个细节：从详情页返回列表页时，列表页的 activated 会触发。如果详情页里修改了数据，返回列表时希望列表反映这个变化，你可以在列表页的 activated 里做一个标记判断，决定要不要刷新列表。示例：

let shouldRefresh = false // 详情页返回列表时可以通过一个标记让列表刷新 onActivated(() => { if (shouldRefresh) { fetchList() shouldRefresh = false } }) // 暴露一个方法给外部或事件总线调用 function markNeedRefresh() { shouldRefresh = true }

当然，如果你的业务要求"从详情返回列表必须刷新列表"，那直接每次在 activated 里 fetchList 也可以，只是要注意别让首次进入的重复请求影响体验。

5.2 同一组件多个参数，避免缓存串号

后台项目中经常出现这种情况：用户编辑页和新增页用的是同一个 Vue 组件，只是路由不同、传入的参数不同，比如 /system/user/edit/1 和 /system/user/edit/2。这两个路由都会渲染 UserEdit 组件，组件 name 都是 'UserEdit'。

按照 keep-alive 的匹配规则，cachedViews 里存的是 'UserEdit' 这个字符串，两个路由都能命中。匹配命中后，keep-alive 会按照 vnode 的 key 来决定是否复用同一个组件实例。在若依Vue3版的 AppMain 中，router-view 的 key 绑定的 route.path，也就是不同 path 会生成不同的 key，所以两个编辑页会各自缓存各自的实例，互不干扰。

但如果你把 AppMain 里的 key 改成了 route.name，或者没设置 key，问题就来了：两个不同路径共用一个组件实例，从编辑用户A切到编辑用户B，组件不会重新创建，A页面的参数可能串到B页面上。这种问题很难通过普通调试发现，因为 breakpoint 和 console 都看不到组件重建。

我的建议是：如果你遇到了"不同参数的编辑页互相串数据"这种诡异现象，先检查 router-view 的 key 是不是 route.path 或 route.fullPath，确保不同路由有不同 key。如果同一个 path 只是 query 参数不同（比如 /system/user/detail?id=1 和 /system/user/detail?id=2），path 相同，key 也相同，组件实例是同一个，这时你就不能用 keep-alive 来区分两个数据源了，必须靠组件内部监听 query 变化，比如 watch route 的 query 然后主动请求数据。

实操方案我建议：编辑详情这类"同一组件多实例"页面，宁可别用 keep-alive，或者把不同参数设计成不同子路由 path，让 key 天然区分。

5.3 主动控制缓存清理：按需失效而不必关闭标签

有些业务场景下，你希望页面缓存一直保留，但某一次操作之后缓存里的数据已经过期了，需要主动让它失效。最粗的方式是直接关掉这个tab，让用户重新打开，但这会影响用户的操作连续性和记忆。

更优雅一点的做法是在业务代码里主动从 cachedViews 中移除某个页面的缓存。这相当于告诉 keep-alive："这个组件以后别再复用了，下次进入请重新创建。" 但又不关闭标签页，用户看到的标签还在，下次点回来才会重建。

具体代码可以这样：

import useTagsViewStore from '@/store/modules/tagsView' const tagsViewStore = useTagsViewStore() // 清除某个路由对应的缓存 tagsViewStore.delCachedView({ name: 'User', path: '/system/user', meta: { title: '用户管理' } })

调用之后，cachedViews 里就没有 'User' 了，而标签栏里用户管理这个tab还在。下次用户从未被缓存的路径切回来时，组件会重新走 created / mounted，拿到的就是新数据。

我在实际项目里用这个方案处理过"操作完某些数据后，想让某个列表页自动刷新但不想关tab"的需求。比如在"用户管理"里把一个用户禁用了，希望列表页下次激活时能看到状态变化，就在数据更新成功后调一次 delCachedView，再配合列表页 activated 里的刷新逻辑，体验非常顺滑。

需要注意的是，delCachedView 只清缓存不清标签，和 delView（既清标签又清缓存）是两个不同层级的操作。用之前想清楚自己想清掉哪一层，不要搞混。

5.4 一个值得长期坚持的命名约定

页面缓存机制踩坑多了之后，我给自己定了一个约定，也推荐给你：所有需要缓存的页面组件，name 统一使用路由 name 的大驼峰写法，且在组件里显式声明，不依赖文件名自动推断。这样有两个好处：一是排查时拿着路由 name 去组件里搜，一搜一个准；二是避免 Vue 在特殊情况下对组件名的自动推断和路由配置产生不一致。

排查缓存问题时，最稳的路径是：先看 cachedViews 有没有这个页面 -> 再看组件 name 对不对得上 -> 再确认操作是切换还是关闭。按这个顺序走一遍，90%的问题都能在几分钟内定位。

回到开头那个"填了一半表单切出去回来就丢了"的场景，你现在应该明白：问题不在若依框架本身，而在你是否把这个页面正确地纳入了 keep-alive 的缓存名单。给路由加上 keepAlive，让组件 name 对得上，再按业务诉求决定数据请求放在哪个钩子，这套组合拳打下来，tab切换再也不会成为数据丢失的元凶。

最后多提一嘴，keep-alive 缓存本质上是拿内存换体验，缓存页面越多，占用的内存也越大。后台系统动辄几十个菜单，尽量不要无差别地给所有页面都开缓存，只给那些"用户会反复切换、且状态重建成本高"的页面开，比如列表查询页、多步骤表单页。这既是对用户体验负责，也是对服务器和浏览器内存负责。