Vue keep-alive生命周期详解：修复列表页状态丢失问题

如果你维护过稍微有点规模的中后台项目，大概率遇过这个场景：在列表页调好了筛选条件，往下翻了几页，点进一条数据查看详情，返回时整个列表被重置成初始状态，滚动位置回到顶部，刚才那堆筛选条件全白选了。这类问题在 Vue 里的标准解法就是 keep-alive 组件——它会把组件实例缓存起来，配合 activated 和 deactivated 这两个专属生命周期钩子，让页面切走之后还能原样回来。这篇文章就从生命周期钩子的角度，把 keep-alive 的运行机制、路由接入方式、常见坑和我实际踩过的雷一次讲清楚，适合正在用 Vue 2 / Vue 3 做中后台系统、想做页面状态保持但总被缓存问题困扰的同学。

我一直觉得，很多同学对 keep-alive 的认知停留在"给组件包一层就不会重新加载了"，但一旦遇到"为什么又缓存了""为什么我明明写了 include 还是不生效""为什么 activated 执行了两遍"这类问题就抓瞎。要真正用好它，必须从生命周期钩子的变化入手理解，而不是背配置。接下来我从一个最典型的痛点场景展开。

1. 为什么需要 keep-alive：一个返回页面就丢状态的经典场景

1.1 痛点案例：列表页筛选条件与滚动位置全部消失

先描述一个我做过无数次的项目场景。后台管理系统的订单列表页，顶部有三个筛选条件：订单状态、下单时间范围、关键词搜索框。用户选了"已发货"、时间范围选了最近七天、关键词输了一个订单号，然后翻到了第五页，看到一条感兴趣的订单，点进去看详情。看完了点返回，页面一下子就回到了第一页的初始状态，筛选条件全部清空，滚动位置也在顶部。

这个问题的本质是：在默认的路由切换机制下，离开列表页时组件实例被销毁了，组件内部所有本地状态随着内存释放一起没了。返回时 Vue 重新创建了一个全新的组件实例，重新走一遍数据请求，渲染出来的当然是最初始的状态。用户刚才辛辛苦苦调的筛选条件、翻的页码，全都没有被保存下来。

很多团队第一次遇到这个问题时，第一反应是"把筛选条件存到 Vuex / Pinia 里"。但存进去之后又发现，不仅仅是筛选条件，还有表格滚动位置、当前展开的行、临时勾选的数据、某个面板的开合状态……要存的东西越来越多，而且每一次都要小心翼翼地处理"什么时候存、什么时候恢复"的逻辑。做得久了，代码里全是状态恢复的补丁。其实这个问题的通用解法很简单：别让组件销毁，让它活着。

1.2 keep-alive 做的事：实例缓存而不是销毁重建

keep-alive 是 Vue 内置的一个抽象组件，它本身不会渲染任何额外的 DOM 节点，作用只有一个：把内部嵌套的组件实例缓存起来。当内部组件因为路由切换等原因要被"替换掉"时，keep-alive 会拦下这次销毁动作，转而把组件实例挂到内部一个隐藏的区域里；当组件再次被需要时，如果缓存命中，它直接把原来的实例和 DOM 拿回来重新渲染。

你可以把它类比成宿舍里的床位：普通模式下，你每次回来都要重新租一个房间、重新搬行李、重新布置；而 keep-alive 模式下，你的床位一直保留着，人出去一趟回来，铺位上东西都还在，坐下来就能继续干活。这个类比基本涵盖了 keep-alive 的核心价值——保留状态、避免重复渲染、省掉重复请求。

但这里必须说清楚：keep-alive 不是银弹。缓存意味着这些实例的内存不会释放，组件内部如果有定时器、WebSocket、全局事件监听，切走时不会自动清理，需要在合适的钩子里手动处理。这些细节我会在后面专门展开。先记住一句话：keep-alive 让你省去了"销毁重建"的代价，同时也把"管理组件副作用"的责任移交给了你。

2. activated 与 deactivated：缓存组件独有的两个钩子

2.1 首次进入时钩子顺序为什么不一样

普通组件从创建到显示，走的生命周期是：setup（或 Vue 2 的created）→mounted，之后数据更新触发beforeUpdate/updated，销毁时触发beforeUnmount/unmounted。

被 keep-alive 包裹的组件多了一对钩子：activated和deactivated。被缓存的组件首次挂载时，created/mounted会正常执行一遍，执行完mounted之后紧接着就执行activated。也就是说，一个页面第一次被打开时，mounted和activated都会触发。

