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