方案一：前端全量配置路由表 + 后端返回權(quán)限碼

思路

• 所有可能的路由都在前端 router 中靜態(tài)配置好（就像你現(xiàn)在這樣）。

• 登錄后，后端返回當(dāng)前用戶的菜單權(quán)限（通常是一個(gè)權(quán)限 code 列表）。

• 前端根據(jù)權(quán)限碼過(guò)濾掉無(wú)權(quán)訪問(wèn)的路由，生成最終的可訪問(wèn)菜單。

優(yōu)點(diǎn)

• 路由結(jié)構(gòu)清晰，開(kāi)發(fā)時(shí)有完整的路由提示和類型支持。

• 不依賴后端返回路由結(jié)構(gòu)，前端可獨(dú)立開(kāi)發(fā)和調(diào)試。

• 性能好，減少一次菜單結(jié)構(gòu)的接口解析。

缺點(diǎn)

• 每次新增菜單都需要前端改代碼并發(fā)版。

• 如果菜單結(jié)構(gòu)變化頻繁，前端維護(hù)成本高。

方案二：后端返回菜單/路由結(jié)構(gòu)，前端動(dòng)態(tài)生成路由

思路

• 登錄后，后端直接返回當(dāng)前用戶可訪問(wèn)的菜單樹（包含 path、component、meta 等信息）。

• 前端用 router.addRoute() 動(dòng)態(tài)注冊(cè)路由。

• 菜單渲染直接用后端返回的數(shù)據(jù)。

優(yōu)點(diǎn)

• 菜單和權(quán)限完全由后端控制，前端無(wú)需改代碼即可調(diào)整菜單結(jié)構(gòu)。

• 多端（Web、App、小程序）可共用一套菜單權(quán)限數(shù)據(jù)。

缺點(diǎn)

• 前端需要做動(dòng)態(tài)組件加載（import()），并處理找不到組件的情況。

• 路由類型提示和 IDE 自動(dòng)補(bǔ)全會(huì)缺失。

• 如果后端返回的路由數(shù)據(jù)有誤，前端可能直接掛掉。

建議

• 如果你的系統(tǒng)菜單變化不頻繁（比如 ERP、后臺(tái)管理系統(tǒng)），推薦方案一： 前端全量配置路由，后端只返回權(quán)限碼，前端過(guò)濾展示。 這樣開(kāi)發(fā)體驗(yàn)好，調(diào)試方便，出錯(cuò)率低。

• 如果你的系統(tǒng)菜單變化頻繁（比如 SaaS 平臺(tái)，不同客戶菜單差異大），推薦方案二： 后端返回菜單樹，前端動(dòng)態(tài)注冊(cè)路由，真正做到菜單和權(quán)限后端可配。

混合方案（很多企業(yè)在用）

• 前端維護(hù)一個(gè)路由組件映射表（path → component）。

• 后端返回菜單結(jié)構(gòu)（只包含 path、meta 等），前端用映射表找到對(duì)應(yīng)組件并動(dòng)態(tài)注冊(cè)。

• 這樣既能后端控制菜單，又能保證組件路徑可控。

// 路由組件映射表
const componentMap = {
  'dashboard': () => import('@/views/Dashboard/index.vue'),
  'system/user': () => import('@/views/System/User.vue'),
  // ...
}

// 動(dòng)態(tài)注冊(cè)
menus.forEach(menu => {
  router.addRoute('Layout', {
    path: menu.path,
    name: menu.name,
    component: componentMap[menu.component]
  })
})

方案一和方案二速度上性能比較

性能對(duì)比

總結(jié)

• 速度優(yōu)先 → 方案一更快，因?yàn)槁酚杀砗徒M件都已經(jīng)在前端準(zhǔn)備好，進(jìn)入系統(tǒng)時(shí)只做一次本地過(guò)濾。

• 靈活性優(yōu)先 → 方案二更靈活，菜單結(jié)構(gòu)改動(dòng)不需要前端發(fā)版，但首屏?xí)稽c(diǎn)。

為什么混合方案比方案二能提升速度那？

組件路徑提前確定，避免運(yùn)行時(shí)查找失敗

• 方案二：后端返回的 component 通常是字符串（如 "system/user"），前端需要在運(yùn)行時(shí)用 import() 去拼接路徑并加載，這個(gè)過(guò)程會(huì)觸發(fā) Webpack 的動(dòng)態(tài)模塊查找，范圍大時(shí)會(huì)生成一個(gè)很大的動(dòng)態(tài) chunk map，解析和匹配都要時(shí)間。

• 混合方案：前端事先維護(hù)一個(gè) componentMap（key → import函數(shù)），直接用 componentMap[menu.component] 獲取組件加載函數(shù)，跳過(guò)了運(yùn)行時(shí)路徑匹配，Webpack 只打包實(shí)際用到的模塊，按需加載更快。

路由注冊(cè)邏輯更輕量

• 方案二：后端返回的菜單數(shù)據(jù)需要先做一輪“數(shù)據(jù)清洗 + 動(dòng)態(tài) import + 異步注冊(cè)”，這一步必須等接口返回后才能開(kāi)始。

• 混合方案：后端只返回菜單結(jié)構(gòu)（不含復(fù)雜組件路徑解析），前端拿到數(shù)據(jù)后直接用映射表匹配組件并注冊(cè)，省去了動(dòng)態(tài)路徑解析的耗時(shí)。

首屏渲染提前啟動(dòng)

• 方案二：首屏必須等菜單接口返回 + 動(dòng)態(tài) import 完成后才能渲染主框架。

• 混合方案：因?yàn)榻M件映射表在打包時(shí)就存在，首屏可以先渲染 Layout 框架，菜單接口返回后再補(bǔ)充路由，不會(huì)阻塞主框架渲染。

打包優(yōu)化更好

• 方案二：動(dòng)態(tài)路徑 import 可能導(dǎo)致 Webpack 打包出一個(gè)大而全的 chunk（因?yàn)樗鼰o(wú)法靜態(tài)分析具體會(huì)用到哪些組件）。

• 混合方案：映射表是靜態(tài)的，Webpack 能精確分割 chunk，按需加載，減少首屏下載體積。

總結(jié)

混合方案的提速點(diǎn)在于：

• 路徑解析提前到編譯期，減少運(yùn)行時(shí)動(dòng)態(tài)匹配

• 組件按需打包，避免大 chunk

• 首屏可并行渲染，減少等待時(shí)間

到此這篇關(guān)于前端菜單權(quán)限幾種方案的使用及對(duì)比的文章就介紹到這了,更多相關(guān)前端菜單權(quán)限內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論