activated为什么排在mounted后面？因为activated表达的是"组件已经进入活跃状态，可以开始工作了"。对 keep-alive 来说，只有确保组件真正渲染到界面上、DOM 挂载完成，才应该通知外部"它已经活了"。这个顺序在 Vue 2 和 Vue 3 里保持一致。

这里有一个非常容易踩的坑：首次进入时，mounted和activated都会执行。如果你把初始化逻辑同时写在两个钩子里，它就会被执行两次。我见过有人在mounted里初始化图表、在activated里也初始化一遍，结果图表第一次打开就闪了一下重新渲染。后面我会给出推荐的分工方式，先记住这个执行顺序：

首次打开缓存组件：created -> mounted -> activated

2.2 缓存命中后再进入：只有 activated 会触发

第二次以及以后进入这个页面时，组件实例已经被缓存，Vue 不会重新创建实例，也不会再走created/mounted。你唯一能感知到的钩子是activated。离开页面时，组件不会走beforeUnmount/unmounted，而是触发deactivated，实例进入休眠状态。

我用一张表把这个流程完整列出来，方便你对照排查：

这张表是我排查 keep-alive 问题时的基准。在代码里打日志，看到一组钩子执行顺序，就能立刻判断"这次进入是走了缓存还是全新创建"。比如你发现某个页面每次进入都有created日志，说明 keep-alive 根本没有缓存住它，应该去查 include 或 key 的问题。如果发现切走时走了unmounted，说明这个组件被淘汰了，或者它压根没被 keep-alive 接管。

2.3 Vue 3 组合式 API 中的 onActivated 与 onDeactivated

Vue 3 的组合式 API 提供了对应的钩子onActivated和onDeactivated，用法跟选项式的activated/deactivated几乎一样。唯一要注意的是：这两个函数必须在setup执行阶段同步注册，不能放到setInterval回调、异步方法或者条件分支里注册，否则注册不到当前组件实例上。

<script setup> import { onActivated, onDeactivated, ref } from 'vue' const pageNo = ref(1) onActivated(() => { console.log('页面重新激活，当前页码：', pageNo.value) }) onDeactivated(() => { console.log('页面切走，在这里清理定时器或事件监听') }) </script>

如果选项式和组合式同时写了这两个钩子，两者都会执行。正常项目里不会有人刻意混用，但如果你接手老代码时要意识到这一点，别看到一个activated还要再翻一遍<script setup>里有没有对应的onActivated。Vue 2.7 的<script setup>也支持onActivated，但 Vue 2 老项目里更常见的还是选项式写法，两种写法本质是同一套生命周期机制。

3. 路由场景下让 keep-alive 按需生效的完整写法

3.1 基础接入：router-view 外层包裹

最朴素的接入方式是把路由出口包进 keep-alive：

<template> <router-view v-slot="{ Component }"> <keep-alive> <component :is="Component" /> </keep-alive> </router-view> </template>

Vue 2 里更常见的写法是<keep-alive><router-view /></keep-alive>，这个写法在 Vue 3 里也能用，但如果你需要在 include 名单上做动态控制，推荐上面这种基于v-slot的写法，因为它把当前路由组件Component暴露出来，方便继续操作。

这里必须说一个原则：几乎不会有正经项目采用"所有页面全部缓存"的策略。全缓存会带来两个问题：一是随着项目页面增多，所有访问过的页面实例都被存在内存里，内存占用不停上涨；二是像登录页、404 页、实时数据大屏这类页面，缓存反而会产生错误行为——大屏每次进入应该拉最新数据，结果你拿到的是几个小时后之前的数据。所以，按需缓存几乎是唯一合理的选择。

3.2 include/exclude 控制缓存名单

keep-alive 提供了include和exclude两个 prop，用来控制哪些组件可以被缓存、哪些绝对不能缓存。它们可以接收字符串、正则表达式，在 Vue 3 里也可以传数组。

<keep-alive :include="['ListPage', 'DetailPage']"> <component :is="Component" /> </keep-alive>

使用 include / exclude 时最大的坑是：匹配的是组件的 name，而不是路由的 name。很多同学在路由配置里写了name: 'list'，然后在 include 里也写'list'，结果发现缓存死活不生效。原因在于 keep-alive 内部判断的是组件实例上的name字段，跟路由配置里的 name 是两套东西。

