路由配置這活兒看似誰都能寫上兩行但真放到工程里路由表怎么組織、權(quán)限怎么掛載、懶加載怎么切分、刷新為什么白屏每一處都是選擇題。我最早只是把路由當(dāng)“頁面路徑登記表”用后來在幾個(gè)中后臺(tái)項(xiàng)目里反復(fù)重構(gòu)才慢慢理清了一套適合自己的配置方式。這篇就圍繞 Vue 路由配置展開以 vue-router 4 配合 Vue 3 為主同時(shí)兼顧 vue-router 3 老項(xiàng)目的遷移習(xí)慣適合剛上手路由的新人也適合正在折騰權(quán)限路由、動(dòng)態(tài)路由和性能優(yōu)化的開發(fā)者參考。內(nèi)容不堆概念直接講配置背后的邏輯和實(shí)戰(zhàn)中最好用的那套組合拳。1. 路由配置的整體思路——它不只是“路徑和組件的映射表”很多人第一次接觸 vue-router會(huì)覺得它就是把 URL 和組件對(duì)上號(hào)比如{ path: /home, component: Home }這句話沒錯(cuò)但只是表皮。路由真正解決的問題是單頁應(yīng)用沒有傳統(tǒng)多頁面的刷新跳轉(zhuǎn)瀏覽器地址欄發(fā)生變化時(shí)應(yīng)用內(nèi)部的視圖層級(jí)要跟著切換同時(shí)還要保證刷新、前進(jìn)、后退、書簽這些瀏覽器行為仍然可用。這背后涉及三部分地址變化如何被捕獲、匹配到的路由如何渲染、路由過程中如何把狀態(tài)帶過去。這三件事做好了路由才算配置通了。還有一個(gè)容易忽略的點(diǎn)路由配置本質(zhì)上是應(yīng)用導(dǎo)航結(jié)構(gòu)的“靜態(tài)抽象”。一個(gè)項(xiàng)目有多少個(gè)一級(jí)頁面、多少個(gè)嵌套的子模塊、哪些頁面需要權(quán)限、哪些頁面允許帶參數(shù)這些都不是寫到一半臨時(shí)加的而是應(yīng)該在路由設(shè)計(jì)階段就想清楚。我見過不少項(xiàng)目路由全部堆在一個(gè)文件里幾百行數(shù)組越寫越長(zhǎng)后面加一個(gè)頁面要翻半天改一個(gè)權(quán)限要全局搜索這其實(shí)是路由配置沒有做架構(gòu)拆分。合理的做法是按模塊拆比如視圖目錄長(zhǎng)什么樣路由表就跟著長(zhǎng)什么樣一個(gè)模塊對(duì)應(yīng)一個(gè)路由模塊文件頁面結(jié)構(gòu)、文件路徑、路由路徑三者盡量保持一致的對(duì)應(yīng)關(guān)系。另一個(gè)決定整體配置風(fēng)格的關(guān)鍵選擇是路由模式。vue-router 有 hash 模式和 history 模式兩種模式的差異直接在路由配置的第一行決定后續(xù)的部署、運(yùn)維、SEO 策略都會(huì)因此不同。很多人上來就圖好看選 history結(jié)果部署到服務(wù)器之后刷新頁面返回 404又回頭改回 hash。這不是 history 模式不行而是部署側(cè)沒有配合好。后面我會(huì)專開一節(jié)講這個(gè)坑的完整解法。整體思路上我建議先畫一張導(dǎo)航樹應(yīng)用分幾級(jí)菜單哪些頁面共享一個(gè)父級(jí)布局哪些頁面是抽屜、彈窗式的臨時(shí)路由哪些是登錄后才能進(jìn)的受保護(hù)路由。這張樹理清了再落成 routes 數(shù)組就順理成章。路由配置里的大量“為什么這么做”其實(shí)都源于這張導(dǎo)航樹長(zhǎng)什么樣。2. 三步搭起一套基礎(chǔ)路由——從安裝到首屏路由生效2.1 安裝與掛載vue-router 3 和 4 的差別如果是 Vue 3 項(xiàng)目直接安裝 vue-router 4npm install vue-router4如果是 Vue 2 項(xiàng)目需要配套 vue-router 3npm install vue-router3兩者在基礎(chǔ)配置上有個(gè)標(biāo)志性區(qū)別vue-router 3 用new VueRouter()配合new Vue({ router })掛載vue-router 4 改成createRouter()函數(shù)配合createApp(App).use(router)。除此之外v4 還移除了router-link標(biāo)簽上的一些舊屬性改為通過插槽自定義導(dǎo)航內(nèi)容同時(shí)對(duì) TypeScript 的支持更深。老項(xiàng)目升級(jí)時(shí)這些 API 變化是排查腳本類型報(bào)錯(cuò)的高頻區(qū)。2.2 路由實(shí)例與 routes 數(shù)組的最小完整范式一個(gè)最小但完整的 vue-router 4 配置包含四部分路由模式、路由表、創(chuàng)建實(shí)例、掛載到應(yīng)用。// router/index.js import { createRouter, createWebHistory } from vue-router const routes [ { path: /, component: () import(/layout/MainLayout.vue), children: [ { path: , name: Home, component: () import(/views/HomeView.vue), }, { path: about, name: About, component: () import(/views/AboutView.vue), }, ], }, ] const router createRouter({ history: createWebHistory(), routes, scrollBehavior(to, from, savedPosition) { return savedPosition || { top: 0 } }, }) export default router然后在入口文件里import { createApp } from vue import App from ./App.vue import router from ./router createApp(App).use(router).mount(#app)這幾行看起來簡(jiǎn)單但有幾個(gè)細(xì)節(jié)值得展開createWebHistory()是 history 模式createWebHashHistory()是 hash 模式主布局組件包住子路由是絕大多數(shù)后臺(tái)項(xiàng)目的標(biāo)配結(jié)構(gòu)子路由的 path 不要加/開頭寫成about而不是/about否則會(huì)被當(dāng)成絕對(duì)路徑處理導(dǎo)致嵌套失效這個(gè)是我見過新手最容易踩的細(xì)節(jié)。2.3 路由模式的選擇hash 和 history 背后各有一筆賬要算hash 模式 URL 里會(huì)帶#例如example.com/#/home。瀏覽器看到#后面的變化不會(huì)去請(qǐng)求服務(wù)器所以整套路由切換完全靠前端監(jiān)聽 hashChange 完成。它的最大優(yōu)勢(shì)是部署極其簡(jiǎn)單任意靜態(tài)文件服務(wù)器都能直接跑不需要額外的 nginx 或后端配合。缺點(diǎn)是 URL 不美觀SEO 天然吃虧。history 模式利用 HTML5 History APIURL 干凈和普通頁面地址一樣。它需要服務(wù)器把不存在的文件路徑都 fallback 到入口 HTML。以 nginx 為例典型配置是location / { try_files $uri $uri/ /index.html; }如果這一步?jīng)]有配置用戶直接訪問example.com/about時(shí)服務(wù)器找不到/about這個(gè)文件就會(huì)返回 404。很多項(xiàng)目上線前不檢查這條上線后運(yùn)營(yíng)反饋“從瀏覽器地址欄里輸網(wǎng)址打不開”就是這個(gè)原因。我的實(shí)際選擇標(biāo)準(zhǔn)是項(xiàng)目是內(nèi)部中后臺(tái)選 hash省心項(xiàng)目是公開站點(diǎn)、需要分享鏈接或者對(duì) SEO 有要求選 history并提前把服務(wù)器 fallback 規(guī)則寫好。另外history 模式在低版本瀏覽器和某些 WebView 環(huán)境里兼容性稍差如果目標(biāo)用戶那邊 WebView 內(nèi)核比較舊也要把這點(diǎn)算進(jìn)去。3. 路由表的核心細(xì)節(jié)——嵌套路由、命名路由與傳參設(shè)計(jì)3.1 嵌套路由與布局的關(guān)系后臺(tái)項(xiàng)目幾乎都有一個(gè)固定的頁面外殼側(cè)邊欄、頂部導(dǎo)航、內(nèi)容區(qū)。內(nèi)容區(qū)會(huì)隨著路由切換改變內(nèi)部組件外殼不變。這種結(jié)構(gòu)就直接對(duì)應(yīng)嵌套路由。上面示例里MainLayout.vue作為父組件內(nèi)部必須放一個(gè)router-view /作為子路由的出口。如果沒有這個(gè)出口子路由匹配到了組件也渲染不出來因?yàn)楦附M件里根本沒留插槽位置。這跟 Vue 組件的插槽概念是一模一樣的邏輯。嵌套層級(jí)多的時(shí)候每個(gè)層級(jí)都要有對(duì)應(yīng)的router-view。比如一個(gè)三級(jí)菜單/user/list、/user/detail/:id先要有一個(gè)UserLayout接收二級(jí)路由再在UserLayout里再用router-view接收三級(jí)頁面組件。很多人只在根組件 App.vue 里放了一個(gè) router-view二級(jí)、三級(jí)頁面一加新頁面白屏卻不報(bào)任何錯(cuò)排查半天發(fā)現(xiàn)是少放了出口。3.2 命名路由路徑變了邏輯不會(huì)斷name字段看著只是個(gè)字符串別名但它最大的價(jià)值是讓跳轉(zhuǎn)邏輯與 URL 結(jié)構(gòu)解耦。比如router.push({ name: UserDetail, params: { id: 123 } })只要name不變即使后續(xù)重構(gòu)把路徑從/user/detail/:id改成/user/info/:id業(yè)務(wù)代碼也完全不用動(dòng)。這在大型項(xiàng)目里特別重要因?yàn)闃I(yè)務(wù)代碼里可能有幾十處跳轉(zhuǎn)到用戶詳情頁。反過來如果全部寫字符串路徑一改路徑就要全局替換還容易漏。我之前在某個(gè)項(xiàng)目里就是把/order/list改成/order/detail觸發(fā)的關(guān)聯(lián)修正光標(biāo)在編輯器里跳了幾十次從那以后我就形成了習(xí)慣凡是會(huì)被人引用的路由都強(qiáng)制加name。命名路由還有一個(gè)容易被忽視的細(xì)節(jié)params在 vue-router 4 里只有通過name跳轉(zhuǎn)才能正確帶上如果使用path跳轉(zhuǎn)并傳params那個(gè)參數(shù)會(huì)被悄悄丟棄掉。這在 v3 里同樣是坑很多開發(fā)者掉進(jìn)去之后說“路由跳轉(zhuǎn)怎么參數(shù)丟了”十有八九是path params的搭配寫錯(cuò)了。3.3 傳參的三種主流方式及使用場(chǎng)景傳參方式示例使用場(chǎng)景注意點(diǎn)query/user?id1列表頁跳轉(zhuǎn)詳情頁可分享鏈接刷新、復(fù)制鏈接參數(shù)都在params/user/1RESTful 風(fēng)格詳情頁必須配合 name 跳轉(zhuǎn)state內(nèi)存態(tài)傳遞不進(jìn) URL大對(duì)象、敏感信息刷新丟失不適合持久query和params的選擇我一般按語義來URL 里的參數(shù)是否對(duì)頁面內(nèi)容有決定性影響。用戶詳情頁如果不帶 id 就沒有意義用params列表頁的搜索條件、頁碼、排序用query方便用戶在瀏覽器里直接改 URL 做調(diào)試也方便收藏和分享。接收參數(shù)也有差異。vue-router 4 里route.params和route.query都是響應(yīng)式的但組件在參數(shù)變化時(shí)不會(huì)自動(dòng)重新渲染需要watch(() route.params.id)來觸發(fā)邏輯。如果組件加了key綁定比如router-view :key$route.fullPath /參數(shù)變化時(shí)整個(gè)組件會(huì)被強(qiáng)制重建用于那些參數(shù)一變?nèi)捉涌诙家匦吕〉膱?chǎng)景。4. 動(dòng)態(tài)路由與權(quán)限控制的落地——不寫死路由才是中后臺(tái)的標(biāo)配4.1 后端返回菜單前端動(dòng)態(tài)注冊(cè)路由中小項(xiàng)目可以把路由表全部寫在前端但中后臺(tái)系統(tǒng)幾乎都是一次登錄、按角色顯示不同菜單。讓每個(gè)角色都拿到全量路由表再靠 v-if 過濾菜單一方面暴露了未授權(quán)頁面另一方面路由守衛(wèi)里要寫一堆角色判斷邊界情況容易漏。更常見的做法是登錄后請(qǐng)求后端獲取當(dāng)前用戶的菜單權(quán)限數(shù)據(jù)前端把這些數(shù)據(jù)轉(zhuǎn)換成路由對(duì)象用router.addRoute()逐個(gè)動(dòng)態(tài)添加。也正因?yàn)槁酚刹皇菍懰赖膭?chuàng)建 router 實(shí)例時(shí)只放公共路由比如登錄頁、注冊(cè)頁、404 頁以及一個(gè)空殼的主布局其他全部在運(yùn)行時(shí)注入。轉(zhuǎn)轉(zhuǎn)換邏輯大概是這樣的function buildRoutesFromMenu(menu) { return menu.map((item) ({ path: item.path, name: item.name, component: loadView(item.component), children: item.children ? buildRoutesFromMenu(item.children) : [], meta: { title: item.title, icon: item.icon }, })) } async function setupDynamicRoutes(router, menu) { const routes buildRoutesFromMenu(menu) routes.forEach((route) router.addRoute(route)) }這里的loadView通常采用映射表或 import 函數(shù)因?yàn)閯?dòng)態(tài)傳一個(gè)字符串路徑并直接import(字符串)在構(gòu)建工具里無法靜態(tài)分析容易打包失敗。最省事的方案是提前建一張組件路徑和 import 函數(shù)的映射表或者讓后端直接返回組件的相對(duì)路徑由前端統(tǒng)一拼接并映射。4.2 路由守衛(wèi)、meta 與頁面權(quán)限檢查動(dòng)態(tài)路由注冊(cè)完成后需要在全局前置守衛(wèi)里做權(quán)限檢查。標(biāo)準(zhǔn)流程是如果沒有 token放行去登錄頁。如果有 token 但動(dòng)態(tài)路由沒注冊(cè)先請(qǐng)求菜單、注冊(cè)路由、再觸達(dá)原本打算去的頁面。如果目標(biāo)路由匹配到了且配置了權(quán)限標(biāo)識(shí)檢查當(dāng)前用戶是否滿足不滿足就重定向到 403 或首頁。一個(gè)關(guān)鍵小技巧是在beforeEach里通過to.matched遍歷父級(jí)路由的meta因?yàn)樽勇酚煽赡軟]寫權(quán)限標(biāo)識(shí)但它的父路由寫了。比如一個(gè)模塊下所有頁面都需要管理員權(quán)限把meta.roles: [admin]寫在父路由上子路由就不用重復(fù)標(biāo)記檢查時(shí)直接遍歷to.matched一路向上找即可。router.beforeEach(async (to, from) { const hasToken !!getToken() if (!hasToken) { return { name: Login } } if (!store.dynamicRoutesLoaded) { const menu await fetchMenu() const routes buildRoutesFromMenu(menu) routes.forEach((route) router.addRoute(route)) store.dynamicRoutesLoaded true return { ...to, replace: true } } return true })注意守衛(wèi)函數(shù)里不要直接next()一把梭。vue-router 4 支持在beforeEach里直接 return 路由配置或布爾值代碼更簡(jiǎn)潔也減少了忘記調(diào)用next的問題?；氐侥繕?biāo)路由用return { ...to, replace: true }可以避免動(dòng)態(tài)路由注冊(cè)后再次進(jìn)入守衛(wèi)時(shí)重復(fù)邏輯。4.3 動(dòng)態(tài)路由刷新白屏的元兇與對(duì)策動(dòng)態(tài)路由最大的坑是刷新。用戶訪問/user/list時(shí)刷新瀏覽器此時(shí)應(yīng)用剛加載動(dòng)態(tài)路由還沒注冊(cè)路由表里匹配不到/user/list就會(huì)落到 404 頁。很多人抱怨動(dòng)態(tài)路由刷新白屏其實(shí)就是這個(gè)時(shí)序問題。對(duì)策有兩個(gè)層面。第一個(gè)層面在入口處提前恢復(fù)權(quán)限信息如果本地有 token 和菜單緩存先注冊(cè)動(dòng)態(tài)路由再mount(#app)第二個(gè)層面用上面守衛(wèi)里“重試原目標(biāo)”的邏輯兜底第一次匹配不到就先去加載動(dòng)態(tài)路由加載完return { ...to, replace: true }這一次就能正確匹配了。我一般兩層都做入口恢復(fù)能減少閃爍守衛(wèi)兜底能應(yīng)付極端情況。5. 性能優(yōu)化的關(guān)鍵——路由懶加載與組件拆分5.1 動(dòng)態(tài)導(dǎo)入的原理路由懶加載的本質(zhì)不是 vue-router 的魔法而是代碼分割。() import(/views/Example.vue)會(huì)被構(gòu)建工具識(shí)別為動(dòng)態(tài)導(dǎo)入單獨(dú)打包成一個(gè) chunk只有這個(gè)路由被訪問時(shí)才對(duì)應(yīng)用加載腳本。對(duì)應(yīng)的效果就是首屏只下載入口文件和公共依賴其他頁面按需加載。如果把所有路由都寫成靜態(tài)import構(gòu)建出來的主包會(huì)包含所有頁面組件首屏體積飛速膨脹。中后臺(tái)項(xiàng)目頁面一多這種體積增長(zhǎng)是災(zāi)難性的。5.2 分包命名的兩種寫法Webpack 項(xiàng)目里動(dòng)態(tài)導(dǎo)入支持注釋指定 chunk 名稱{ path: example, name: Example, component: () import(/* webpackChunkName: example */ /views/Example.vue), }Vite 項(xiàng)目里chunk 名稱由構(gòu)建配置控制router 里一般不需要注釋但也會(huì)按相對(duì)路徑自動(dòng)生成 chunk 名。如果你希望 chunk 名穩(wěn)定、排錯(cuò)友好可以統(tǒng)一規(guī)劃頁面組件目錄結(jié)構(gòu)讓構(gòu)建產(chǎn)物的清晰度更高。還有一種進(jìn)階玩法是“模塊塊打包”。把同一模塊的路由頁面統(tǒng)一到同一個(gè) chunk 里減少請(qǐng)求數(shù)const orderRoutes () { return import(/views/order/routes) }這種方式適合一個(gè)復(fù)雜模塊內(nèi)頁面之間存在路由跳轉(zhuǎn)頻繁且聯(lián)動(dòng)關(guān)系很強(qiáng)的場(chǎng)景。但要注意模塊包太大時(shí)打開任何一個(gè)模塊頁面都要先下載整個(gè)模塊包反而拖慢首屏所以是否合并要拿體積數(shù)據(jù)說話不要憑感覺。5.3 驗(yàn)證路由拆分的實(shí)際收益懶加載到底有沒有效果不能靠感覺。我常用的驗(yàn)證方式是構(gòu)建產(chǎn)物的體積分析。Webpack 用webpack-bundle-analyzerVite 用rollup-plugin-visualizer構(gòu)建后直接看每個(gè) chunk 的體積分布。另一個(gè)驗(yàn)證點(diǎn)是在瀏覽器 Network 面板里清空緩存后刷新觀察首屏請(qǐng)求數(shù)量和 chunk 加載時(shí)機(jī)。首屏應(yīng)該只加載入口和公共依賴的 chunk切換到未訪問過的路由時(shí)出現(xiàn)一個(gè)新的 JS 請(qǐng)求這就說明按需加載生效了。如果刷新首頁就把所有 chunk 全拉下來了基本可以斷定有地方用了靜態(tài)import或者prefetch策略過于激進(jìn)。Vite 默認(rèn)會(huì)對(duì)動(dòng)態(tài)導(dǎo)入做 prefetch 預(yù)請(qǐng)求這個(gè)行為可以在build.modulePreload.polyfill和build.rollupOptions.output.manualChunks附近配置調(diào)整不過一般默認(rèn)就行。6. 路由配置中經(jīng)常踩的坑與排查實(shí)錄6.1 history 模式刷新 404這是排在最前面的經(jīng)典問題。開發(fā)環(huán)境通常不會(huì)有因?yàn)槟_手架自帶的 dev server 已經(jīng)做好了 fallback上線后才暴露。排查時(shí)先確認(rèn)服務(wù)器配置nginx 的try_files規(guī)則有沒有正確加上如果是 Node 服務(wù)需要自己實(shí)現(xiàn)了靜態(tài)目錄下的 fallback 中間件。如果服務(wù)器配置沒問題還要確認(rèn)部署路徑。Vue 項(xiàng)目部署在子路徑如/app/下時(shí)createWebHistory()要傳入基路徑createWebHistory(/app/)同時(shí)構(gòu)建時(shí)要配置base否則刷新后路徑會(huì)對(duì)不上。這一對(duì)配置經(jīng)常被分開改結(jié)果部署完頁面白屏控制臺(tái)報(bào)錯(cuò)都是資源 404。6.2 路由重復(fù)添加的警告動(dòng)態(tài)路由反復(fù)addRoute同名路由時(shí)控制臺(tái)會(huì)出現(xiàn)紅色警告嚴(yán)重時(shí)路由匹配錯(cuò)亂。常見場(chǎng)景是退出登錄再切換賬號(hào)時(shí)沒有清理上一次添加的動(dòng)態(tài)路由。解決方式是使用removeRoute按名稱移除舊路由。注冊(cè)一面叫router.addRoute(route)返回的是一個(gè)移除函數(shù)直接調(diào)用即可或者用router.removeRoute(route.name)。最穩(wěn)的思路是在退出登錄時(shí)把所有動(dòng)態(tài)添加的路由名列表統(tǒng)一 remove 一遍。我一般會(huì)維護(hù)一個(gè)dynamicRouteNames數(shù)組和一個(gè)resetRouter()函數(shù)。另外路由的name必須唯一。兩個(gè)路由用同一個(gè) name即使路徑不同router.push({ name })也會(huì)匹配到先注冊(cè)的那條行為非常難排查。6.3 組件復(fù)用導(dǎo)致頁面不刷新同一個(gè)路由組件從/user/1跳到/user/2組件默認(rèn)不會(huì)重新創(chuàng)建。因?yàn)?Vue 認(rèn)為組件類型沒變?yōu)榱诵阅苤苯訌?fù)用現(xiàn)有實(shí)例。這會(huì)導(dǎo)致created、mounted等生命周期不重新觸發(fā)頁面顯示的還是上一個(gè)人的信息。解決的常見方案有兩種。一種是監(jiān)聽路由參數(shù)變化watch( () route.params.id, (newId) { fetchDetail(newId) } )另一種是讓組件身份強(qiáng)制變化在 router-view 上綁定:key$route.fullPath或:keyroute.name route.params.id參數(shù)一變組件直接銷毀重建。前者適合需要保留組件局部狀態(tài)的情況后者適合詳情頁這種每次都需要全新數(shù)據(jù)的情況兩種沒有絕對(duì)優(yōu)劣按場(chǎng)景選。6.4 守衛(wèi)死循環(huán)守衛(wèi)里跳轉(zhuǎn)邏輯寫得不小心非常容易卡死循環(huán)。比如if (!token) { router.replace(/login) }如果目標(biāo)還是觸發(fā)守衛(wèi)的路由登錄頁又不匹配放行條件守衛(wèi)就無限執(zhí)行。正確的跳出方式是在 return 的邏輯里加終止條件比如判斷to.path /login就直接放行if (!hasToken to.path ! /login) { return { name: Login } }這種問題在搜索頁、外鏈頁、公共頁面多的項(xiàng)目里尤其常見。我的排查思路是先用瀏覽器控制臺(tái)的面包屑看看跳轉(zhuǎn)記錄是否一直在重復(fù)再逐步注釋守衛(wèi)函數(shù)縮小范圍。守衛(wèi)邏輯最好所有分支都給出明確返回值任何一個(gè)分支“掉進(jìn)去沒有結(jié)果”都可能變成潛在死循環(huán)。7. 一套讓我長(zhǎng)期受益的路由組織習(xí)慣寫了這么多年路由我慢慢把一些零散經(jīng)驗(yàn)沉淀成了固定做法。路由文件一定不只有index.js我習(xí)慣拆成routes.js、guard.js、dynamic.js三個(gè)文件index.js只負(fù)責(zé)組裝。權(quán)限相關(guān)邏輯獨(dú)立開守衛(wèi)里不要寫業(yè)務(wù)代碼只做檢查和放行這樣團(tuán)隊(duì)其他人接手時(shí)能很快找到入口。路由命名統(tǒng)一用模塊前綴比如order-list、order-detail、user-center避免全項(xiàng)目到處都是detail這種含義模糊的名字。路徑命名和組件目錄保持大小寫、結(jié)構(gòu)一致后端給菜單 data 時(shí)直接映射即可不需要寫一堆 if-else。還有一個(gè)小細(xì)節(jié)是在路由meta里統(tǒng)一維護(hù)頁面標(biāo)題和緩存開關(guān)。中后臺(tái)的 Tab 標(biāo)簽頁、面包屑、keep-alive 緩存都可以從meta讀取而不需要在每個(gè)頁面里自己判斷。這個(gè)抽象做得好了新加一個(gè)頁面時(shí)只需要在路由表里寫幾行 meta整套導(dǎo)航和緩存機(jī)制就自動(dòng)生效。每次排查路由問題我最后都會(huì)做一次“路徑可視化演練”拿著用戶實(shí)際的點(diǎn)擊路徑從列表頁到詳情頁到編輯頁再到返回列表一步步對(duì)照路由表、守衛(wèi)、服務(wù)器配置。這個(gè)習(xí)慣幫我繞開了無數(shù)次表面修 bug、根因沒解決的循環(huán)。路由配置看著瑣碎但體系理順之后它會(huì)是整個(gè)項(xiàng)目最省心的一部分。