文章目录0. 一个真实场景三个标签三种状态1. 为什么单靠 keep-alive 不够1.1 keep-alive 的缓存粒度是「组件」不是「页面实例」1.2 常见方案对比2. 设计目标与非目标3. 数据模型Tab 与 Page 是一对多4. 让 keep-alive 按「页面实例」缓存4.1 思路4.2 关键实现4.3 一个必须注意的坑包装组件必须是 keep-alive 的直接子节点4.4 代价5. 栈式导航forward / backward 与 __tab5.1 forward先压栈再导航5.2 backward必须先导航再驱逐5.3 __tab 到底在做什么5.4 浏览器原生后退怎么办6. 缓存驱逐为什么不能路由一变就删7. 刷新活动页和非活动页走两条路8. 刷新恢复当前版本的契约与边界8.1 当前版本恢复什么8.2 如果要完整对标业务系统应该怎么改8.3 另一个改进方向让 __tab 更稳定9. iframe 标签什么时候该用真隔离9.1 懒加载9.2 刷新策略分两种9.3 加载超时与错误占位9.4 安全默认值10. 踩坑清单11. 最小接入11.1 路由11.2 Layout11.3 打开标签与标签内导航11.4 版本前提12. 工程化与真实数据13. 适合谁不适合谁14. 小结admin 模板里的 tags-view本质是「组件名 一个 keep-alive」。它能让页面不丢状态但同一路由多开只能共享一个实例标签内也没有独立的前进/后退栈。本文拆解一个基于 Vue Router 的页面级缓存方案用 UUID 作为每个页面实例的缓存身份用StackPage维护标签内导航用 URL 上的__tab保证刷新和分享后仍能恢复归属并如实讨论这套设计的边界与代价。在线演示https://jktantan.github.io/vue-stack-tabs/demo.html源码https://github.com/jktantan/vue-stack-tabs0. 一个真实场景三个标签三种状态先不聊 API想象一个订单后台用户在订单列表勾选订单 A打开详情停留在「售后记录」Tab回到列表又打开订单 B 的详情停留在「物流信息」Tab从订单 B 的详情点进物流详情页再点页面里的「返回」期望回到订单 B 的详情而不是订单列表。这三个动作对应三个很具体的要求同一路由可以多开/order/1和/order/2同时存在筛选条件、表单草稿、滚动位置互不影响每个标签有独立的导航栈订单 B 标签里是「详情 → 物流」订单 A 标签里可能还停在「详情」刷新后现场还在按 F5 之后标签、栈、当前页都还能恢复。大多数 admin 模板的 tags-view第一条就做不到。1. 为什么单靠 keep-alive 不够1.1 keep-alive 的缓存粒度是「组件」不是「页面实例」典型的 tags-view 实现长这样router-view v-slot{ Component } keep-alive :includecachedViews component :isComponent :key$route.fullPath / /keep-alive /router-viewcachedViews里存的是组件 name而keep-alive的include匹配的也是组件 name。问题在于/order/1和/order/2渲染的是同一个OrderDetail组件name 一样。于是include里只有一个OrderDetailkeep-alive 只保留一份实例从 A 切到 B组件被复用onActivated里重新取数A 的表单状态、滚动位置就没了。有人会在:key上用$route.fullPath强制区分。但keep-alive的缓存 key 仍然是组件 name:key只能让组件重建不能让它同时保留两份实例。这是缓存维度的限制不是配置问题。1.2 常见方案对比方案缓存粒度同路由多开标签内导航栈刷新恢复主要代价单 keep-alive 路由 name组件级不支持互相覆盖无依赖 URL无法保留多实例admin 模板 tags-view组件级不支持无部分同上一个标签一个 iframe页面级支持浏览器历史支持通信、样式、内存、路由都要另做一套本文方案页面实例级支持每标签独立栈__tab session侵入性较强URL 带参数iframe 的隔离是真的独立 JS 上下文、独立 CSS、独立路由一个页面崩了不影响别的标签。但代价也真实父子通信要自己做、弹窗/下载/登录态要处理、内存占用高、标签切换有白屏感。如果页面都是同源 Vue 页面用 iframe 属于用重型隔离换一个本来可以靠作用域解决的问题。本文的方案走中间路线仍然是同一个 Vue 应用、同一个路由但把 keep-alive 的缓存单位从「组件」下沉到「页面实例」。2. 设计目标与非目标先把边界说清楚后面的取舍才站得住。目标每个标签拥有独立的页面实例和页面栈标签内支持forward/backward行为接近浏览器历史刷新、复制链接、新窗口打开后能知道当前页面属于哪个标签支持 iframe 标签作为老系统渐进式接入的过渡方案滚动位置、标签增删、批量关闭、右键菜单等后台系统常规能力可用。非目标不做安全隔离。同一 JS 上下文里的「作用域隔离」不等于 iframe 的安全隔离全局变量污染、未捕获异常仍然会影响整个应用不支持一个 Vue app 里多个VueStackTabs实例。业务系统通常只有一个主框架多实例会让路由同步、session 隔离、__tab协议的复杂度成倍上升不承诺刷新后保留组件内部状态。keep-alive 不跨刷新表单草稿这类状态需要业务自己持久化。还有一个容易被误解的点__tab为什么不放到内存里因为它承担的不是「运行时优化」而是「刷新/分享/新窗口时的归属契约」。没有它URL 只剩一个path当两个标签都停在同一路径时浏览器刷新后无法判断当前页面属于哪个标签。sessionStorage只能救当前窗口的刷新救不了复制链接和新窗口。对业务系统来说URL 可恢复性比 URL 干净更重要。3. 数据模型Tab 与 Page 是一对多核心模型只有三层interfaceITabItem{id:stringtitle:stringclosable:booleanrefreshable:booleaniframe:booleanactive:booleanpages:StackITabPage// 标签内的页面栈}interfaceITabPage{id:string// UUID同时是 keep-alive 的 cacheNametabId:stringpath:stringquery?:LocationQueryRaw refreshVersion?:number}Tab 是业务概念用户看到的那一条标签Page 是缓存身份栈里的每一页拥有全局唯一的 UUID栈顶是当前显示页forward入栈backward出栈。Tab ├─ id / title / closable / pinned └─ pages: StackPage ├─ Page { id: UUID, path, query } ← 栈顶当前显示 ├─ Page { id: UUID, path, query } └─ Page { id: UUID, path, query }这个拆分是后面所有机制的基础标签可以切换页面可以出栈但每个页面的缓存身份始终稳定。4. 让 keep-alive 按「页面实例」缓存4.1 思路既然include匹配组件 name那就给每个页面实例造一个唯一的组件 name页面入栈时生成 UUIDcacheName动态defineComponent({ name: cacheName })包一层把这个cacheName放进caches作为include列表component :keyactiveCacheKey切到对应的包装组件。这样/order/1和/order/2虽然内部渲染的是同一个OrderDetail但外层包装组件的 name 不同keep-alive 会为它们保留两份实例。4.2 关键实现包装组件工厂的骨架src/lib/hooks/tabPanel/pageComponentFactory.tsx有删减const cacheComponent defineComponent{ vnode?: VNode }({ name: cacheName, // ← 关键keep-alive 的 include 按这个 name 匹配 props: { vnode: { type: Object as PropTypeVNode, default: undefined } }, setup(props, context) { const lastCloned shallowRefVNode | null(null) onMounted(() { context.emit(onLoaded) addPageScroller(cacheName, #W-${cacheName}) }) onDeactivated(() saveScroller(cacheName)) onActivated(() { context.emit(onLoaded) restoreScroller(cacheName) evictMarkedCaches() // 统一在这里清理待驱逐缓存 }) return () { lastCloned.value props.vnode ? cloneVNode(props.vnode, { tId: tabInfo.id, pId: cacheName, ...(backParams ? { _back: backParams } : {}) }) : null return ( div id{W-${cacheName}} classstack-tab__cache-page-wrapper styleheight: 100% {lastCloned.value} PageLoading tabId{tabInfo.id!} / /div ) } } })对应的模板结构StackKeepAlive.vuerouter-view v-slot{ Component, route } StackCacheRenderer v-slot{ wrappedComponent, activeCacheKey, activePageRefreshVersion, component } :routeroute :componentComponent transition namestack-tab-swap appear modeout-in keep-alive :includecaches component :iswrappedComponent :key${activeCacheKey}-${activePageRefreshVersion} :vnodecomponent / /keep-alive /transition /StackCacheRenderer /router-view4.3 一个必须注意的坑包装组件必须是 keep-alive 的直接子节点如果为了代码整洁在keep-alive和动态组件之间再包一层普通组件keep-alive :includecaches MyWrapper component :iswrappedComponent / /MyWrapper /keep-aliveinclude匹配到的会是MyWrapper的 name而不是页面包装组件的 name缓存直接失效。所以这里没有用「包一层」的写法而是用StackCacheRenderer的scoped slot把解析结果暴露给父级保证真正的缓存页仍然是keep-alive的直接子节点。这段设计在源码注释里写得很直白属于踩过一次就不想再踩的坑。4.4 代价每个页面多一层包装组件DOM 上多一个容器divcacheName必须全局唯一否则两个页面会抢同一份缓存caches是一个需要手动维护的include列表增删时机必须和页面栈严格一致包装组件内部通过cloneVNode注入tId/pId/_back页面组件需要知道这些约定。5. 栈式导航forward / backward 与__tab5.1 forward先压栈再导航constforward(to:RouteLocationPathRaw){constquerydefu(to.query,{__tab:tabInfo})consttransactionVersionnavigationVersionletoptimisticPageIdrunNavigationTransaction({apply:(){constsnapshottab?getPageSnapshot(tab.id):[]if(tab){optimisticPageIdcreatePageId()appendPage(tab.id,{id:optimisticPageId,tabId:tab.id,path:to.path,query:cloneLocationQuery(to.query)})}returnsnapshot},navigate:()router.push({path:to.path,query}),rollback:(snapshot){if(tab)replacePages(tab.id,snapshot)},isFailureResult:isNavigationFailure,isCurrent:()navigationVersiontransactionVersion,cleanupStale:(){if(!tab||!optimisticPageId)returnreplacePages(tab.id,getPages(tab.id).filter((page)page.id!optimisticPageId))}})}注意两件事先压栈再router.push。这样router-view重新渲染时updatePageState能直接在栈顶找到刚创建的 page复用它的cacheName导航失败要回滚。路由守卫拒绝、重复导航、快速连续点击都可能让router.push失败如果不回滚栈里会留下一个永远渲染不出来的「幽灵页」。5.2 backward必须先导航再驱逐constrecyclingBinpopPages(tab.id,steps).map((page)page.id)consttargetgetTopPage(tab.id)runNavigationTransaction({apply:()originalPages,navigate:()router.push({path:target.path,query:targetQueryWithTab}),rollback:(snapshot)replacePages(tab.id,snapshot),isFailureResult:isNavigationFailure,isCurrent:()navigationVersiontransactionVersion,commit:(){for(constidofrecyclingBin)evictPageCache(id)},cleanupStale:(){constactivePageIdsnewSet(getPages(tab.id).map((page)page.id))for(constidofrecyclingBin){if(!activePageIds.has(id))evictPageCache(id)}}})这里最容易写错的是顺序先把页面从栈里弹出但不能立刻销毁缓存要等路由导航成功后再驱逐。原因很直接router.push之后页面的卸载/激活是异步的。如果导航被守卫取消或者用户快速连点导致前一次导航过期提前销毁缓存会让界面停在白屏或旧页面上。所以这里把「弹出的页面」先放进recyclingBin导航成功才真正evictPageCache。5.3__tab到底在做什么每次打开标签、切换标签、forward都会把标签的元信息编码进 URLexportconstencodeTabInfo(tabData:ITabBase):string{constpayload{version:1,id:tabData.id,title:tabData.title,iframe:tabData.iframe,closable:tabData.closable,refreshable:tabData.refreshable,iframeRefreshMode:tabData.iframeRefreshModereload?reload:postMessage}returnencodeBase64(JSON.stringify(payload))}URL 变成这样/order/1?__tabeyJ2ZXJzaW9uIjoxLCJpZCI6...它解决三件事路由归属页面渲染时updatePageState解析__tab知道这次渲染属于哪个标签、哪个页面刷新恢复浏览器刷新后URL 还在标签身份就还在分享/新窗口复制链接给别人对方打开时能落到同一个标签语义里。首屏 URL 通常没有__tab所以初始化时会用router.replace把当前标签编码写回地址而不是push——避免用户刚进系统就多一条历史记录。if(typeofroute.query.__tab!string){voidrouter.replace({path:route.path,query:{...cloneLocationQuery(route.query),__tab:encodeTabInfo(tabInfo)},hash:route.hash})}5.4 浏览器原生后退怎么办用户点浏览器的后退按钮时不会经过backward()路由会直接变化。当前实现会在updatePageState里做一次「栈修复」如果新路径等于栈顶复用如果新路径在栈的中间弹出中间的页面并标记驱逐把栈顶修回目标页如果找不到才创建新页面。这就是为什么updatePageState里有一段从pages.length - 2往前找的逻辑。它不是冗余代码而是在兼容「路由是全局的、标签栈是局部的」这个事实。6. 缓存驱逐为什么不能路由一变就删一个很自然的写法是watch(()route.fullPath,(){evictPageCache(oldPageId)})但在多标签场景里这个写法会遇到两个问题路由变化不等于页面销毁。切换标签、forward、backward都会改路由但大多数页面需要保留路由 watcher 是同步的导航结果不是。守卫拒绝、重定向、导航取消都可能发生提前删除缓存会让页面无法恢复。所以这里把驱逐拆成两步// 第一步只标记markCacheForEviction(cacheName)// 第二步在安全时机统一执行onActivated((){evictMarkedCaches()})evictMarkedCaches会从caches也就是 keep-alive 的include列表里移除这些 name并删除对应的组件工厂。它被安排在页面激活之后、或下一拍执行确保路由已经稳定。代价是状态会短暂多存在一会儿所以还需要isTabMarkedForEviction这类守卫防止一个已经被标记的标签在驱逐前又被渲染出来。7. 刷新活动页和非活动页走两条路「刷新标签」看起来是同一件事但活动页和非活动页不能用同一种实现。constrefreshPage(tab:ITabItem){constcurrentPagegetTopPage(tab.id)if(!currentPage)returnif(tab.active){// 活动页只递增刷新版本让外层 :key 变化触发正常卸载重建updatePage(tab.id,currentPage.id,{refreshVersion:(currentPage.refreshVersion??0)1})return}// 非活动页直接换一个新的 cacheName并驱逐旧缓存constoldCacheNamecurrentPage.idconstnextPageIdcreatePageId()updatePage(tab.id,oldCacheName,{id:nextPageId,refreshVersion:0})evictPageCache(oldCacheName)addCache(nextPageId)}为什么活动页不能直接换cacheName因为活动页正在 keep-alive 里渲染。如果直接把它从include里移除再换:key会同时触发「移出缓存」和「重新挂载」两条路径容易出现重复挂载、闪烁甚至 keep-alive 内部的缓存树和caches列表短时间不一致。而递增refreshVersion只改外层:key组件的卸载/重建完全交给 Vue 的正常生命周期行为更可预测。非活动页没有这个顾虑直接换 id 更彻底。8. 刷新恢复当前版本的契约与边界这一节可能是全文最不「爽文」的部分但它是业务系统真正关心的。8.1 当前版本恢复什么当前sessionStorage里保存的是上次激活的那一个标签包含它的 pages 栈。刷新后状态刷新后当前激活标签及其页面栈✅ 恢复其他已打开标签❌ 不在defaultTabs里就丢失当前页的 URL 归属✅ 由__tab恢复组件内部状态、表单草稿❌ keep-alive 不跨刷新滚动位置⚠️ 需要业务侧持久化栈顶之外的页面深链接❌ 单 URL 只能表达栈顶这不是「设计缺陷」而是当前版本明确的范围。session.ts里只有一个SESSION_TAB_NAMEkeyrestoreTabFromSession只反序列化一个ITabItem。8.2 如果要完整对标业务系统应该怎么改如果你的目标是「刷新后我打开的五个标签都还在」需要把 session 结构从「一个 tab」升级为「标签集合 激活项」interfaceSessionSnapshot{tabs:Array{id:stringtitle:stringclosable:booleanrefreshable:booleaniframe:booleanpages:Array{id:string;path:string;query?:Recordstring,unknown}}activeTabId:string}初始化流程变成先建defaultTabs/homeTab读取 session 快照按id合并缺失的标签用 URL 里的__tab校正当前激活项URL 优先于 session对每个恢复的 page 调用addCache(page.id)。组件实例仍然会重建这是 keep-alive 的边界但标签和导航栈的结构可以完整恢复。对用户来说「现场还在」的体感主要来自标签和路径而不是组件内部对象。8.3 另一个改进方向让__tab更稳定当前__tab里编码了title、closable、refreshable等元数据带来的问题是标签标题一改URL 就变编码串比较长肉眼不可读业务字段变化会牵动 URL 协议。更稳的契约是URL 只携带稳定的tabId必要时加pageId标题等元数据从 session 或路由 meta 补齐。homeTab已经使用固定 idDEFAULT_HOME_TAB_ID来保证刷新前后身份一致这个思路可以推广到所有可恢复标签。9. iframe 标签什么时候该用真隔离路由标签解决不了所有问题。老系统、第三方页面、技术栈完全不同的子系统仍然需要 iframe。这里做了几件容易被忽略的事9.1 懒加载未激活的 iframe 标签src是about:blank首次激活才换成真实 URL避免打开系统时同时发起十几个请求。9.2 刷新策略分两种postMessage通知 iframe 内部自己刷新不重建 DOM适合同源、能改代码的页面reload给 URL 追加__stack_tabs_refresh参数并重建 iframe适合跨域、无法改代码的页面。9.3 加载超时与错误占位默认 15 秒超时超时后展示错误占位提供retry()。iframe 的load事件在跨域场景并不可靠必须有超时兜底。9.4 安全默认值sandbox默认是allow-scripts allow-forms allow-popups allow-downloads allow-same-origin这是兼容优先不是强隔离。要强隔离就移除allow-same-origin并按业务能力继续减少 token把它当成安全边界会出问题。postMessage桥接也一样onRefreshRequest(callback,{allowedOrigins:[https://app.example.com]})allowedOrigins默认是空数组此时不校验 origin任何嵌入该 iframe 的父页面都能触发刷新。这个默认值是为了本地调试方便生产环境必须显式传。源码注释里也写明了这一点。10. 踩坑清单如果你准备自己实现一套下面这些坑大概率会碰到include匹配的是组件 name不是路由 name。包装组件的name必须等于cacheName。包装组件必须是keep-alive的直接子节点。中间多包一层缓存就会落到错误组件上。路由未稳定前不要直接驱逐缓存。先 mark再在onActivated/ 下一拍统一evict。快速连续导航会让事务过期。用版本号判断isCurrent过期事务只能清理不能回滚否则会覆盖新状态。首屏写__tab用replace不要用push。否则用户一进系统就多一条历史记录。__tab里不要放易变字段。标题、权限标记这类会变的信息放进 URL 会让链接失效。活动页刷新别直接换cacheName。用页面级refreshVersion驱动:key走正常卸载重建。iframe 的 sandbox 默认值不是安全边界。allow-same-originallow-scripts组合会显著削弱隔离。backward的步数可能超过栈深。要 clamp 到pages.length - 1并给出开发期警告。session 恢复要校验结构。旧版本数据、被篡改的数据、隐私模式下写入失败都要能降级不能白屏。11. 最小接入11.1 路由需要一个承载VueStackTabs的父路由以及一个 iframe 占位路由constroutes[{path:/,component:()import(./Layout.vue),children:[{path:,component:()import(./pages/Home.vue)},{path:order/:id,component:()import(./pages/OrderDetail.vue)},{path:iframe,component:()import(vue-stack-tabs).then((m)m.IFrame)}]}]11.2 Layouttemplate div styleheight: 100vh VueStackTabs iframe-path/iframe :default-tabsdefaultTabs :max20 / /div /template script setup langts import type { ITabData } from vue-stack-tabs const defaultTabs: ITabData[] [ { title: 首页, path: /, closable: false, refreshable: true } ] /script11.3 打开标签与标签内导航import{useTabActions}fromvue-stack-tabsconst{openTab}useTabActions()openTab({title:订单 A,path:/order/1})openTab({title:订单 B,path:/order/2})import{useTabRouter}fromvue-stack-tabsconst{forward,backward}useTabRouter()// 在当前标签内进入物流页forward({path:/order/2/logistics})// 返回上一页也可以 backward(/order/2)backward(1)11.4 版本前提当前 2.x 的 peer 依赖是vue ^3.5.43、vue-router ^5.4.0。Vue Router 4 的项目请使用 1.x或在升级后再接入。安装前先确认你的项目版本避免 peer 冲突。12. 工程化与真实数据这套东西不算大但为了让它可维护做了一些基础设施核心库约6000 行TS/TSX/Vue33 个测试文件、232 个用例覆盖缓存驱逐、导航事务回滚、session 恢复、iframe 消息校验等时序敏感逻辑ESM 产物61KBgzip 约 20KB样式45KBgzip 约 7KB支持 Vue 3.5、Vue Router 5.4提供 Nuxt 3/4 模块内置中英文 i18n、右键菜单、滚动位置记忆、标签拖拽排序iframe-bridge独立子入口iframe 内页面引它不会带入主库样式。这里刻意不写 star 数和下载量。一个库有没有用和它有多少 star 是两件事对读者来说能不能解决你的场景才重要。13. 适合谁不适合谁适合中后台系统确实需要同一路由多开、每个标签保留自己的页面栈需要从列表 → 详情 → 子详情层层深入并且每层都能独立返回新壳 老系统并存需要 iframe 标签做过渡团队能接受 URL 带__tab并且愿意按约定使用useTabRouter。不适合只需要「标签历史 页面不丢状态」的普通 admin直接用模板自带的 tags-view 更轻需要强安全隔离、故障隔离直接用 iframe不能接受单实例、ESM-only、深度依赖 Vue Router 的项目希望刷新后连表单内容都恢复的团队需要额外的业务级持久化。14. 小结多标签页的难点从来不是「怎么画标签栏」而是keep-alive 的缓存 key 是组件不是页面实例标签内的导航栈和全局路由历史不是一回事刷新恢复需要一个能跨刷新存活的归属标识缓存驱逐必须等导航稳定不能跟着路由 watcher 同步执行。这个项目做的事情本质上是在 Vue Router 之上加了一层「页面实例 标签栈」的映射并接受它带来的侵入性。它不适合所有人但对「同一路由多开 标签内多级返回 刷新现场恢复」这三个需求同时成立的后台系统它比 iframe 轻比单 keep-alive 完整。在线演示https://jktantan.github.io/vue-stack-tabs/demo.html文档https://jktantan.github.io/vue-stack-tabs/源码https://github.com/jktantan/vue-stack-tabsLicense: Apache-2.0你们的 tags-view 是怎么处理「同一路由多开」的是共享一个实例、用 iframe还是自己维护了一套页面栈欢迎在评论区聊聊。
文章目录0. 一个真实场景三个标签三种状态1. 为什么单靠 keep-alive 不够1.1 keep-alive 的缓存粒度是「组件」不是「页面实例」1.2 常见方案对比2. 设计目标与非目标3. 数据模型Tab 与 Page 是一对多4. 让 keep-alive 按「页面实例」缓存4.1 思路4.2 关键实现4.3 一个必须注意的坑包装组件必须是 keep-alive 的直接子节点4.4 代价5. 栈式导航forward / backward 与 __tab5.1 forward先压栈再导航5.2 backward必须先导航再驱逐5.3 __tab 到底在做什么5.4 浏览器原生后退怎么办6. 缓存驱逐为什么不能路由一变就删7. 刷新活动页和非活动页走两条路8. 刷新恢复当前版本的契约与边界8.1 当前版本恢复什么8.2 如果要完整对标业务系统应该怎么改8.3 另一个改进方向让 __tab 更稳定9. iframe 标签什么时候该用真隔离9.1 懒加载9.2 刷新策略分两种9.3 加载超时与错误占位9.4 安全默认值10. 踩坑清单11. 最小接入11.1 路由11.2 Layout11.3 打开标签与标签内导航11.4 版本前提12. 工程化与真实数据13. 适合谁不适合谁14. 小结admin 模板里的 tags-view本质是「组件名 一个 keep-alive」。它能让页面不丢状态但同一路由多开只能共享一个实例标签内也没有独立的前进/后退栈。本文拆解一个基于 Vue Router 的页面级缓存方案用 UUID 作为每个页面实例的缓存身份用StackPage维护标签内导航用 URL 上的__tab保证刷新和分享后仍能恢复归属并如实讨论这套设计的边界与代价。在线演示https://jktantan.github.io/vue-stack-tabs/demo.html源码https://github.com/jktantan/vue-stack-tabs0. 一个真实场景三个标签三种状态先不聊 API想象一个订单后台用户在订单列表勾选订单 A打开详情停留在「售后记录」Tab回到列表又打开订单 B 的详情停留在「物流信息」Tab从订单 B 的详情点进物流详情页再点页面里的「返回」期望回到订单 B 的详情而不是订单列表。这三个动作对应三个很具体的要求同一路由可以多开/order/1和/order/2同时存在筛选条件、表单草稿、滚动位置互不影响每个标签有独立的导航栈订单 B 标签里是「详情 → 物流」订单 A 标签里可能还停在「详情」刷新后现场还在按 F5 之后标签、栈、当前页都还能恢复。大多数 admin 模板的 tags-view第一条就做不到。1. 为什么单靠 keep-alive 不够1.1 keep-alive 的缓存粒度是「组件」不是「页面实例」典型的 tags-view 实现长这样router-view v-slot{ Component } keep-alive :includecachedViews component :isComponent :key$route.fullPath / /keep-alive /router-viewcachedViews里存的是组件 name而keep-alive的include匹配的也是组件 name。问题在于/order/1和/order/2渲染的是同一个OrderDetail组件name 一样。于是include里只有一个OrderDetailkeep-alive 只保留一份实例从 A 切到 B组件被复用onActivated里重新取数A 的表单状态、滚动位置就没了。有人会在:key上用$route.fullPath强制区分。但keep-alive的缓存 key 仍然是组件 name:key只能让组件重建不能让它同时保留两份实例。这是缓存维度的限制不是配置问题。1.2 常见方案对比方案缓存粒度同路由多开标签内导航栈刷新恢复主要代价单 keep-alive 路由 name组件级不支持互相覆盖无依赖 URL无法保留多实例admin 模板 tags-view组件级不支持无部分同上一个标签一个 iframe页面级支持浏览器历史支持通信、样式、内存、路由都要另做一套本文方案页面实例级支持每标签独立栈__tab session侵入性较强URL 带参数iframe 的隔离是真的独立 JS 上下文、独立 CSS、独立路由一个页面崩了不影响别的标签。但代价也真实父子通信要自己做、弹窗/下载/登录态要处理、内存占用高、标签切换有白屏感。如果页面都是同源 Vue 页面用 iframe 属于用重型隔离换一个本来可以靠作用域解决的问题。本文的方案走中间路线仍然是同一个 Vue 应用、同一个路由但把 keep-alive 的缓存单位从「组件」下沉到「页面实例」。2. 设计目标与非目标先把边界说清楚后面的取舍才站得住。目标每个标签拥有独立的页面实例和页面栈标签内支持forward/backward行为接近浏览器历史刷新、复制链接、新窗口打开后能知道当前页面属于哪个标签支持 iframe 标签作为老系统渐进式接入的过渡方案滚动位置、标签增删、批量关闭、右键菜单等后台系统常规能力可用。非目标不做安全隔离。同一 JS 上下文里的「作用域隔离」不等于 iframe 的安全隔离全局变量污染、未捕获异常仍然会影响整个应用不支持一个 Vue app 里多个VueStackTabs实例。业务系统通常只有一个主框架多实例会让路由同步、session 隔离、__tab协议的复杂度成倍上升不承诺刷新后保留组件内部状态。keep-alive 不跨刷新表单草稿这类状态需要业务自己持久化。还有一个容易被误解的点__tab为什么不放到内存里因为它承担的不是「运行时优化」而是「刷新/分享/新窗口时的归属契约」。没有它URL 只剩一个path当两个标签都停在同一路径时浏览器刷新后无法判断当前页面属于哪个标签。sessionStorage只能救当前窗口的刷新救不了复制链接和新窗口。对业务系统来说URL 可恢复性比 URL 干净更重要。3. 数据模型Tab 与 Page 是一对多核心模型只有三层interfaceITabItem{id:stringtitle:stringclosable:booleanrefreshable:booleaniframe:booleanactive:booleanpages:StackITabPage// 标签内的页面栈}interfaceITabPage{id:string// UUID同时是 keep-alive 的 cacheNametabId:stringpath:stringquery?:LocationQueryRaw refreshVersion?:number}Tab 是业务概念用户看到的那一条标签Page 是缓存身份栈里的每一页拥有全局唯一的 UUID栈顶是当前显示页forward入栈backward出栈。Tab ├─ id / title / closable / pinned └─ pages: StackPage ├─ Page { id: UUID, path, query } ← 栈顶当前显示 ├─ Page { id: UUID, path, query } └─ Page { id: UUID, path, query }这个拆分是后面所有机制的基础标签可以切换页面可以出栈但每个页面的缓存身份始终稳定。4. 让 keep-alive 按「页面实例」缓存4.1 思路既然include匹配组件 name那就给每个页面实例造一个唯一的组件 name页面入栈时生成 UUIDcacheName动态defineComponent({ name: cacheName })包一层把这个cacheName放进caches作为include列表component :keyactiveCacheKey切到对应的包装组件。这样/order/1和/order/2虽然内部渲染的是同一个OrderDetail但外层包装组件的 name 不同keep-alive 会为它们保留两份实例。4.2 关键实现包装组件工厂的骨架src/lib/hooks/tabPanel/pageComponentFactory.tsx有删减const cacheComponent defineComponent{ vnode?: VNode }({ name: cacheName, // ← 关键keep-alive 的 include 按这个 name 匹配 props: { vnode: { type: Object as PropTypeVNode, default: undefined } }, setup(props, context) { const lastCloned shallowRefVNode | null(null) onMounted(() { context.emit(onLoaded) addPageScroller(cacheName, #W-${cacheName}) }) onDeactivated(() saveScroller(cacheName)) onActivated(() { context.emit(onLoaded) restoreScroller(cacheName) evictMarkedCaches() // 统一在这里清理待驱逐缓存 }) return () { lastCloned.value props.vnode ? cloneVNode(props.vnode, { tId: tabInfo.id, pId: cacheName, ...(backParams ? { _back: backParams } : {}) }) : null return ( div id{W-${cacheName}} classstack-tab__cache-page-wrapper styleheight: 100% {lastCloned.value} PageLoading tabId{tabInfo.id!} / /div ) } } })对应的模板结构StackKeepAlive.vuerouter-view v-slot{ Component, route } StackCacheRenderer v-slot{ wrappedComponent, activeCacheKey, activePageRefreshVersion, component } :routeroute :componentComponent transition namestack-tab-swap appear modeout-in keep-alive :includecaches component :iswrappedComponent :key${activeCacheKey}-${activePageRefreshVersion} :vnodecomponent / /keep-alive /transition /StackCacheRenderer /router-view4.3 一个必须注意的坑包装组件必须是 keep-alive 的直接子节点如果为了代码整洁在keep-alive和动态组件之间再包一层普通组件keep-alive :includecaches MyWrapper component :iswrappedComponent / /MyWrapper /keep-aliveinclude匹配到的会是MyWrapper的 name而不是页面包装组件的 name缓存直接失效。所以这里没有用「包一层」的写法而是用StackCacheRenderer的scoped slot把解析结果暴露给父级保证真正的缓存页仍然是keep-alive的直接子节点。这段设计在源码注释里写得很直白属于踩过一次就不想再踩的坑。4.4 代价每个页面多一层包装组件DOM 上多一个容器divcacheName必须全局唯一否则两个页面会抢同一份缓存caches是一个需要手动维护的include列表增删时机必须和页面栈严格一致包装组件内部通过cloneVNode注入tId/pId/_back页面组件需要知道这些约定。5. 栈式导航forward / backward 与__tab5.1 forward先压栈再导航constforward(to:RouteLocationPathRaw){constquerydefu(to.query,{__tab:tabInfo})consttransactionVersionnavigationVersionletoptimisticPageIdrunNavigationTransaction({apply:(){constsnapshottab?getPageSnapshot(tab.id):[]if(tab){optimisticPageIdcreatePageId()appendPage(tab.id,{id:optimisticPageId,tabId:tab.id,path:to.path,query:cloneLocationQuery(to.query)})}returnsnapshot},navigate:()router.push({path:to.path,query}),rollback:(snapshot){if(tab)replacePages(tab.id,snapshot)},isFailureResult:isNavigationFailure,isCurrent:()navigationVersiontransactionVersion,cleanupStale:(){if(!tab||!optimisticPageId)returnreplacePages(tab.id,getPages(tab.id).filter((page)page.id!optimisticPageId))}})}注意两件事先压栈再router.push。这样router-view重新渲染时updatePageState能直接在栈顶找到刚创建的 page复用它的cacheName导航失败要回滚。路由守卫拒绝、重复导航、快速连续点击都可能让router.push失败如果不回滚栈里会留下一个永远渲染不出来的「幽灵页」。5.2 backward必须先导航再驱逐constrecyclingBinpopPages(tab.id,steps).map((page)page.id)consttargetgetTopPage(tab.id)runNavigationTransaction({apply:()originalPages,navigate:()router.push({path:target.path,query:targetQueryWithTab}),rollback:(snapshot)replacePages(tab.id,snapshot),isFailureResult:isNavigationFailure,isCurrent:()navigationVersiontransactionVersion,commit:(){for(constidofrecyclingBin)evictPageCache(id)},cleanupStale:(){constactivePageIdsnewSet(getPages(tab.id).map((page)page.id))for(constidofrecyclingBin){if(!activePageIds.has(id))evictPageCache(id)}}})这里最容易写错的是顺序先把页面从栈里弹出但不能立刻销毁缓存要等路由导航成功后再驱逐。原因很直接router.push之后页面的卸载/激活是异步的。如果导航被守卫取消或者用户快速连点导致前一次导航过期提前销毁缓存会让界面停在白屏或旧页面上。所以这里把「弹出的页面」先放进recyclingBin导航成功才真正evictPageCache。5.3__tab到底在做什么每次打开标签、切换标签、forward都会把标签的元信息编码进 URLexportconstencodeTabInfo(tabData:ITabBase):string{constpayload{version:1,id:tabData.id,title:tabData.title,iframe:tabData.iframe,closable:tabData.closable,refreshable:tabData.refreshable,iframeRefreshMode:tabData.iframeRefreshModereload?reload:postMessage}returnencodeBase64(JSON.stringify(payload))}URL 变成这样/order/1?__tabeyJ2ZXJzaW9uIjoxLCJpZCI6...它解决三件事路由归属页面渲染时updatePageState解析__tab知道这次渲染属于哪个标签、哪个页面刷新恢复浏览器刷新后URL 还在标签身份就还在分享/新窗口复制链接给别人对方打开时能落到同一个标签语义里。首屏 URL 通常没有__tab所以初始化时会用router.replace把当前标签编码写回地址而不是push——避免用户刚进系统就多一条历史记录。if(typeofroute.query.__tab!string){voidrouter.replace({path:route.path,query:{...cloneLocationQuery(route.query),__tab:encodeTabInfo(tabInfo)},hash:route.hash})}5.4 浏览器原生后退怎么办用户点浏览器的后退按钮时不会经过backward()路由会直接变化。当前实现会在updatePageState里做一次「栈修复」如果新路径等于栈顶复用如果新路径在栈的中间弹出中间的页面并标记驱逐把栈顶修回目标页如果找不到才创建新页面。这就是为什么updatePageState里有一段从pages.length - 2往前找的逻辑。它不是冗余代码而是在兼容「路由是全局的、标签栈是局部的」这个事实。6. 缓存驱逐为什么不能路由一变就删一个很自然的写法是watch(()route.fullPath,(){evictPageCache(oldPageId)})但在多标签场景里这个写法会遇到两个问题路由变化不等于页面销毁。切换标签、forward、backward都会改路由但大多数页面需要保留路由 watcher 是同步的导航结果不是。守卫拒绝、重定向、导航取消都可能发生提前删除缓存会让页面无法恢复。所以这里把驱逐拆成两步// 第一步只标记markCacheForEviction(cacheName)// 第二步在安全时机统一执行onActivated((){evictMarkedCaches()})evictMarkedCaches会从caches也就是 keep-alive 的include列表里移除这些 name并删除对应的组件工厂。它被安排在页面激活之后、或下一拍执行确保路由已经稳定。代价是状态会短暂多存在一会儿所以还需要isTabMarkedForEviction这类守卫防止一个已经被标记的标签在驱逐前又被渲染出来。7. 刷新活动页和非活动页走两条路「刷新标签」看起来是同一件事但活动页和非活动页不能用同一种实现。constrefreshPage(tab:ITabItem){constcurrentPagegetTopPage(tab.id)if(!currentPage)returnif(tab.active){// 活动页只递增刷新版本让外层 :key 变化触发正常卸载重建updatePage(tab.id,currentPage.id,{refreshVersion:(currentPage.refreshVersion??0)1})return}// 非活动页直接换一个新的 cacheName并驱逐旧缓存constoldCacheNamecurrentPage.idconstnextPageIdcreatePageId()updatePage(tab.id,oldCacheName,{id:nextPageId,refreshVersion:0})evictPageCache(oldCacheName)addCache(nextPageId)}为什么活动页不能直接换cacheName因为活动页正在 keep-alive 里渲染。如果直接把它从include里移除再换:key会同时触发「移出缓存」和「重新挂载」两条路径容易出现重复挂载、闪烁甚至 keep-alive 内部的缓存树和caches列表短时间不一致。而递增refreshVersion只改外层:key组件的卸载/重建完全交给 Vue 的正常生命周期行为更可预测。非活动页没有这个顾虑直接换 id 更彻底。8. 刷新恢复当前版本的契约与边界这一节可能是全文最不「爽文」的部分但它是业务系统真正关心的。8.1 当前版本恢复什么当前sessionStorage里保存的是上次激活的那一个标签包含它的 pages 栈。刷新后状态刷新后当前激活标签及其页面栈✅ 恢复其他已打开标签❌ 不在defaultTabs里就丢失当前页的 URL 归属✅ 由__tab恢复组件内部状态、表单草稿❌ keep-alive 不跨刷新滚动位置⚠️ 需要业务侧持久化栈顶之外的页面深链接❌ 单 URL 只能表达栈顶这不是「设计缺陷」而是当前版本明确的范围。session.ts里只有一个SESSION_TAB_NAMEkeyrestoreTabFromSession只反序列化一个ITabItem。8.2 如果要完整对标业务系统应该怎么改如果你的目标是「刷新后我打开的五个标签都还在」需要把 session 结构从「一个 tab」升级为「标签集合 激活项」interfaceSessionSnapshot{tabs:Array{id:stringtitle:stringclosable:booleanrefreshable:booleaniframe:booleanpages:Array{id:string;path:string;query?:Recordstring,unknown}}activeTabId:string}初始化流程变成先建defaultTabs/homeTab读取 session 快照按id合并缺失的标签用 URL 里的__tab校正当前激活项URL 优先于 session对每个恢复的 page 调用addCache(page.id)。组件实例仍然会重建这是 keep-alive 的边界但标签和导航栈的结构可以完整恢复。对用户来说「现场还在」的体感主要来自标签和路径而不是组件内部对象。8.3 另一个改进方向让__tab更稳定当前__tab里编码了title、closable、refreshable等元数据带来的问题是标签标题一改URL 就变编码串比较长肉眼不可读业务字段变化会牵动 URL 协议。更稳的契约是URL 只携带稳定的tabId必要时加pageId标题等元数据从 session 或路由 meta 补齐。homeTab已经使用固定 idDEFAULT_HOME_TAB_ID来保证刷新前后身份一致这个思路可以推广到所有可恢复标签。9. iframe 标签什么时候该用真隔离路由标签解决不了所有问题。老系统、第三方页面、技术栈完全不同的子系统仍然需要 iframe。这里做了几件容易被忽略的事9.1 懒加载未激活的 iframe 标签src是about:blank首次激活才换成真实 URL避免打开系统时同时发起十几个请求。9.2 刷新策略分两种postMessage通知 iframe 内部自己刷新不重建 DOM适合同源、能改代码的页面reload给 URL 追加__stack_tabs_refresh参数并重建 iframe适合跨域、无法改代码的页面。9.3 加载超时与错误占位默认 15 秒超时超时后展示错误占位提供retry()。iframe 的load事件在跨域场景并不可靠必须有超时兜底。9.4 安全默认值sandbox默认是allow-scripts allow-forms allow-popups allow-downloads allow-same-origin这是兼容优先不是强隔离。要强隔离就移除allow-same-origin并按业务能力继续减少 token把它当成安全边界会出问题。postMessage桥接也一样onRefreshRequest(callback,{allowedOrigins:[https://app.example.com]})allowedOrigins默认是空数组此时不校验 origin任何嵌入该 iframe 的父页面都能触发刷新。这个默认值是为了本地调试方便生产环境必须显式传。源码注释里也写明了这一点。10. 踩坑清单如果你准备自己实现一套下面这些坑大概率会碰到include匹配的是组件 name不是路由 name。包装组件的name必须等于cacheName。包装组件必须是keep-alive的直接子节点。中间多包一层缓存就会落到错误组件上。路由未稳定前不要直接驱逐缓存。先 mark再在onActivated/ 下一拍统一evict。快速连续导航会让事务过期。用版本号判断isCurrent过期事务只能清理不能回滚否则会覆盖新状态。首屏写__tab用replace不要用push。否则用户一进系统就多一条历史记录。__tab里不要放易变字段。标题、权限标记这类会变的信息放进 URL 会让链接失效。活动页刷新别直接换cacheName。用页面级refreshVersion驱动:key走正常卸载重建。iframe 的 sandbox 默认值不是安全边界。allow-same-originallow-scripts组合会显著削弱隔离。backward的步数可能超过栈深。要 clamp 到pages.length - 1并给出开发期警告。session 恢复要校验结构。旧版本数据、被篡改的数据、隐私模式下写入失败都要能降级不能白屏。11. 最小接入11.1 路由需要一个承载VueStackTabs的父路由以及一个 iframe 占位路由constroutes[{path:/,component:()import(./Layout.vue),children:[{path:,component:()import(./pages/Home.vue)},{path:order/:id,component:()import(./pages/OrderDetail.vue)},{path:iframe,component:()import(vue-stack-tabs).then((m)m.IFrame)}]}]11.2 Layouttemplate div styleheight: 100vh VueStackTabs iframe-path/iframe :default-tabsdefaultTabs :max20 / /div /template script setup langts import type { ITabData } from vue-stack-tabs const defaultTabs: ITabData[] [ { title: 首页, path: /, closable: false, refreshable: true } ] /script11.3 打开标签与标签内导航import{useTabActions}fromvue-stack-tabsconst{openTab}useTabActions()openTab({title:订单 A,path:/order/1})openTab({title:订单 B,path:/order/2})import{useTabRouter}fromvue-stack-tabsconst{forward,backward}useTabRouter()// 在当前标签内进入物流页forward({path:/order/2/logistics})// 返回上一页也可以 backward(/order/2)backward(1)11.4 版本前提当前 2.x 的 peer 依赖是vue ^3.5.43、vue-router ^5.4.0。Vue Router 4 的项目请使用 1.x或在升级后再接入。安装前先确认你的项目版本避免 peer 冲突。12. 工程化与真实数据这套东西不算大但为了让它可维护做了一些基础设施核心库约6000 行TS/TSX/Vue33 个测试文件、232 个用例覆盖缓存驱逐、导航事务回滚、session 恢复、iframe 消息校验等时序敏感逻辑ESM 产物61KBgzip 约 20KB样式45KBgzip 约 7KB支持 Vue 3.5、Vue Router 5.4提供 Nuxt 3/4 模块内置中英文 i18n、右键菜单、滚动位置记忆、标签拖拽排序iframe-bridge独立子入口iframe 内页面引它不会带入主库样式。这里刻意不写 star 数和下载量。一个库有没有用和它有多少 star 是两件事对读者来说能不能解决你的场景才重要。13. 适合谁不适合谁适合中后台系统确实需要同一路由多开、每个标签保留自己的页面栈需要从列表 → 详情 → 子详情层层深入并且每层都能独立返回新壳 老系统并存需要 iframe 标签做过渡团队能接受 URL 带__tab并且愿意按约定使用useTabRouter。不适合只需要「标签历史 页面不丢状态」的普通 admin直接用模板自带的 tags-view 更轻需要强安全隔离、故障隔离直接用 iframe不能接受单实例、ESM-only、深度依赖 Vue Router 的项目希望刷新后连表单内容都恢复的团队需要额外的业务级持久化。14. 小结多标签页的难点从来不是「怎么画标签栏」而是keep-alive 的缓存 key 是组件不是页面实例标签内的导航栈和全局路由历史不是一回事刷新恢复需要一个能跨刷新存活的归属标识缓存驱逐必须等导航稳定不能跟着路由 watcher 同步执行。这个项目做的事情本质上是在 Vue Router 之上加了一层「页面实例 标签栈」的映射并接受它带来的侵入性。它不适合所有人但对「同一路由多开 标签内多级返回 刷新现场恢复」这三个需求同时成立的后台系统它比 iframe 轻比单 keep-alive 完整。在线演示https://jktantan.github.io/vue-stack-tabs/demo.html文档https://jktantan.github.io/vue-stack-tabs/源码https://github.com/jktantan/vue-stack-tabsLicense: Apache-2.0你们的 tags-view 是怎么处理「同一路由多开」的是共享一个实例、用 iframe还是自己维护了一套页面栈欢迎在评论区聊聊。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