如果你在 Vue 3 里使用<script setup>，组件默认不会自动生成 name 字段，必须用defineOptions显式声明：

<script setup> defineOptions({ name: 'ListPage' }) </script>

如果是选项式组件，name就是组件选项里那个name。写 include 之前先确认目标组件的 name 是什么，用defineOptions声明过才算数，这是 keep-alive 接入时最容易忽略的一步。

3.3 用路由 meta 动态管理缓存视图

中后台项目最推荐的缓存管理方式是：在路由表里配置 meta 标记，再根据路由动态生成 include 数组。这样哪些页面要缓存、哪些不要缓存，都集中在路由配置里管理，而不是散落在组件代码中。

路由配置：

{ path: '/list', name: 'list', component: () => import('@/views/ListPage.vue'), meta: { keepAlive: true } }

布局组件里的实际包裹方式：

<template> <router-view v-slot="{ Component, route }"> <keep-alive :include="cachedViews"> <component :is="Component" :key="route.path" /> </keep-alive> </router-view> </template>

import { computed } from 'vue' import { useRoute } from 'vue-router' const route = useRoute() // 实际项目中这个数组往往由路由配置统一生成，这里示意一个静态数组 const cachedViews = computed(() => ['ListPage'])

include 数组是响应式的，keep-alive 会根据名单变化动态新增或淘汰缓存。比如某个页面原本标记了需要缓存，后来因为业务调整把 meta.keepAlive 改成了 false，对应组件就会在名单移除后被真正销毁并触发 unmounted。这个特性可以用来处理"页面从缓存状态恢复到常规状态"的需求。

这里我再补一个细节：:key="route.path"的作用是区分同一个组件在不同路由路径下的实例。后面会讲到多实例场景，key 是 keep-alive 正确工作的关键一环，先记住这个写法。

4. 缓存带来的"数据残留"陷阱与多实例场景区分

4.1 activated 不是 mounted：别在钩子里做一次性初始化

我见过的最典型错误：把"初始化图表对象""注册 window resize 事件""获取基础字典配置"这类逻辑写进activated。结果每次从缓存切回来，图表重新初始化一遍、事件监听重复注册一份，表现就是页面越来越卡、图表闪烁、resize 被触发多次。这是对生命周期语义理解不透彻造成的。

正确的认知是：created/mounted是这个组件实例一生只执行一次的地方，适合放一次性初始化；activated是每次进入都会执行的钩子，适合放"每次回到这个页面都需要刷新一遍"的逻辑。

如果你确实是"首次进入时初始化，后续进入时跳过初始化"的需求，可以加一个标志位：

let initialized = false onActivated(() => { if (!initialized) { initChart() initialized = true } fetchListData() })

这比把所有初始化都放进 activated 可靠得多。实际项目里我还见过一种衍生问题：组件被缓存后，activated里的逻辑如果在切走前异步执行了一半，切回来时会出现"上一次请求和这一次请求同时返回、数据互相覆盖"的情况。我习惯在请求函数里加一个"当前请求唯一性"判断，或者干脆用 AbortController 在 deactivated 时取消未完成的请求，这个处理对体验提升很明显。

4.2 多标签页场景下如何区分触发的是哪个实例

中后台管理系统经常做多标签页（Tab）效果：用户每打开一个路由页面对应一个 Tab，组件被切走时缓存，切回来时保留原样。当多个 Tab 同时存在时，activated会在每次标签切换时触发，但它不告诉你是哪个实例被激活了。比如列表页和详情页都开了，切换两个 Tab，两个组件的activated都会各自触发，这是正常的，因为每个缓存组件实例在激活时都会执行自己的activated。

但有一个容易混淆的场景：同一个组件被实例化了多份，比如"用户详情"组件被两个不同用户的 Tab 同时打开。这时候两个实例的activated都会触发，你需要一个方法来区分当前是哪个实例。最常用的是读取当前路由信息来判断：

