multitabs.js多标签改造：菜单刷新与标签不刷新

后台管理系统顶部那排页面标签几乎是每个中后台产品的标配。点侧边菜单开一个页面顶部就多一个 tab点 tab 能在已开页面之间来回切——这套交互人人都熟可一到细节就露馅。multitabs.js这类多标签组件在默认实现里把点侧边菜单和点顶部页面标签当成同一条路径处理都是激活一个 tab都是把对应的 iframe 或组件显示出来。而实际项目要的是两套语义点侧边菜单得刷新让页面重新拉一遍数据、回到初始状态点顶部标签不能刷新用户填了一半的表单、滚到一半的列表、展开的树节点切回来必须原样还在。围绕侧边菜单点击刷新、顶部页面标签点击不刷新这个诉求下面把我改造 multitabs.js 的完整过程摊开讲机制怎么跑、改造点在哪一行、参数怎么加、单页路由模式怎么等价实现以及踩过的坑。1. 先把需求翻译成技术语言1.1 两种点击在组件内部走的是同一条路径多数 multitabs 实现都长这个样子对外暴露一个openTab(item)方法侧边菜单的点击事件里调它传进去一个对象包含id也叫name或key、url、title三个字段。方法内部先查一遍已开标签列表命中就走激活没命中就走创建 iframe 并激活。问题就出在这个命中就走激活上。激活这个动作本身没有问题问题在于很多组件为了省事在激活之后顺手做了iframe.src item.url或者干脆把 iframe 从 DOM 里摘掉再塞回去。前者等于重新加载后者在某些浏览器里也会触发重排重绘甚至重载。于是不管你是从菜单点进来的还是从标签点回来的页面都被刷了一遍。要改的东西其实很聚焦让激活和加载这两件事彻底解耦。标签点击只做激活一行加载代码都不许有菜单点击才允许带上如果标签已存在则强制重载的指令。把这个原则立住剩下的都是实现细节。1.2 刷新与不刷新分别对应什么用户心智不谈代码先说用户怎么想这件事。用户点侧边菜单心里的预期是我要去那个功能去一个功能通常意味着给我看最新的数据。他可能刚在另一个页面改了某个配置回到列表页希望看到变化。这种时候如果页面还是十分钟前的旧数据用户会以为自己的操作没生效这是实打实的体验事故。所以菜单点击带刷新是符合直觉的。用户点顶部已存在的标签心里的预期是回到我刚才那摊事。他填了三个字段切去别的页面查了个编号现在要回来接着填。这时候一刷新全没了用户情绪直接上来。标签在这个场景里扮演的是工作现场的角色它的价值就在于保住现场。所以这两个动作不是技术上的偏好是两种完全不同的用户心智模型。代码里如果把它们合并成一条路径产品体验必然对不上。1.3 方案选型改源码、包一层还是走配置真动手之前有三条路可走各有取舍。第一条是直接改 multitabs.js 源码在openTab上开一个第二参数。好处是改动最彻底、调用方最省心坏处是组件一旦升级改动会被覆盖得留一份 patch 记录。第二条是不动源码在业务层写一个openTabWithReload的包装函数内部先判断标签是否存在存在就手动调iframe.contentWindow.location.reload()然后再调原生的openTab。好处是零侵入、可随组件版本自由升级坏处是依赖组件的内部结构iframe 的 id 命名规则、DOM 层级组件改个命名就全崩。第三条是走配置看组件有没有暴露refresh之类的开关。多数版本只提供全局开关一开全刷、一关全不刷粒度不够。我的选择是第一条为主、第二条兜底在源码里加参数但参数默认值设成false保证所有旧调用点行为不变同时在业务层留一个包装函数万一哪天组件被替换包装层还能顶一阵。这个组合的性价比最高不会因为一次升级导致全线改代码。提醒不管走哪条路先把openTab的全部调用点 grep 一遍统计清楚有多少处。别改完主框架发现某个隐藏模块还在用旧签名。2. multitabs.js 的核心运行机制拆解2.1 标签、iframe、菜单三者的数据结构理解一个组件最快的办法是看它维护了什么状态。multitabs 这类组件通常内部只有一份数组我们叫它tabList每一项大概是这样的结构{ id: user-list, // 唯一标识通常等于菜单的 code 或路由 path title: 用户列表, // 标签上显示的文字 url: /pages/user/list.html, closable: true, // 是否允许关闭 iframeId: iframe-user-list // 关联的 iframe DOM id }侧边菜单在点击时从菜单配置里取出id、title、url三个字段拼成上面这个对象丢给openTab。顶部标签在点击时只用id去tabList里查查到就把对应 iframe 的display从none改成block其他 iframe 反过来。看出来了吧菜单那边有完整的url标签那边只有id。这个信息差就是我们做区分的天然抓手——只有菜单点击的那条路径才携带着足以重新加载页面的信息。只要在openTab里守住有 url 且显式要求刷新才重载这条规则标签点击天然就不会刷新。2.2 openTab 与 switchTab 的分工组件一般会暴露两个方法名字可能不同职责大同小异。openTab(item)负责打开逻辑是查重 创建或激活。switchTab(id)负责切换逻辑是纯激活不碰 DOM 结构也不碰 iframe 的src。改造的正确姿势是把重载逻辑全部收进openTab并且用一个显式参数控制switchTab里一行加载代码都不留。标签的点击事件绑定的应该是switchTab侧边菜单绑定的应该是openTab。如果发现标签点击也绑到了openTab那基本就是问题根源改绑定比改内部逻辑更省事。我见过不少项目图省事标签点击也走openTab靠内部那段命中则激活的兜底逻辑跑通。跑是能跑但一旦有人往激活分支里加了重载代码标签点击就跟着遭殃。职责分离这件事短期看是麻烦长期看是保险。2.3 刷新动作到底发生在哪一行把刷新归到三类实现效果差别很大写法实质动作是否保留浏览器历史状态是否丢失适用场景iframe.src iframe.src重新请求追加一条历史后退行为异常全部丢失不推荐iframe.contentWindow.location.reload()原地重载保留符合预期全部丢失同源页面首选iframe.src url ?t Date.now()重新请求并绕过缓存追加历史全部丢失需要强制绕过缓存的场景仅切换display不加载不变完整保留标签点击第一种写法看着最简单坑也最多某些浏览器里会往历史栈塞一条记录用户点后退会回到同一个页面体验很怪。第二种是最接近按 F5 的行为前提是 iframe 和主页面同源跨域访问contentWindow会直接抛安全错误。第三种加时间戳能绕开缓存但会破坏 iframe 内部的相对路径跳转一定要慎用。如果页面里还有一层缓存比如后端返回的静态资源带强缓存reload()可能仍读缓存。这种情况我会给 iframe 的src加一个业务无关的 query让 URL 变一下等加载完再把这个 query 抹掉。做法是history.replaceState不影响用户看到的东西。3. 动手改造让菜单刷新、标签不刷新3.1 先做最小侵入的探针定位调用源头动手之前先插个探针把真实的调用链打出来。在openTab的第一行加一句console.trace([openTab], item.id, item.url)然后分别从侧边菜单和顶部标签各点一次看控制台堆栈。这一步价值极高。很多项目里标签点击并不是我以为的那个函数可能是某个 UI 框架的 tab 组件自己 emit 出来的事件中间还绕了两层。探针能直接告诉你真相省掉半小时瞎猜。同时确认三件事iframe 的 id 生成规则是什么、tabList存在哪个变量里、重载代码是否已经存在于激活分支。这三条信息决定了后面改哪、怎么改。3.2 改造方案一给 openTab 加 refresh 参数这是我最推荐的方案。核心改动只有几行// 改造后的 openTab openTab: function (item, forceReload) { var existed this.findTab(item.id); if (existed) { // 命中已有标签先激活 this.activateTab(item.id); // 仅在显式要求刷新时才重载 if (forceReload true) { this.reloadTab(item.id); } return this; } // 未命中新建 this.createTab(item); return this; }, reloadTab: function (tabId) { var iframe document.getElementById(iframe- tabId); if (!iframe) return; // 防止连续点击引发的重复重载 if (iframe.getAttribute(data-loading) 1) return; iframe.setAttribute(data-loading, 1); try { if (iframe.contentWindow iframe.contentWindow.location) { iframe.contentWindow.location.reload(); } else { iframe.src iframe.getAttribute(data-src); } } catch (e) { // 跨域场景下访问 contentWindow 会抛错退化为重置 src iframe.src iframe.getAttribute(data-src); } iframe.addEventListener(load, function onload() { iframe.removeEventListener(load, onload); iframe.removeAttribute(data-loading); }); }关键点说明几个。forceReload true用全等判断不用if (forceReload)。因为有的调用点会传item的某些字段进来宽松判断容易被一个空字符串之外的值意外触发。全等判断让语义只有一种解释。新建路径不加重载逻辑。新标签的 iframe 本来就是带着 src 创建的创建即加载不需要第二次。>// 侧边菜单点击 menu.on(click, function (menuItem) { multitabs.openTab({ id: menuItem.code, title: menuItem.name, url: menuItem.url }, true); // 第二个参数 true 命中已有标签时强制刷新 }); // 顶部标签点击 tabBar.on(click, function (tabId) { multitabs.switchTab(tabId); // 纯激活不刷新 });两行调用的差别就一个true。可别小看这个布尔值它是整个需求的分水岭。写注释的时候我特意标了一句此参数仅用于菜单入口就是防着后来人图省事在标签点击里也传true。还有一种更隐蔽的做法给菜单项对象加一个来源标记multitabs.openTab({ id: menuItem.code, title: menuItem.name, url: menuItem.url, from: menu // 来源标记 });组件内部判断item.from menu才允许刷新。这种写法的好处是调用签名不用变缺点是标记容易被复制粘贴到不该出现的地方。我倾向于显式参数因为它在函数签名上是可见的review 的时候一眼能看出来。3.4 关键代码与参数说明把上面几段拼起来一份可直接抄的完整改造如下var multitabs { tabList: [], findTab: function (id) { for (var i 0; i this.tabList.length; i) { if (this.tabList[i].id id) return this.tabList[i]; } return null; }, openTab: function (item, forceReload) { var existed this.findTab(item.id); if (existed) { this.activateTab(item.id); if (forceReload true) { this.reloadTab(item.id); } return; } this.createTab(item); }, createTab: function (item) { // 上限保护 if (this.tabList.length this.options.maxTabNum) { this.closeTab(this.tabList[1].id); } this.tabList.push({ id: item.id, title: item.title, url: item.url, closable: item.closable ! false }); var iframe document.createElement(iframe); iframe.id iframe- item.id; iframe.setAttribute(data-src, item.url); iframe.src item.url; iframe.frameBorder 0; iframe.style.width 100%; iframe.style.height 100%; this.panel.appendChild(iframe); this.activateTab(item.id); }, activateTab: function (id) { this.tabList.forEach(function (t) { var f document.getElementById(iframe- t.id); if (f) f.style.display (t.id id) ? block : none; }); // 高亮标签样式 this.renderTabBar(id); }, reloadTab: function (id) { var iframe document.getElementById(iframe- id); if (!iframe || iframe.getAttribute(data-loading) 1) return; iframe.setAttribute(data-loading, 1); try { iframe.contentWindow.location.reload(); } catch (e) { iframe.src iframe.getAttribute(data-src); } setTimeout(function () { iframe.removeAttribute(data-loading); }, 800); } };参数上只有一个新增项forceReload取值true/false/ 不传。不传等价于false兼容所有旧调用。maxTabNum那个上限保护顺手提一下。超限时我关掉的是tabList[1]而不是[0]因为[0]通常是首页或者控制台用户不希望它被关掉。这个小细节在组件默认实现里经常被忽略结果标签开多了首页消失用户会懵。reloadTab里的setTimeout解锁是我吃过亏之后加的。早期用load事件解锁跨域兜底那条分支的src重设如果被浏览器拦截load永远不来锁就永远解不开页面再也刷不动。改成定时解锁虽然不够精确但至少不会死锁。4. 单页路由模式下的等价实现4.1 keep-alive 与 key 的配合不全是 iframe 架构。现在不少中后台走的是单页路由标签组件只是渲染router-view。这种架构下点标签不刷新是默认行为因为组件实例被keep-alive缓存住了。真正要解决的问题变成反向的点菜单怎么触发刷新。思路是给缓存的组件一个可控的失效信号。最常用的是给router-view或者keep-alive内部的组件加:keyrouter-view v-slot{ Component } keep-alive :includecachedViews component :isComponent :keyroute.path - refreshStamps[route.path] / /keep-alive /router-viewrefreshStamps是一张表键是路由 path值是时间戳或自增数字。点标签激活不动refreshStamps组件实例从缓存里取出来状态全在。点菜单如果目标路由已经开过标签把refreshStamps[path]加一:key变化Vue 认为这是新组件销毁旧的、创建新的等于刷新。注意keep-alive的include里必须包含该路由的组件名否则加不加 key 都没用。另外 key 变化会让旧实例被销毁如果组件里有未保存的表单会静默丢失。这属于预期行为但如果产品要求刷新前提醒未保存得在 key 变化前拦一道。4.2 provide/inject 或者事件总线做刷新信号key 方案的粒度是整组件重建属于推倒重来。有些场景不需要这么重比如只是想重新拉一次列表表单和筛选条件要保留。这时更适合组件自己暴露一个refresh方法。实现方式是在标签容器里维护一个待刷新路由集合通过provide下发// 容器组件 export default { data() { return { pendingRefresh: [] }; }, provide() { return { tabRefresh: { consume: (path) { const i this.pendingRefresh.indexOf(path); if (i -1) { this.pendingRefresh.splice(i, 1); return true; } return false; } } }; }, methods: { onMenuClick(item) { if (this.openedPaths.includes(item.path)) { this.pendingRefresh.push(item.path); this.activateTab(item.path); } else { this.openTab(item); } } } };页面组件在activated钩子里问一句activated() { if (this.tabRefresh.consume(this.$route.path)) { this.fetchList(); } }这套的比分在于刷新动作由页面自己决定刷新什么。列表页只重拉列表详情页只重拉详情不会把整个组件树重建。缺点是每个页面都得主动接入漏掉的页面仍然是旧数据需要一份接入检查表。4.3 刷新粒度的控制iframe 架构和单页架构在刷新粒度上的表现完全不同值得单独列一下。维度iframe 模式单页 keep-alive 模式默认是否保持状态切换 display 即保持默认保持刷新代价重新请求整个 HTML 资源只重建组件实例资源走缓存刷新能否只重拉数据不能除非页面自己支持能调组件方法即可滚动位置刷新后回顶部key 方案同样回顶方法方案可保留跨域影响有会限制 reload 写法无iframe 模式的优势是隔离性强A 页面的 CSS 不会污染 B 页面劣势是刷新粒度粗一切都得重来。单页模式反过来粒度细但样式和作用域要靠约定约束。选架构的时候就得想清楚刷新这件事怎么办事后再补会很别扭。5. 踩坑实录与排查速查表5.1 高频问题对照表现象最可能的原因排查动作处理办法点标签也刷新了标签点击绑到了openTab且激活分支里有重载加console.trace看堆栈标签改绑switchTab重载逻辑加forceReload守卫点菜单不刷新openTab命中已有标签后直接 return重载代码在 return 之后打断点看是否进入命中分支把重载挪到return之前或加forceReload判断刷新后页面白屏iframe 高度未重算或重载时display被置为 none看 iframe 的 computed style重载前先activateTabload后重算高度连点菜单刷两三次没有防抖锁看 network 是否出现重复请求加>