做后臺(tái)管理系統(tǒng)或者企業(yè)官網(wǎng)的時(shí)候?qū)Ш綑诙际抢@不開的東西。正常情況下用戶點(diǎn)一下導(dǎo)航按鈕按鈕背景色高亮內(nèi)容區(qū)域跟著切過去URL路徑也一起變這一套流程順下來沒什么感覺。但等真正部署上線用戶隨便刷新一下瀏覽器問題就來了——高亮狀態(tài)丟了有的甚至路徑也回了默認(rèn)頁整個(gè)導(dǎo)航看起來像是失靈了一樣。我最早遇到這個(gè)問題是在一個(gè)傳統(tǒng)的多頁面項(xiàng)目里當(dāng)時(shí)以為是瀏覽器緩存清了一遍又一遍結(jié)果還是老樣子。后來仔細(xì)捋了一遍代碼才發(fā)現(xiàn)根本不是緩存的事而是我壓根沒把“導(dǎo)航高亮”和“URL路徑”當(dāng)成一條線來對(duì)待。點(diǎn)擊事件里改了按鈕樣式但沒同步路徑刷新的時(shí)候也沒有反查當(dāng)前路徑去恢復(fù)高亮兩個(gè)邏輯各干各的狀態(tài)自然就丟了。這個(gè)問題看起來小實(shí)際踩坑的人不少尤其是不太熟悉瀏覽器路由機(jī)制的同學(xué)很容易陷在“我明明設(shè)置了樣式怎么會(huì)丟”的困惑里。這篇文章我就用實(shí)際項(xiàng)目的經(jīng)驗(yàn)把導(dǎo)航欄按鈕背景色切換、刷新后狀態(tài)保持、路徑同步這幾個(gè)點(diǎn)徹底聊透包括原生JavaScript的實(shí)現(xiàn)、Vue / uni-app等框架環(huán)境的處理方案以及一些排查問題的實(shí)用技巧。1. 問題現(xiàn)象與根因分析1.1 三個(gè)典型表現(xiàn)場(chǎng)景先說常見的表現(xiàn)排查問題之前得先分清自己屬于哪種情況。第一種刷新后高亮丟了但路徑是對(duì)的。這是最典型的情況。你點(diǎn)了“數(shù)據(jù)看板”這個(gè)導(dǎo)航按鈕地址欄變成了/dashboard按鈕背景色也變藍(lán)了但按一下F5頁面內(nèi)容還是數(shù)據(jù)看板導(dǎo)航高亮卻回到了默認(rèn)第一個(gè)按鈕。這種現(xiàn)象說明你的高亮狀態(tài)只存在于內(nèi)存里頁面一刷新JavaScript重新執(zhí)行所有DOM回到了初始狀態(tài)之前加的class全部被清掉了。第二種點(diǎn)擊后背景色切換了但地址欄路徑壓根沒變。這種情況比第一種更隱蔽。很多同學(xué)會(huì)用a標(biāo)簽做導(dǎo)航按鈕然后在點(diǎn)擊事件里e.preventDefault()阻止了默認(rèn)跳轉(zhuǎn)想著自己用JS去控制頁面切換但寫著寫著就只處理了樣式跳轉(zhuǎn)邏輯漏掉了。表現(xiàn)出來就是按鈕變亮了但路徑?jīng)]變刷新一下又回到原來的狀態(tài)。第三種頁面內(nèi)容切換了但路徑?jīng)]變。這常見于單頁應(yīng)用。有的同學(xué)為了方便直接用v-if或display:none切換幾個(gè)div的顯示隱藏內(nèi)容確實(shí)是換了但地址欄始終是同一個(gè)地址。用戶看著是“頁面切過去了”但任何一個(gè)外部鏈接都沒法直接定位到當(dāng)前內(nèi)容刷新后也必然回到默認(rèn)區(qū)塊壓根談不上狀態(tài)保持。1.2 狀態(tài)丟失的根本原因不管表現(xiàn)是哪種背后只有一個(gè)核心原因?qū)Ш礁吡梁蚒RL路徑用的是兩套獨(dú)立的邏輯沒有形成綁定關(guān)系。用生活里的例子類比一下。你去圖書館借書管理員記的是“張三借了《三體》”但你手里拿的借書卡上寫的是“張三借了《流浪地球》”。書拿走的時(shí)候沒問題第二次來的時(shí)候管理員按卡上的記錄去找書結(jié)果找錯(cuò)了甚至找不到。前端也是一樣樣式狀態(tài)是一張記錄URL地址是另一張記錄兩邊對(duì)不上刷新的時(shí)候以哪個(gè)為準(zhǔn)哪個(gè)都不可靠。更具體地說瀏覽器本身沒有“記住你上一次點(diǎn)擊了哪個(gè)導(dǎo)航按鈕”的功能但它天然會(huì)記住當(dāng)前頁面的URL。所以正確做法是把URL當(dāng)作唯一的“賬本”每次刷新之后都從地址欄反推當(dāng)前應(yīng)該高亮的導(dǎo)航項(xiàng)然后重新設(shè)置樣式。這就解決了第一條。至于點(diǎn)擊后路徑?jīng)]變那是事件處理函數(shù)里壓根沒有寫更新URL的代碼屬于邏輯遺漏不是技術(shù)難題。1.3 正確的架構(gòu)思路搞清楚原因之后解決方案其實(shí)很清晰建立一個(gè)“單向數(shù)據(jù)流”的關(guān)系。URL路徑是唯一數(shù)據(jù)源負(fù)責(zé)記錄當(dāng)前處于哪個(gè)頁面。點(diǎn)擊導(dǎo)航按鈕時(shí)唯一要做的是更新URL路徑。URL變化后通過監(jiān)聽事件或路由機(jī)制自動(dòng)更新導(dǎo)航按鈕的高亮樣式和內(nèi)容區(qū)域。這樣設(shè)計(jì)之后不管用戶是點(diǎn)擊按鈕、手動(dòng)改地址欄、按瀏覽器前進(jìn)后退還是直接刷新頁面所有入口都會(huì)歸到同一條邏輯上根據(jù)當(dāng)前URL渲染頁面狀態(tài)。高亮問題、路徑不同步問題、刷新后狀態(tài)丟失問題都會(huì)一起消失。2. 原生JavaScript可直接落地的完整實(shí)現(xiàn)方案2.1 先搭一個(gè)基礎(chǔ)的導(dǎo)航結(jié)構(gòu)很多項(xiàng)目沒上框架或者只是簡(jiǎn)單的后臺(tái)模板頁面這時(shí)候用原生JS處理是最直接的。先看HTML結(jié)構(gòu)我建議用無序列表加鏈接的經(jīng)典寫法方便語義化也方便后面的事件綁定。ul classnav-list idnavList li a href/dashboard classnav-link>function setActiveNav(currentPath) { const links document.querySelectorAll(.nav-link); // 先統(tǒng)一移除所有高亮避免出現(xiàn)多個(gè)按鈕同時(shí)亮起 links.forEach(function(link) { link.classList.remove(active); }); // 根據(jù)當(dāng)前路徑找到對(duì)應(yīng)鏈接添加高亮 links.forEach(function(link) { if (link.getAttribute(data-path) currentPath) { link.classList.add(active); } }); }這段邏輯看起來簡(jiǎn)單但這個(gè)函數(shù)是整個(gè)方案的地基。后面不管哪個(gè)入口觸發(fā)了路徑變化最終都是調(diào)它來更新按鈕狀態(tài)所以從一開始就封裝成獨(dú)立函數(shù)不要在每個(gè)事件里重復(fù)寫class操作。注意一個(gè)細(xì)節(jié)第二行那個(gè)“先全部移除”不能省。如果不先清除舊的高亮當(dāng)你從“訂單管理”切到“用戶列表”的時(shí)候兩個(gè)按鈕都會(huì)處于高亮狀態(tài)導(dǎo)航欄看起來像故障了一樣。這個(gè)問題我最早踩過排查了半天結(jié)果就是漏了這行。點(diǎn)擊事件綁定然后是點(diǎn)擊事件。這一步的關(guān)鍵有兩點(diǎn)一是阻止a標(biāo)簽的默認(rèn)跳轉(zhuǎn)行為二是更新URL路徑并調(diào)用渲染函數(shù)。document.getElementById(navList).addEventListener(click, function(e) { const target e.target.closest(.nav-link); if (!target) return; // 阻止默認(rèn)跳轉(zhuǎn)改成由JS來控制路徑更新 e.preventDefault(); const path target.getAttribute(data-path); // 使用 history.pushState 更新URL不觸發(fā)整頁刷新 history.pushState(null, , path); // 更新高亮按鈕 setActiveNav(path); });這里用到了e.target.closest(.nav-link)好處是你點(diǎn)擊的不一定剛好是a標(biāo)簽本身可能是里面的文字或者內(nèi)嵌圖標(biāo)closest會(huì)幫我們找到最近的導(dǎo)航鏈接元素避免給每個(gè)內(nèi)含元素單獨(dú)加事件。history.pushState方法比較關(guān)鍵。它可以在不刷新頁面的情況下改變地址欄的URL也不會(huì)觸發(fā)瀏覽器向服務(wù)器發(fā)起新的請(qǐng)求特別適合單頁應(yīng)用。但注意這個(gè)方法要求新的URL必須和當(dāng)前頁面同源這個(gè)限制后面我會(huì)單獨(dú)講。刷新時(shí)恢復(fù)高亮最后是初始化。頁面加載完成的時(shí)候從地址欄讀取當(dāng)前的路徑然后反查對(duì)應(yīng)導(dǎo)航項(xiàng)并設(shè)置高亮。window.addEventListener(DOMContentLoaded, function() { const currentPath window.location.pathname; setActiveNav(currentPath); });如果地址欄是/order頁面加載完之后自動(dòng)把“訂單管理”按鈕點(diǎn)亮。這樣不管你從哪個(gè)外部鏈接進(jìn)來還是手動(dòng)刷新高亮狀態(tài)都能正確恢復(fù)。到這里一個(gè)最基礎(chǔ)的導(dǎo)航欄刷新保持方案就完整了。整個(gè)邏輯循環(huán)起來點(diǎn)擊→更新URL→更新樣式刷新→讀取URL→更新樣式。兩個(gè)入口都?xì)w到同一條鏈路上再也不會(huì)出現(xiàn)狀態(tài)丟失的問題。2.3 三種URL更新方式的選型比較上面我用的是history.pushState但實(shí)際項(xiàng)目里URL更新有三種常用方式各有用武之地需要區(qū)分場(chǎng)景。更新方式刷新后狀態(tài)保持瀏覽器歷史記錄觸發(fā)頁面刷新適用場(chǎng)景l(fā)ocation.href /path保持會(huì)記錄會(huì)整頁刷新傳統(tǒng)多頁面項(xiàng)目location.hash #/path保持會(huì)記錄不刷新老版單頁應(yīng)用history.pushState保持會(huì)記錄不刷新現(xiàn)代SPA、大部分框架項(xiàng)目先說location.href。這種方式最直接頁面直接跳轉(zhuǎn)瀏覽器重新加載新地址。它的優(yōu)點(diǎn)是簡(jiǎn)單可靠缺點(diǎn)是每次切換導(dǎo)航都需要重新請(qǐng)求整個(gè)頁面體驗(yàn)相對(duì)差一些適合傳統(tǒng)的多頁面網(wǎng)站。再說location.hash。早期單頁應(yīng)用常用地址欄里會(huì)出現(xiàn)一個(gè)#號(hào)比如example.com/#/order。好處是不用刷新頁面而且刷新后hash還在高亮能恢復(fù)。缺點(diǎn)是這個(gè)#號(hào)在現(xiàn)代項(xiàng)目里看起來不夠美觀而且SEO不友好搜索引擎對(duì)hash后面的內(nèi)容收錄能力有限。最后是history.pushState。這是目前框架項(xiàng)目里最主流的方案。它改變地址欄但不會(huì)觸發(fā)整頁刷新也不需要#號(hào)配合popstate事件還能監(jiān)聽用戶點(diǎn)擊瀏覽器前進(jìn)后退按鈕。要注意的是生產(chǎn)環(huán)境如果用了history.pushState服務(wù)端必須配置好路徑重寫把所有路由都指向入口HTML文件否則用戶直接訪問/order地址時(shí)會(huì)報(bào)404。這個(gè)配置涉及服務(wù)器環(huán)境細(xì)節(jié)這里不展開但務(wù)必記住有這一層要求。2.4 手動(dòng)實(shí)現(xiàn)時(shí)容易忽略的細(xì)節(jié)方案本身不復(fù)雜但我在實(shí)際寫代碼過程中踩過不少坑集中說一下。第一個(gè)坑pushState的同源限制。window.history.pushState(null, , path)里的path必須是相對(duì)路徑或者和當(dāng)前域名端口完全一致的同源地址。如果你寫了一個(gè)http://other-domain.com/path瀏覽器會(huì)直接報(bào)錯(cuò)。這個(gè)限制是為了安全考慮但也意味著你沒法通過pushState跳轉(zhuǎn)到外部站點(diǎn)。第二個(gè)坑>window.addEventListener(popstate, function() { const currentPath window.location.pathname; setActiveNav(currentPath); });這個(gè)監(jiān)聽要放在初始化的時(shí)候一起綁定。加上之后前進(jìn)后退按鈕也能正確聯(lián)動(dòng)高亮算是閉環(huán)了。3. 框架與復(fù)雜場(chǎng)景下的處理方案原生方案搞定之后再來看看我們工作中更常見的框架環(huán)境。Vue、uni-app、iframe嵌套這幾個(gè)場(chǎng)景各有各的坑單獨(dú)拿出來說。3.1 Vue Router環(huán)境別重復(fù)造輪子在Vue項(xiàng)目里很多人習(xí)慣自己寫一個(gè)函數(shù)在點(diǎn)擊導(dǎo)航時(shí)手動(dòng)替換class這個(gè)思路可以理解但其實(shí)是重復(fù)造輪子。Vue Router本身就內(nèi)置了導(dǎo)航高亮的完整方案用得好完全不用自己寫。最簡(jiǎn)單的方式是用router-link組件替代原生的a標(biāo)簽。router-link在路由匹配成功時(shí)會(huì)自動(dòng)給對(duì)應(yīng)的導(dǎo)航項(xiàng)添加router-link-active類如果設(shè)置了exact屬性會(huì)使用更嚴(yán)格的router-link-exact-active類。我通常在全局樣式里針對(duì)這兩個(gè)類設(shè)置不同顏色不需要任何手動(dòng)邏輯。nav router-link to/dashboard exact數(shù)據(jù)看板/router-link router-link to/order exact訂單管理/router-link router-link to/user exact用戶列表/router-link router-link to/setting exact系統(tǒng)設(shè)置/router-link /nav樣式里寫上.router-link-exact-active { background-color: #409eff; color: #ffffff; }這樣從點(diǎn)擊到刷新再到瀏覽器前進(jìn)后退高亮全部由Vue Router自己接管天然不會(huì)出問題。這也是我做Vue項(xiàng)目最推薦的方式?jīng)]有之一。但有一種情況需要手動(dòng)處理動(dòng)態(tài)生成的導(dǎo)航數(shù)據(jù)比如根據(jù)后端返回的菜單權(quán)限渲染導(dǎo)航項(xiàng)。這時(shí)候router-link仍然可以用關(guān)鍵在于路由的name字段和to屬性的綁定要對(duì)上確保exact匹配不會(huì)誤判。遇到過的最典型問題是/dashboard和/dashboard/detail兩個(gè)路徑同時(shí)存在時(shí)不加exact的話訪問詳情頁會(huì)讓“數(shù)據(jù)看板”和“詳情頁”兩個(gè)按鈕都高亮加上exact之后只匹配完全相同的路徑問題就消失了。另一類需要手動(dòng)處理的情況是使用vue-router的編程式導(dǎo)航比如某個(gè)按鈕不是router-link而是普通的el-button點(diǎn)擊后執(zhí)行this.$router.push(/order)。這時(shí)候按鈕沒有自動(dòng)的active類只能在計(jì)算屬性里判斷this.$route.path再動(dòng)態(tài)綁定class。button :class{ menu-active: $route.path /order } click$router.push(/order) 訂單管理 /button核心思想還是同一個(gè)以$route.path為唯一數(shù)據(jù)源樣式由它推導(dǎo)而不是在點(diǎn)擊事件里手動(dòng)去加類。3.2 uni-app 與小程序自定義導(dǎo)航欄的高亮處理小程序場(chǎng)景下問題又有點(diǎn)不一樣。如果你用的是微信小程序原生的tabBar點(diǎn)擊底部導(dǎo)航時(shí)系統(tǒng)會(huì)自動(dòng)切換選中態(tài)這個(gè)由框架自己處理基本不用操心。但有一個(gè)常見需求是頁面頂部的導(dǎo)航欄按鈕也想要背景色切換這就必須用自定義導(dǎo)航組件了因?yàn)樵鷮?dǎo)航欄的背景色是全局配置的不支持點(diǎn)擊切換。自定義導(dǎo)航欄里按鈕高亮切換的邏輯跟原生網(wǎng)頁類似但有一個(gè)關(guān)鍵區(qū)別小程序頁面切換是通過uni.switchTab、uni.navigateTo等API進(jìn)行的不會(huì)刷新整個(gè)頁面而是會(huì)觸發(fā)目標(biāo)頁面的onShow生命周期。這就意味著如果你在某個(gè)頁面的onLoad里根據(jù)當(dāng)前路由設(shè)置導(dǎo)航高亮有可能不生效——因?yàn)轫撁鎸?shí)例可能已經(jīng)存在直接走的是onShow。我的處理習(xí)慣是寫一個(gè)導(dǎo)航組件在組件的onShow或當(dāng)前頁面onShow里重新讀取當(dāng)前頁面路由再設(shè)置按鈕狀態(tài)。小程序里獲取當(dāng)前頁面路徑可以用getCurrentPages()方法它是小程序框架的原生API返回頁面棧最后一個(gè)元素就是當(dāng)前頁面其route屬性就是路徑。// 頁面onShow里 onShow() { const pages getCurrentPages(); const currentPage pages[pages.length - 1]; const currentPath / currentPage.route; this.setData({ activePath: currentPath }); }如果導(dǎo)航欄是自定義組件的形態(tài)組件內(nèi)部也可以監(jiān)聽當(dāng)前頁面變化。一種做法是通過組件的pageLifetimes.show生命周期在宿主頁面展示時(shí)自動(dòng)觸發(fā)拿到當(dāng)前頁面路徑后更新按鈕狀態(tài)。還有一個(gè)很容易踩的坑是頁面路徑帶參數(shù)。比如進(jìn)入詳情頁時(shí)路徑是/pages/order/detail?id123但導(dǎo)航欄里對(duì)應(yīng)的高亮項(xiàng)是/pages/order/index。如果直接做字符串匹配/pages/order/index和/pages/order/detail根本對(duì)不上。這種情況要么對(duì)路徑做前置截取處理要么在組件里維護(hù)一個(gè)“當(dāng)前導(dǎo)航項(xiàng)對(duì)應(yīng)路徑”的映射表把詳情頁歸到訂單管理的導(dǎo)航項(xiàng)下。另外uni-app里如果監(jiān)聽了底部tabBar的點(diǎn)擊事件有時(shí)候也會(huì)跟自定義頂部導(dǎo)航的狀態(tài)同步產(chǎn)生沖突。我建議的處理方式是底部導(dǎo)航點(diǎn)擊之后統(tǒng)一觸發(fā)一個(gè)全局事件或者Vuex/ Pinia的狀態(tài)更新頂部導(dǎo)航監(jiān)聽同一份數(shù)據(jù)源保證上下一致。千萬不要在底部導(dǎo)航和頂部導(dǎo)航里各維護(hù)一套當(dāng)前激活項(xiàng)的狀態(tài)那樣只會(huì)平白多出無數(shù)個(gè)bug。3.3 iframe嵌套場(chǎng)景父頁面和子頁面如何同步iframe嵌套是真的煩人因?yàn)槔锩嫔婕皟蓚€(gè)獨(dú)立的文檔刷新行為也跟普通頁面完全不同。常見情況是父頁面左側(cè)是導(dǎo)航菜單右側(cè)是iframe點(diǎn)擊菜單切換iframe的src。問題在于如果你單獨(dú)刷新iframe子頁面父頁面的導(dǎo)航高亮是不會(huì)跟著變的因?yàn)楦疙撁鎵焊鶝]重新加載也沒有收到子頁面?zhèn)鬟f的任何信息。你要是刷新整個(gè)父頁面iframe會(huì)重新加載默認(rèn)地址導(dǎo)航是恢復(fù)高亮了但內(nèi)容又回到了最初的頁面用戶之前看的那個(gè)頁面變成了“丟了”的狀態(tài)。針對(duì)這種情況我的方案分成兩部分。第一父頁面導(dǎo)航高亮的來源還是要綁定到當(dāng)前的iframe地址可以用一個(gè)全局變量或者父頁面的hash來記錄點(diǎn)擊導(dǎo)航時(shí)同時(shí)更新這兩者。第二子頁面加載完成后主動(dòng)向父頁面報(bào)告自己的路徑父頁面收到之后設(shè)置對(duì)應(yīng)導(dǎo)航高亮。具體實(shí)現(xiàn)時(shí)在子頁面里用window.parent.postMessage傳遞信息// 子頁面 window.addEventListener(load, function() { const currentPath window.location.pathname; window.parent.postMessage({ type: page-loaded, path: currentPath }, *); });父頁面對(duì)應(yīng)監(jiān)聽消息// 父頁面 window.addEventListener(message, function(event) { if (event.data event.data.type page-loaded) { setActiveNav(event.data.path); } });需要注意postMessage的第二個(gè)參數(shù)指定目標(biāo)窗口的源在生產(chǎn)環(huán)境里建議換成具體的域名不要用通配符*避免安全隱患。這個(gè)細(xì)節(jié)很多新手會(huì)忽略但涉及跨域通信時(shí)非常重要。另外如果iframe子頁面里也有獨(dú)立的導(dǎo)航并且點(diǎn)擊時(shí)要同步父頁面的導(dǎo)航高亮邏輯也是一樣的子頁面點(diǎn)擊后向父頁面發(fā)一條postMessage父頁面更新自己的導(dǎo)航狀態(tài)?？傊趇frame場(chǎng)景里通信協(xié)議就是postMessage狀態(tài)來源就是子頁面當(dāng)前的URL照著這個(gè)思路走基本不會(huì)亂。4. 常見故障排查清單與實(shí)操經(jīng)驗(yàn)4.1 刷新后狀態(tài)完全丟失如果你的導(dǎo)航欄刷新后完全回到默認(rèn)高亮連路徑恢復(fù)都沒做到那多半是初始化回讀的邏輯壓根沒寫上或者寫錯(cuò)了地方。先從三個(gè)點(diǎn)排查第一檢查初始化函數(shù)是否在DOMContentLoaded事件里執(zhí)行。如果腳本放在head里而且沒有加defer執(zhí)行時(shí)DOM結(jié)構(gòu)還不存在querySelectorAll拿到的是空列表高亮自然設(shè)置不上。第二檢查讀取路徑的方式。window.location.pathname、window.location.hash、window.location.href三個(gè)值在帶hash路由的SPA里差異很大先打印到控制臺(tái)看一眼實(shí)際值是什么再?zèng)Q定怎么匹配。第三檢查數(shù)據(jù)路徑和實(shí)際路徑是否匹配。比如導(dǎo)航>