import { useRoute } from 'vue-router' onActivated(() => { const route = useRoute() if (route.params.id === '1001') { // 当前激活的是用户 1001 的详情 } })

如果同一个路由组件要支持并行多个不同参数的实例，就必须给组件设置不同的 key。比如：

<component :is="Component" :key="route.fullPath" />

直接用route.fullPath作为 key，同一个路由不同 query 参数会被当成不同实例缓存。如果只用一个固定 key 或者不加 key，两个用户的详情会互相覆盖数据，这是多标签页项目里非常经典的坑。

4.3 嵌套路由中 keep-alive 的命中问题

嵌套路由在真实项目里非常常见：一个布局组件下挂着多个子路由页面，子页面往往有自己的筛选和滚动位置。如果你把 keep-alive 直接包在父布局的外层，会碰到一个诡异的现象：整个 Layout 被缓存了，但 Layout 内部的子路由视图并没有独立的缓存，切出去再切回来时，Layout 的 activated 触发了，子页面却显示的还是旧状态，甚至内部一些依赖路由参数的逻辑没有重新计算。

这种问题出现的原因在于：keep-alive 缓存的最小单位是组件实例，而嵌套路由下"父组件 + 子组件"是组合在一起的。父组件被缓存时，子路由视图是由父组件内部的<router-view>渲染出来的，它并不直接归属于外层的 keep-alive 管理。

我的实践经验是：遇到嵌套路由，先画清楚"谁被缓存、谁在切换、谁要状态保持"的关系。通常更合理的安排是，keep-alive 只包在最内层真正的页面组件上，布局组件不做整层缓存。如果你确实需要整体缓存，也要明确子页面依赖的响应式数据是否能在 activated 触发后正确刷新。调试时最直接的方式是在每个候选组件的 activated / deactivated 里打日志，看看到底谁触发了、谁没有触发，比对着代码猜快得多。

5. 缓存页面如何拿到最新数据：刷新策略与钩子分工

5.1 activated 里拉数据：代价与正确姿势

缓存让列表状态保持了，但紧接着会有新问题：切回来时数据还是旧的。比如列表页缓存了，但另一个页面改了订单状态，回到列表应该看到最新数据。如果只在mounted里请求过一次，缓存复用时不会走 mounted，列表永远不会更新。

最直接的做法是把请求动作从mounted挪到activated。这样每次进入缓存页面都会重新请求，数据保持新鲜。代价是：缓存只省了"渲染和状态保持"的成本，没有省网络请求成本——每次进页面照样打接口。

如果数据实时性没那么强，可以用"缓存过期时间"来折中：记录上次请求时间，activated时判断是否超过规定时长，超时才重新请求：

const lastFetchTime = ref(0) const listData = ref([]) async function fetchList(force = false) { const now = Date.now() if (!force && now - lastFetchTime.value < 60 * 1000) return listData.value = await getListApi() lastFetchTime.value = now } onMounted(() => fetchList(true)) onActivated(() => fetchList())

这个 60 秒的阈值完全按业务场景定，有些页面 30 秒就要最新数据，有些页面 5 分钟不刷新也没关系。这个模式特别适合列表详情这种"状态要保持、数据要新鲜"的典型场景。

5.2 beforeRouteEnter 与 activated 的分工

很多同学分不清beforeRouteEnter和activated的区别。beforeRouteEnter是路由守卫，发生在导航确认前、组件实例尚未创建时。因此在这个钩子里拿不到this，也不能直接操作组件数据。你可以在里面做权限校验、页面访问拦截，或者通过next(vm => ...)拿到实例再做一些初始化操作。

activated是组件实例的钩子，发生在组件创建完成或者已经从缓存中恢复之后，可以安全地访问响应式数据、调用方法、发起请求。在业务上我做这样的分工：需要拦截导航的，放beforeRouteEnter；需要刷新数据的，放activated。两者可以同时存在，执行顺序是beforeRouteEnter先于activated。

一个实际建议：如果只是"回来刷新数据"这个需求，没必要把请求写到beforeRouteEnter里，直接写activated更干净。beforeRouteEnter适合做带"这次导航是否放行"语义的事情，而activated适合做"页面已经可见，我把数据搞新"的事情。很多项目把请求逻辑硬塞进beforeRouteEnter，写下来代码绕来绕去，其实没有必要。

5.3 watch 监听 + activated 混合使用的经验

keep-alive 缓存实例里，watch依然正常工作。比如页面依赖某个全局 store 里的状态，切回页面时 store 已经更新，watch就会触发。如果你同时又在activated里发起一次同样的请求，就可能出现同一份数据请求两遍的尴尬。

我的处理原则是：同一类数据更新只交给一个触发源。"每次进入页面都必须刷新"的数据，用activated控制；"依赖外部状态变化而更新"的数据，用watch控制。如果确实两个触发源都会碰到同一个数据刷新逻辑，就把刷新函数抽出来共用，并且加一个简单的请求中标记，避免并发重复请求。

还有一个很容易被忽略的坑：组件被缓存后，切走时不会触发unmounted，如果你把事件监听、定时器的清理写在unmounted里，它可能一直不会执行。正确做法是把这些清理动作放到onDeactivated里。这一点对 keep-alive 场景下的内存管理非常重要，我排查过的几个线上卡顿问题，最后都定位到某个页面缓存后定时器还在无限运行。

6. 什么时候不该用 keep-alive：内存与性能权衡

6.1 缓存会放大什么成本

keep-alive 缓存的是整个组件实例，包括响应式数据、虚拟节点和真实 DOM 节点。列表页里有几千行表格数据、大图预览、长列表的话，这些内容都会被存在内存里。缓存五到十个这样的页面，内存占用可能轻松超过一两百 MB，在内存受限的设备上体感非常明显。

所以用 keep-alive 前必须想清楚：这个页面真的值得缓存吗？判断标准是"用户离开这个页面再回来，是否需要保持原样"。带有筛选条件、分页和滚动位置的列表，编辑到一半的表单，值得缓存；实时监控大屏、一次性报表、异常页、404 页，不值得缓存。

我还见过一种"缓存放肆"的项目：为了省事，把所有页面都丢进 keep-alive，结果页面越开越多，缓存越来越多，最后出现各种内存问题和状态残留问题。这种问题排查起来非常痛苦，因为看起来每个页面都正常，但整体上项目越来越卡。所以我在项目里一直强调：缓存名单要经过设计，不是所有页面都要缓存。

6.2 max 限制与淘汰策略

keep-alive 提供了max属性，限制最多缓存多少个实例：

<keep-alive :max="10"> <component :is="Component" /> </keep-alive>

超过上限时，最久没有被访问的缓存实例会被淘汰。被淘汰的组件会真正卸载，走beforeUnmount/unmounted。这个行为和浏览器的 LRU 缓存机制类似。如果你把某个页面视为"必须始终在缓存里"，但 max 设得太小，它在中途被挤出去了，下次进入时会重新创建，状态也就丢了。

项目里我一般把 max 设为需要缓存页面的数量再加上一两页余量，而不是随便写个很大的数。更重要的是，一旦你意识到"缓存可能被淘汰"，所有依赖"这个实例一定存在"的代码都要谨慎。这就是为什么前面反复强调activated里的刷新逻辑要兜底——哪怕组件真的被重新创建了，activated依然会触发，数据逻辑不会断。

6.3 排查 keep-alive 失效的常用思路

最后分享一套我排查 keep-alive 问题的固定流程，遇到"怎么不缓存了""怎么状态丢了"之类的问题，可以直接照着查：

1. 先确认目标组件有没有被 keep-alive 实际包住。在组件里打console.log('activated')，切走再切回，看钩子是否触发。没触发说明组件根本不在 keep-alive 的管理范围。
2. 检查 include / exclude 是否匹配到正确的组件 name。用defineOptions显式声明 name 是最稳妥的做法，别依赖任何自动推断。
3. 检查组件外层是否有 v-if / v-for / :key 在变化。key 一旦变化，Vue 会认为这是一个不同的节点，keep-alive 的缓存失效，组件走重建流程。
4. 检查是否存在多个 keep-alive 互相嵌套、组件被包在错误层级的情况。画出"谁负责接管这个组件实例"的关系图，比盲目加 include 有效得多。
5. 检查淘汰策略：max 是否够用、有没有动态修改 include 导致缓存被主动丢弃。

我用了很多年这套流程，基本覆盖了日常工作中九成的 keep-alive 异常。剩下的情况大多是缓存实例内部某个副作用没清理干净导致的表现异常，比如定时器、事件监听、全局状态残留，这种只能通过 review 组件内部的资源和事件管理来定位。

最后再分享一个我个人坚持的小习惯：在接入 keep-alive 之前，先画一张简单的页面流转图，把需要缓存、不需要缓存、每次进入需要刷新的页面分别标出来，再设计 include 名单。这个动作看起来要多花十分钟，但项目逐渐变大之后，你会感谢当初这张图帮你避免了一堆"这个页面到底该不该缓存"的反复争论。这也是我做中后台项目这些年里，最想推荐给后来者的一条实战经验。