開門見山地說做后臺管理系統(tǒng)十有八九會撞上權限體系這堵墻。菜單要按角色區(qū)分、頁面要按權限隔離、按鈕要按身份顯隱這一套東西看著簡單真做起來坑比想象多得多。我最近在一個 Vue 3 后臺項目里把這套東西徹徹底底捋了一遍從登錄認證、路由守衛(wèi)一直到按鈕級控制整條鏈路全部打通。這篇文章就聊聊我實際操作中的完整思路和踩過的坑內容包括 Vue 3 Pinia Vue Router 4 的組合方案以及 RBAC 模型的落地細節(jié)。正在做后臺管理系統(tǒng)或者被權限需求搞得頭大的同學可以參考一下。1. 需求拆解一套后臺權限體系到底要管哪些事1.1 先搞清楚權限的三個層級我習慣把權限拆成三個層級來理解登錄權限、路由權限、按鈕權限。三個層級對應三個問題你能不能進這個系統(tǒng)、你能看到哪些頁面、你能對頁面里的東西做什么操作。拿我這次做的管理后臺舉例需求方給的角色分了三種管理員、運營人員、訪客角色。管理員能看所有頁面、能增刪改查所有數據運營人員能看數據看板和數據列表頁面能導出表格但不能刪除數據訪客角色只能看數據看板和報表連導出按鈕都沒有。如果只用路由權限控制運營人員照樣能看到刪除按鈕點擊之后才會被后端攔截體驗很差。所以必須做到按鈕級控制讓沒有權限的人直接看不到操作入口。這是三個層級的核心差異。1.2 為什么主流方案都選 RBAC 模型權限模型有很多種ACL、RBAC、ABAC各有各的適用場景。我在這個項目里選了 RBAC基于角色的訪問控制原因很簡單現實業(yè)務里權限往往是跟著角色走的而不是跟著人走。RBAC 的核心思想是“用戶-角色-權限”三層關系。用戶不直接綁定權限而是綁定角色角色再關聯一堆權限點。比如“運營人員”這個角色關聯了“數據列表頁訪問權限”“導出權限”但不關聯“刪除權限”。新增一個運營人員時只需要給他分配角色權限自然就到位了。對比一下兩種常見模型模型核心思想優(yōu)點缺點適用場景ACL用戶直接關聯權限靈活、精確用戶多了以后維護成本爆炸用戶量小、權限需求簡單RBAC用戶關聯角色角色關聯權限易維護、擴展性好權限需要按角色批量設置絕大多數后臺管理系統(tǒng)ABAC 則基于屬性動態(tài)判斷比如“部門財務且職級經理”適合大型企業(yè)復雜業(yè)務后臺管理系統(tǒng)用不上那么重徒增開發(fā)成本。1.3 整體數據流權限是怎么在系統(tǒng)里流轉起來的我梳理了一套閉環(huán)流程整個權限鏈路的起點是登錄終點是按鈕顯隱。第一步用戶輸入賬號密碼后端校驗成功后返回 token第二步前端拿著 token 請求獲取用戶信息接口返回用戶角色、用戶名、頭像第三步根據角色從后端拿權限列表包括可訪問路由和按鈕權限標識第四步前端用權限列表動態(tài)生成路由、渲染菜單、控制按鈕。這個流程里最關鍵的點在于“權限列表必須由后端返回”不能寫死在前端。否則后端改個權限前端還得重新打包發(fā)版而且權限邏輯暴露在前端代碼里也不安全。我把這條原則貫穿了整個項目。2. 登錄認證權限體系的入口關卡2.1 登錄流程設計與 token 生命周期登錄是整個權限鏈條的第一環(huán)。我設計登錄模塊的時候沒有只做“發(fā)請求、存 token”這兩步而是把登錄完整拆成了五個環(huán)節(jié)表單校驗、發(fā)起登錄請求、存儲 token、拉取用戶信息、跳轉原目標頁面。表單校驗用的是項目里現成的表單組件規(guī)則就兩條用戶名不能為空、密碼長度不能少于 6 位。校驗通過后調登錄接口。后端返回的數據結構約定為{ code: 0, data: { token: xxxxx, expiresIn: 7200 } }這里有一個細節(jié)我把 token 和用戶信息分開存儲了。token 只負責認證用戶信息和權限列表在登錄后單獨用接口拉取。為什么不一步到位全返回因為 token 的有效期是 2 小時用戶信息可能在這期間被修改比如角色調整單獨拉取可以保證用戶刷新頁面后拿到的是最新權限數據。token 過期處理也是容易被忽略的點。我在響應攔截器里做了統(tǒng)一處理如果接口返回 401說明 token 失效清空本地存儲跳轉登錄頁同時用提示組件告知用戶“登錄狀態(tài)已過期”。這里有一個關鍵細節(jié)跳轉登錄頁時要用redirect參數記錄當前路由地址登錄成功后直接跳回原頁面而不是簡單粗暴地跳回首頁。2.2 token 存哪里localStorage、Pinia 與 Cookie 的取舍很多初學者習慣把 token 一股腦塞進 localStorage簡單是簡單但刷新頁面之后 store 里的數據全沒了還得重新讀一遍 localStorage 再寫回 store多一步操作不說還容易出 bug。我的做法是雙層存儲狀態(tài)放 Pinia持久化放 localStorage。Pinia 負責運行時讀寫localStorage 負責刷新后恢復。這樣既能保證響應式又不會刷新丟狀態(tài)。Cookie 方案我這次沒考慮因為 token 存在 Cookie 里要額外配置跨域和 CSRF 防護管理后臺場景下不劃算。每種方案的特點對比存儲位置特點適合場景注意點localStorage持久化、讀寫簡單后臺管理系統(tǒng)標配不參與請求自動發(fā)送需手動封裝Pinia響應式、運行時高效配合 Vue 3 組合式 API刷新丟失必須搭配持久化Cookie請求自動攜帶需要自動帶上 Cookie 的場景跨域配置麻煩有 CSRF 風險實際操作中登錄成功后我做三件事調useUserStore().setToken(token)寫入 Pinia、調封裝的存儲工具寫入 localStorage、請求攔截器把 token 放進 Authorization 請求頭。2.3 請求攔截器與響應攔截器的完整封裝axios 封裝這塊我寫了很多遍每次都覺得應該長記性這次專門做成了一套完整的。請求攔截器核心邏輯就兩條一是讀 token二是附帶請求頭service.interceptors.request.use((config) { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config })響應攔截器需要處理三種情況成功返回、業(yè)務錯誤、登錄失效。我的寫法是統(tǒng)一解構后端的code字段code 0直接返回data給調用方非 0 則彈出錯誤提示并拋出Promise.reject。401 的情況走專門的登出處理這個我在上面說過了有兩點必須注意一是要防止多個請求同時 401 導致重復跳轉登錄頁我加了一個標志位isRelogin攔截二是登出時要調用接口通知后端銷毀 token不能只清前端緩存。3. 路由權限動態(tài)路由是怎么“長”出來的3.1 靜態(tài)路由與動態(tài)路由的分工Vue Router 4 默認是靜態(tài)路由配置表里有什么就注冊什么。但后臺系統(tǒng)的路由不能靜態(tài)寫死因為不同角色能訪問的頁面不一樣。如果全寫靜態(tài)路由用戶直接輸入 URL 就能繞過菜單訪問無權限頁面。我的分工方案是靜態(tài)路由只放公共頁面和兜底頁面包括登錄頁/login、404 頁和根路徑/。動態(tài)路由在登錄后根據權限列表用addRoute逐個注冊。這樣還有個額外好處路由表分成兩段代碼好維護排查問題也方便。// 靜態(tài)路由 export const constantRoutes [ { path: /login, component: () import(/views/login/index.vue) }, { path: /404, component: () import(/views/error/404.vue) }, { path: /, redirect: /dashboard } ]3.2 后端返回路由 vs 前端維護路由映射表這是動態(tài)路由實現路線上的一個分岔口。后端返回什么前端怎么處理決定了整套方案的復雜度。方案 A 是后端直接返回完整路由表包括path、component字符串、name、meta等信息。前端拿到后遍歷注冊。這種方案靈活但有一個明顯的坑后端返回的組件路徑是字符串前端需要把組件映射表提前準備好否則運行時找不到組件。我這次項目用了這種方案映射表寫了一個模塊統(tǒng)一收集// 組件映射表 const modules import.meta.glob(/views/**/*.vue) function loadView(component) { if (!component) return null const path /src/views/${component}.vue return modules[path] }方案 B 是后端只返回權限標識數組比如[dashboard, data-list, system-user]前端維護一套“權限標識 → 路由配置”的映射表。后端返回什么標識前端就過濾出對應的路由去注冊。好處是對后端要求低前端可控性強壞處是新增頁面要改前端代碼再發(fā)版。這兩個方案我用表格總結下方案優(yōu)點缺點推薦場景后端返回完整路由后端控制靈活前端不用維護映射組件映射必須處理首次加載慢大型系統(tǒng)、權限頻繁調整后端返回權限標識前端可控、實現簡單新增路由需前端發(fā)版中小型后臺管理系統(tǒng)我這次項目最終選了方案 A。因為需求里管理員可以在后臺上線新頁面不想每次都等前端發(fā)版。如果你的項目沒有這種動態(tài)擴展需求我更推薦方案 B省心很多。3.3 路由守衛(wèi)的三個關鍵階段路由守衛(wèi)是權限控制的核心執(zhí)行者。我把它拆成了三個階段白名單判斷、token 判斷、權限判斷。白名單就是不需要登錄就能訪問的頁面常見的有登錄頁、注冊頁、404 頁。白名單判斷放在最前面不涉及權限判斷的頁面直接放行減少不必要的邏輯。token 判斷相對直接沒有 token 且訪問的不是白名單頁面就跳轉登錄頁同時記錄當前地址用于登錄后回跳。有 token 但訪問的是登錄頁就直接送去首頁避免登錄頁和主界面來回跳。權限判斷是核心邏輯所在。這一步要判斷當前用戶是不是已經生成了動態(tài)路由。我設置了一個標志位isRoutesGenerated默認為 false。首次進入守衛(wèi)時如果為 false就從后端拉取權限數據、生成動態(tài)路由、next({ ...to, replace: true })強制重新進入當前路由如果已經生成過就直接next()。這段邏輯里最容易出問題的就是死循環(huán)。我寫過一版在next()時會重復觸發(fā)自己然后用to.path /login做判斷結果一轉圈就蹦出個“無限重定向”警告。后來我悟了標志位判斷必須放在最前面生成完路由之后立刻標記為 true并且通過重復導航當前地址來觸發(fā)新的路由匹配而不是直接粗暴next()。4. 按鈕級權限最細粒度的控制手段4.1 自定義指令 v-permission 的實現思路按鈕級別控制是后臺權限體系里最能體現用戶體驗的細節(jié)。沒有按鈕權限控制的時候用戶看到一個刪除按鈕點一下彈“無權限”很打擊人。有了控制之后沒權限的直接看不到干脆利落。Vue 3 里實現按鈕權限我用了自定義指令。指令的名字我定為v-permission使用方式是在按鈕上掛一個權限標識button v-permission[data:delete]刪除數據/button指令背后的邏輯不復雜把權限標識數組傳進去判斷當前用戶是否擁有對應的任一權限如果都沒有就把這個 DOM 元素移出文檔。app.directive(permission, { mounted(el, binding) { const value binding.value const hasPermission useUserStore().permissions.some((item) value.includes(item)) if (!hasPermission) { el.parentNode.removeChild(el) } } })這里有一個細節(jié)我用.some()而不是.every()。因為有的按鈕是“擁有任一權限就能操作”比如導出按鈕可能同時面向運營人員和高級訪客這種情況下只要匹配到其中一個就顯示。4.2 權限點的獲取時機與 store 管理權限點跟著用戶信息一起從后端接口返回。后端返回的權限列表是一個扁平數組比如[dashboard:view, data:list, data:export, user:add]。我把這個數組直接存放在用戶 store 里所有判斷都從 store 讀保證了響應式。export const useUserStore defineStore(user, { state: () ({ token: , roles: [], permissions: [] }), actions: { async fetchUserInfo() { const res await apiGetUserInfo() this.roles res.roles this.permissions res.permissions } } })權限判斷函數我也封裝了一個工具方法方便在非模板場景下使用。比如路由守衛(wèi)里需要判斷某個操作是否允許直接調用checkPermission(data:delete)就行。這樣權限邏輯就收斂到了一個入口避免各處各寫一套。4.3 三種控制方式怎么選除了自定義指令還有一種常見的做法是封裝一個權限組件用包裹按鈕的方式來控制顯隱authority permissiondata:delete button刪除/button /authority組件方案的好處是可以在包裹層統(tǒng)一處理“無權限時顯示什么”的邏輯比如顯示一個引導開啟權限的提示框。壞處是每個按鈕都要套一層組件代碼略啰嗦。函數方案則適合用在非 UI 場景比如事件處理函數里判斷某個邏輯是否執(zhí)行async function handleDelete(row) { if (!checkPermission(data:delete)) { message.warning(您沒有刪除權限) return } await apiDeleteData(row.id) }我這套項目里三種方式都在用模板顯隱用指令、邏輯判斷用函數、需要統(tǒng)一兜底提示的場景用組件。指令方案在模板里最干凈函數方案在邏輯里最靈活。具體用哪個看你的訴求更偏哪一邊。5. 動態(tài)菜單讓側邊欄“聽你指揮”5.1 菜單數據從哪來長什么樣動態(tài)菜單和動態(tài)路由是同一條數據線的兩個消費端。前端從后端拿到的權限數據里除了路由信息還有一個菜單樹結構。一個典型的菜單數據長這樣[ { path: /data, title: 數據中心, icon: chart, children: [ { path: /data/list, title: 數據列表, icon: table }, { path: /data/report, title: 報表分析, icon: document } ] } ]我項目里菜單數據直接從后端接口返回前端不做任何加工直接渲染。好處是后端可以隨時調整菜單順序和層級前端只負責展示。5.2 用遞歸組件渲染無限層級菜單菜單在真實項目里經常有多級甚至三級嵌套所以渲染組件必須支持遞歸。我實現了一個SidebarItem組件判斷當前節(jié)點是否還有children如果有就繼續(xù)渲染自己沒有就渲染菜單項。template el-menu-item v-if!item.children || item.children.length 0 :indexitem.path span{{ item.title }}/span /el-menu-item el-sub-menu v-else :indexitem.path template #title{{ item.title }}/template sidebar-item v-forchild in item.children :keychild.path :itemchild / /el-sub-menu /template這種遞歸寫法我調試的時間比寫的時間還長因為很容易踩到無限遞歸導致頁面卡死。排查下來發(fā)現是父組件名稱引用問題組件內部自引用必須在script setup中用defineOptions聲明name不然遞歸沒法生效。5.3 菜單高亮與面包屑的聯動菜單做好之后還有一個日常體驗問題菜單高亮和面包屑導航。菜單高亮最簡單的方式是從當前路由的path匹配菜單項。但嵌套路由場景下高亮需要考慮父級菜單。面包屑則需要根據當前路由的matched數組來生成。這個數組包含當前路由所有父級路由信息比如訪問/data/reportmatched里會有父級/data和當前級/data/report。遍歷matched取出每個路由的title面包屑就出來了。這塊不算權限體系的核心但和菜單聯動關系緊密我在項目里順手一起做了。實際效果是整個后臺的導航狀態(tài)和權限數據完全同步換賬號后菜單、高亮、面包屑全部自動更新不需要手動刷新。6. 排查實錄權限體系里最常見的四個坑6.1 刷新頁面后直接 404這是動態(tài)路由方案下“重量級”的坑我?guī)缀趺看味紩凰O一跤。問題出在哪呢刷新頁面時程序需要重新執(zhí)行一遍初始化流程如果動態(tài)路由還沒生成完頁面就嘗試匹配當前路徑結果自然是 404。解決思路有兩條。一條是在路由守衛(wèi)里重復導航當前地址等動態(tài)路由生成完我們再next({ ...to, replace: true })重新匹配另一條是把 404 頁面的注冊順序放在動態(tài)路由之后避免提前匹配。我兩條都做了效果穩(wěn)定。你如果遇到了刷新 404先檢查有沒有這兩步基本能解決。6.2 按鈕權限在組件初始化時不生效這個坑我印象很深。自定義指令mounted的時候去讀 store 的 permissions但如果父組件的初始化邏輯比 store 填充數據跑得更早讀到 permissions 是空數組按鈕就會被錯誤移除。排查的時候我打印了一下 store 數據發(fā)現接口返回權限列表之前頁面已經渲染了。解決方式有兩種要么在模板上加v-if等待用戶信息加載完成再渲染按鈕區(qū)域要么把權限指令的判斷邏輯從mounted改成路由守衛(wèi)放行之后才執(zhí)行。我項目里選擇了第一種在布局組件的模板里加了一層template v-ifuserStore.isUserInfoLoaded button v-permission[data:delete]刪除/button /template這樣權限指令執(zhí)行時 store 里已經有數據了判斷結果才可靠。6.3 切換賬號后權限殘留測試同學報了一個 bug從管理員賬號退出換運營賬號登錄之后菜單還是管理員的那一套。排查下來發(fā)現root cause 是退出登錄時只清掉了 token沒有清空 store 里的 roles、permissions 和動態(tài)路由。解決方式是做一套完整的 reset 邏輯退出時清 Pinia、清 localStorage、移除動態(tài)路由。移除動態(tài)路由不是簡單地路由表置空遍歷路由實例把通過addRoute加進去的路由用removeRoute全部移除。我封裝了一個沖掉全部變量和路由的方法在退出登錄時統(tǒng)一執(zhí)行bug 就再沒出現過。6.4 路由守衛(wèi)死循環(huán)怎么排查死循環(huán)是權限系統(tǒng)里最讓人心態(tài)爆炸的問題。表現是瀏覽器一直提示 “Maximum recursive updates exceeded” 或者紅屏。常見原因就是我上面提到的next()重復觸發(fā)守衛(wèi)自身或者權限判斷分支沒有完整的出口。排查手段我用的是最笨也最有效的辦法在守衛(wèi)里每一步加console.log打印to.path和關鍵標志位?；旧洗虺鋈喨罩揪湍芸闯鲅h(huán)在哪。牢記一個原則路由守衛(wèi)里所有可能的分支都必須有明確的next()或return出口不要讓邏輯進入一個無法終結的狀態(tài)。對比幾個典型的解決路徑現象可能原因解決方案刷新 404動態(tài)路由未注冊就匹配重復導航當前地址按鈕全沒了permissions 尚未拉取模板上等用戶信息加載完成換號權限殘留退出未重置狀態(tài)統(tǒng)一 reset store 與路由無限重定向守衛(wèi)里 next 觸發(fā)自身用標志位記錄生成狀態(tài)后記關于這套方案的一些心里話這套權限體系我從搭骨架到穩(wěn)定運行反復調了將近兩個星期?；仡^看看真正難的根本不是某個 API 或某個組件的寫法而是把整條鏈路理順登錄拿 token、token 換用戶信息、用戶信息生成路由、路由驅動菜單、菜單再疊上按鈕權限每一環(huán)都跟下一環(huán)咬合。如果你現在也要在項目里落地權限體系我給三個建議。第一先和后端約定好數據結構再動手權限列表、菜單樹、用戶信息這些字段口徑統(tǒng)一能省掉一大半聯調成本。第二路由守衛(wèi)和按鈕指令里所有分支都要想好出口權限判斷最怕的就是閉環(huán)循環(huán)一個標志位就能避免很多麻煩。第三權限相關代碼集中管理不要散落在各個業(yè)務組件里哪怕只是多封裝一層工具函數以后維護起來會感謝現在的自己。我個人實際做這一套下來最大的體會是權限系統(tǒng)沒有銀彈別人的方案只能參考骨架細節(jié)必須結合自己項目的角色和業(yè)務來打磨。骨架穩(wěn)了后面的持續(xù)迭代就輕松了。