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