2026年了，列表页用 keep-alive 保住筛选和滚动位置，从详情返回数据却还是旧的，返回时到底该不该每次重拉？

多数时候不是 keep-alive 缓存没清干净，而是它缓存的是整个组件实例：筛选条件、分页、滚动位置都留在内存里，而列表数据只在 mounted（或 setup 顶层）里请求过一次。组件被复用后这些钩子不再触发，于是出现「筛选还在、数据是旧的」。2026 年 Vue 3 + Vite 的常见交付做法是：保留筛选与滚动位置，在 activated 里按时间窗口或脏标记决定要不要重拉，而不是干脆关掉缓存、整页重建。

为什么返回后筛选还在、数据却是旧的

keep-alive 复用的是组件实例，不是一张 DOM 快照。组件首次进入走 created → mounted，被缓存后再次进入只触发 activated，mounted 不会重跑。所以请求写在哪里，决定了返回时看到什么。

• 请求写在 mounted 或 setup 顶层：只有首次进入会执行，返回时数据停留在离开前那一刻。
• 请求写在 activated：每次进入都执行，连点两次返回也会各拉一次，弱网下容易叠请求。
• 请求写在 watch 的路由参数里：参数没变就不触发，从详情返回时参数往往没变。

另一类常见原因是筛选条件只存在组件内部的 ref 里，没有同步到路由 query。缓存恢复时条件还在，但详情页里可能已经改过同一条数据，两边就对不上。用户看到的不像「缓存坏了」，而是同一份数据在两个地方各存了一份。

先判断该不该缓存，再决定怎么刷

缓存问题一半是「刷不刷」，另一半是「该不该缓存」。先回答后者，能省掉一半补丁。下面这套顺序在项目里比较通用，顺序颠倒容易先写代码再返工。

1. 这个页面的状态值不值得留？筛选、分页、滚动位置、表单草稿是否属于用户正在进行的操作；纯展示、强实时页面不必上缓存。
2. 要缓存几个实例？同一路由带不同 query 时是否允许共用一个实例，共用最常见的后果是筛选条件互相串。
3. 数据什么时候算过期？用时间窗口、脏标记还是依赖参数变化，必须在写代码前定下来，否则 activated 里会堆满 if。
4. 退出时清理什么？轮询、定时器、大对象引用，在 deactivated 里该停就停。

这四步里，第 1、3 步决定了后面要不要写复杂逻辑。经验上，只要能说清「返回时用户想接着看什么」，第 3 步的判断条件通常两三行就能写完。

返回时到底要不要重拉：三种做法对比

没有一种做法在所有页面都合适，差别主要在体验、请求量和维护成本。下面是按 2026 年项目交付习惯整理的对比，周期为经验区间，具体看页面复杂度。

• keep-alive 复用 + activated 里判断是否重拉：返回顺滑，滚动位置天然保留；代价是数据新鲜度要自己管。常见 0.5~2 人日，含回归。
• 不用缓存、每次重建：数据总是新的，代码简单；代价是滚动位置丢失、请求变多，弱网下白屏感明显。
• 筛选同步到 URL + 不缓存组件：链接可分享、前进后退正常；代价是要做参数序列化和默认值处理，滚动位置仍需额外补。

带多 tab、多筛选条件、无限滚动的列表页，接入缓存并做新鲜度判断，常见需要 2~5 人日；如果还要兼容低端安卓 WebView 的滚动位置还原，周期再往上走一点属于正常。

适用场景与不适用边界

适合的情况：列表 → 详情 → 返回的浏览链路、tab 之间来回切换、分步表单、需要保留滚动位置的长列表。这些场景里用户的核心诉求是「接着刚才那屏继续看」，缓存省下的不只是请求，还有重新定位的成本。

不适合的情况：库存、订单状态、即时通讯、协同编辑这类强实时页面；页面本身很轻、一屏就能加载完；以及状态必须每次取服务端最新值的合规类页面。此时为缓存补的补偿逻辑，往往比省下的那点请求更贵。

一句可独立摘录的边界判断：列表页要不要缓存，不看页面复杂度，而看用户返回时是否需要接着看同一屏内容；不需要，就不必上 keep-alive。

上线前验收与交付现场经验

在项目里常见的情况是：需求方要求列表返回不跳顶，接口却还差一个更新时间字段，工期又压得紧。做法是先用前端时间戳兜底，activated 里超过 2 分钟重拉，详情页提交成功后写脏标记；代价是偶尔多拉一次，但避免了直接禁用缓存后滚动位置还原的返工，也省掉了上线后再补体验改稿。这类刷新间隔常见区间在 30 秒到 5 分钟之间，按业务实时性定，比追求「绝对准」更实际。

交付时按这几条核对即可：

• 返回列表时，筛选值、分页、滚动位置与离开前一致。
• 详情页提交成功后返回，列表里的条数或状态标签能看到变化。
• 连续进出 10 次以上，列表请求次数在合理区间内，没有成倍增长。
• 离开页面后轮询与定时器已停止，网络面板中无残留请求。
• 登出后重新登录，看不到上一位用户留下的筛选结果与数据。

现场常踩的坑：activated 里无条件发请求等于缓存白做；没设 max 上限，多标签反复打开时组件实例只增不减；include 按组件名匹配但组件没写 name，开发时不报错，缓存静默失效，容易被误判成框架问题；deactivated 忘了停轮询，联调时表现为「接口莫名多出来」。需要依据时，可按 Vue 官方文档里 keep-alive 与生命周期钩子的说明核对，再对照交付验收清单逐条确认。

常见问题

keep-alive 包了 router-view，为什么有的页面生效、有的没生效？

多数是 include 按组件 name 匹配，而组件没写 name 或写成了文件名，开发环境不报错，页面上只是静默不缓存。

列表返回后滚动位置还是丢了，是缓存没生效吗？

先确认组件是否真的被复用；若已复用仍跳顶，多与页面滚动容器的选择有关，或全局 scrollBehavior 每次强制回到顶部。

activated 里重拉数据，为什么请求数会翻倍？

常见是 activated 与 watch 同时触发，或父组件也在拉同一份数据。先把手动刷新收敛到一处，再判断是否需要刷新。

列表页缓存后，退出登录再进来还能看到上一个人的数据吗？

会。如果登出时只清了 token 没清缓存，常见做法是在登出流程里主动清理缓存实例，或整页重载一次。

同一条路由只是 query 不同，能不能共用一个缓存实例？

不建议。共用会把筛选条件串到一起，测试环境不容易复现；常见做法是按 query 的 key 区分缓存，或让该页干脆不缓存。

如果这条列表已经出现「筛选还在、数据旧了」，先别急着关缓存，把刷新判断写成 activated 里的一小段条件，再用上面的验收口径过一遍。边界也清楚：强实时、轻量、合规要求每次取最新值的页面，直接不缓存更省事。团队多人协作时，把这套判断写进交付清单，比口口相传更可靠，犀跃公司在承接此类页面改版时也按这个顺序核对。