1. 后臺(tái)管理系統(tǒng)模板的骨架到底長(zhǎng)什么樣后臺(tái)管理系統(tǒng)模板這個(gè)詞做前端的人都不陌生。但很多人第一次接觸它的時(shí)候腦子里浮現(xiàn)的畫(huà)面是“一套現(xiàn)成的頁(yè)面拿來(lái)改改文字就能用”。如果你也這么想那大概率會(huì)在真正上手之后被現(xiàn)實(shí)教育一頓。后臺(tái)管理系統(tǒng)模板的本質(zhì)不是“頁(yè)面集合”而是一套經(jīng)過(guò)抽象和約束的UI框架——它規(guī)定了你的項(xiàng)目該怎么組織路由、怎么管理狀態(tài)、怎么處理權(quán)限、怎么統(tǒng)一交互反饋。換句話說(shuō)它更像是一套建筑規(guī)范而不是一堆預(yù)制板。我見(jiàn)過(guò)不少團(tuán)隊(duì)的做法是從某個(gè)開(kāi)源倉(cāng)庫(kù)拉一套模板下來(lái)把Logo一換、菜單一改就直接在上面堆業(yè)務(wù)代碼。前兩周效率確實(shí)高頁(yè)面出得飛快。但到了第三周問(wèn)題開(kāi)始集中爆發(fā)——路由配置散落在五六個(gè)文件里、權(quán)限判斷邏輯在組件和路由守衛(wèi)之間反復(fù)橫跳、主題色改一個(gè)地方要全局搜索替換。這些問(wèn)題的根源都是因?yàn)橐婚_(kāi)始沒(méi)有理解模板的分層設(shè)計(jì)意圖只是把它當(dāng)成了一個(gè)靜態(tài)的頁(yè)面殼子。這篇文章想做的事情很明確把后臺(tái)管理系統(tǒng)模板從“拿來(lái)就用”的層面拉到“理解它為什么這樣設(shè)計(jì)”的層面。我會(huì)從模板的核心分層講起拆解路由、權(quán)限、狀態(tài)、主題這幾條主線各自的設(shè)計(jì)邏輯然后給出從零搭建和二次改造兩條路徑的實(shí)操細(xì)節(jié)最后聊一聊在實(shí)際項(xiàng)目中踩過(guò)的坑和對(duì)應(yīng)的解法。適合正在選型后臺(tái)模板的前端開(kāi)發(fā)者、需要從零搭建管理系統(tǒng)的全棧工程師以及接手了別人搭了一半的模板、正在頭疼怎么往下寫(xiě)的同學(xué)。一個(gè)判斷模板好壞的標(biāo)準(zhǔn)如果你把業(yè)務(wù)代碼全部刪掉剩下的那部分還能獨(dú)立運(yùn)行并且結(jié)構(gòu)清晰那它就是一個(gè)合格的UI框架如果刪掉業(yè)務(wù)代碼之后只剩一堆互相引用的空殼組件那它只是一個(gè)頁(yè)面集合。2. 路由、權(quán)限、狀態(tài)三條主線的設(shè)計(jì)邏輯后臺(tái)管理系統(tǒng)和普通前臺(tái)應(yīng)用最大的區(qū)別在于它天然需要處理多角色、多權(quán)限、多層級(jí)菜單的場(chǎng)景。這三個(gè)“多”字直接決定了模板的骨架必須圍繞路由、權(quán)限和狀態(tài)管理來(lái)搭建。很多模板之所以用起來(lái)別扭就是因?yàn)檫@三條線沒(méi)有理清楚互相糾纏在一起。2.1 路由配置為什么不能直接寫(xiě)死在組件里先說(shuō)說(shuō)路由。新手最容易犯的錯(cuò)誤是把路由配置直接寫(xiě)在頁(yè)面組件旁邊比如在某個(gè)UserList.vue文件里順手定義一條路由記錄。這種做法在頁(yè)面數(shù)量少的時(shí)候看不出問(wèn)題一旦頁(yè)面超過(guò)二十個(gè)路由的維護(hù)就會(huì)變成噩夢(mèng)——你想調(diào)整菜單順序得去翻十幾個(gè)文件你想做權(quán)限過(guò)濾得在每個(gè)路由定義里手動(dòng)加標(biāo)記你想做路由懶加載發(fā)現(xiàn)有些路由已經(jīng)被靜態(tài)引入了。合理的做法是把路由配置集中管理并且按照“靜態(tài)路由”和“動(dòng)態(tài)路由”分開(kāi)。靜態(tài)路由是所有角色都能訪問(wèn)的基礎(chǔ)頁(yè)面比如登錄頁(yè)、404頁(yè)、個(gè)人中心動(dòng)態(tài)路由則是根據(jù)用戶角色動(dòng)態(tài)掛載的業(yè)務(wù)頁(yè)面。這樣設(shè)計(jì)的好處是權(quán)限過(guò)濾只需要在動(dòng)態(tài)路由這一層做文章靜態(tài)路由不受影響。// 靜態(tài)路由所有角色可見(jiàn) const staticRoutes [ { path: /login, component: Login, meta: { hidden: true } }, { path: /404, component: NotFound, meta: { hidden: true } }, { path: /profile, component: Profile, meta: { title: 個(gè)人中心 } } ] // 動(dòng)態(tài)路由按角色權(quán)限過(guò)濾后掛載 const asyncRoutes [ { path: /user, meta: { title: 用戶管理, roles: [admin] }, children: [ { path: list, component: UserList, meta: { title: 用戶列表 } }, { path: detail/:id, component: UserDetail, meta: { hidden: true } } ] } ]這里有一個(gè)容易被忽略的細(xì)節(jié)meta字段的設(shè)計(jì)。很多模板只用了title和icon但實(shí)際上meta可以承載更多信息——roles用于權(quán)限判斷、hidden用于控制菜單是否顯示、keepAlive用于控制頁(yè)面緩存、breadcrumb用于面包屑導(dǎo)航。把這些信息統(tǒng)一放在meta里路由配置就變成了一個(gè)自描述的數(shù)據(jù)結(jié)構(gòu)菜單渲染、權(quán)限過(guò)濾、面包屑生成都可以從同一份數(shù)據(jù)源派生出來(lái)避免了多處維護(hù)。2.2 權(quán)限判斷放在路由守衛(wèi)里還是組件里權(quán)限這條線核心問(wèn)題是“在哪里做判斷”。我見(jiàn)過(guò)三種做法各有各的問(wèn)題。第一種是在每個(gè)頁(yè)面組件內(nèi)部做判斷比如在UserList組件里寫(xiě)if (role ! admin) return。這種做法的問(wèn)題是權(quán)限邏輯分散新增角色的時(shí)候要改所有相關(guān)組件而且組件內(nèi)部的判斷只能控制內(nèi)容顯示控制不了路由訪問(wèn)。第二種是在路由守衛(wèi)里做統(tǒng)一判斷。這是比較主流的做法在beforeEach鉤子里檢查目標(biāo)路由的meta.roles是否包含當(dāng)前用戶角色不包含就重定向到403頁(yè)面。這種做法的優(yōu)點(diǎn)是集中、清晰但缺點(diǎn)是只能做路由級(jí)別的權(quán)限控制做不到按鈕級(jí)別的細(xì)粒度控制。第三種是路由守衛(wèi)加指令/組件的組合方案。路由守衛(wèi)負(fù)責(zé)頁(yè)面級(jí)權(quán)限自定義指令負(fù)責(zé)按鈕級(jí)權(quán)限。比如定義一個(gè)v-permission指令傳入權(quán)限標(biāo)識(shí)指令在綁定時(shí)檢查當(dāng)前用戶是否擁有該權(quán)限沒(méi)有就把元素從DOM中移除。// 路由守衛(wèi)頁(yè)面級(jí)權(quán)限 router.beforeEach((to, from, next) { const userRole store.getters.role if (to.meta.roles !to.meta.roles.includes(userRole)) { next(/403) } else { next() } }) // 自定義指令按鈕級(jí)權(quán)限 Vue.directive(permission, { inserted(el, binding) { const permissions store.getters.permissions if (!permissions.includes(binding.value)) { el.parentNode.removeChild(el) } } })實(shí)際項(xiàng)目中我建議把權(quán)限數(shù)據(jù)設(shè)計(jì)成一個(gè)扁平的標(biāo)識(shí)列表而不是嵌套的角色樹(shù)。比如用戶擁有[user:list, user:edit, order:view]這樣的權(quán)限標(biāo)識(shí)路由的meta里配置對(duì)應(yīng)的標(biāo)識(shí)指令里也判斷標(biāo)識(shí)。這樣角色和權(quán)限解耦新增角色只需要配置權(quán)限標(biāo)識(shí)列表不需要改代碼。2.3 狀態(tài)管理該管什么、不該管什么狀態(tài)管理是后臺(tái)模板里最容易過(guò)度設(shè)計(jì)的地方。很多模板一上來(lái)就把所有數(shù)據(jù)往Vuex或Pinia里塞結(jié)果store文件比業(yè)務(wù)代碼還多。我的經(jīng)驗(yàn)是全局狀態(tài)只放三類東西——用戶信息、權(quán)限數(shù)據(jù)、應(yīng)用級(jí)配置主題、語(yǔ)言、側(cè)邊欄折疊狀態(tài)。頁(yè)面級(jí)的列表數(shù)據(jù)、表單數(shù)據(jù)、彈窗狀態(tài)一律放在組件內(nèi)部管理。為什么這么分因?yàn)槿譅顟B(tài)的核心特征是“多個(gè)不相關(guān)的組件都需要訪問(wèn)”。用戶信息在頂部導(dǎo)航、側(cè)邊欄、權(quán)限指令里都要用所以放全局主題色在設(shè)置面板和所有組件里都要用所以放全局。但用戶列表的數(shù)據(jù)只有用戶列表頁(yè)用訂單詳情只有訂單詳情頁(yè)用放全局只會(huì)增加維護(hù)成本。// store/user.js —— 只放全局需要的數(shù)據(jù) export const useUserStore defineStore(user, { state: () ({ token: , name: , role: , permissions: [] }), actions: { async login(credentials) { const { token } await api.login(credentials) this.token token const info await api.getUserInfo() this.name info.name this.role info.role this.permissions info.permissions }, logout() { this.$reset() } } })還有一個(gè)細(xì)節(jié)token的持久化。很多模板把token存在localStorage里刷新頁(yè)面后從localStorage讀取。這本身沒(méi)問(wèn)題但要注意在路由守衛(wèi)里處理“token存在但用戶信息為空”的情況——比如用戶手動(dòng)清了localStorage里的用戶信息但沒(méi)清token這時(shí)候需要重新拉取用戶信息而不是直接放行。3. 從零搭建一套模板的完整實(shí)操路徑理解了設(shè)計(jì)邏輯之后動(dòng)手搭建就是水到渠成的事情。這一章我會(huì)按照實(shí)際搭建的順序把每一步的關(guān)鍵決策和操作細(xì)節(jié)講清楚。整個(gè)流程分為項(xiàng)目初始化、布局系統(tǒng)搭建、路由與權(quán)限接入、以及主題系統(tǒng)實(shí)現(xiàn)四個(gè)階段。3.1 項(xiàng)目初始化時(shí)容易埋下的三個(gè)隱患初始化項(xiàng)目看起來(lái)簡(jiǎn)單npm create一條命令就完事了但有幾個(gè)決策會(huì)直接影響后續(xù)的開(kāi)發(fā)體驗(yàn)。第一個(gè)是構(gòu)建工具的選擇。Vite和Webpack各有優(yōu)劣但對(duì)于后臺(tái)管理系統(tǒng)這種中大型項(xiàng)目Vite的開(kāi)發(fā)服務(wù)器啟動(dòng)速度和熱更新速度優(yōu)勢(shì)非常明顯。我實(shí)測(cè)過(guò)一個(gè)中等規(guī)模的后臺(tái)項(xiàng)目Webpack冷啟動(dòng)需要二十多秒Vite基本在三秒以內(nèi)。生產(chǎn)構(gòu)建方面Vite基于Rollup產(chǎn)物質(zhì)量也足夠。所以如果沒(méi)有特殊的歷史包袱我建議直接用Vite。第二個(gè)是目錄結(jié)構(gòu)的規(guī)劃。很多模板的目錄結(jié)構(gòu)是src/views、src/components、src/api這樣平鋪的項(xiàng)目大了之后views下面會(huì)有幾十個(gè)文件夾。更好的做法是按業(yè)務(wù)模塊劃分比如src/modules/user、src/modules/order每個(gè)模塊內(nèi)部有自己的views、api、components。這樣模塊之間的邊界清晰后續(xù)如果要拆分成微前端或者獨(dú)立包遷移成本很低。src/ ├── modules/ │ ├── user/ │ │ ├── views/ │ │ ├── api.js │ │ └── routes.js │ └── order/ │ ├── views/ │ ├── api.js │ └── routes.js ├── layouts/ ├── router/ ├── store/ └── styles/第三個(gè)是代碼規(guī)范的接入時(shí)機(jī)。ESLint和Prettier一定要在項(xiàng)目初始化階段就配好不要等到代碼寫(xiě)了幾千行再補(bǔ)。因?yàn)楹笃谘a(bǔ)規(guī)范意味著你要面對(duì)成百上千個(gè)lint錯(cuò)誤改起來(lái)非常痛苦。初始化時(shí)配好配合編輯器的保存自動(dòng)格式化后續(xù)基本不需要操心。3.2 布局系統(tǒng)的四種常見(jiàn)形態(tài)與選擇依據(jù)后臺(tái)管理系統(tǒng)的布局說(shuō)到底就是幾個(gè)區(qū)域的排列組合側(cè)邊欄、頂部導(dǎo)航、標(biāo)簽頁(yè)、內(nèi)容區(qū)。不同的組合方式對(duì)應(yīng)不同的使用場(chǎng)景。布局形態(tài)側(cè)邊欄頂部導(dǎo)航標(biāo)簽頁(yè)適用場(chǎng)景經(jīng)典布局左側(cè)固定頂部固定有菜單層級(jí)多、需要多標(biāo)簽切換頂部布局無(wú)頂部橫向菜單無(wú)菜單層級(jí)少、頁(yè)面切換頻繁混合布局左側(cè)一級(jí)菜單頂部二級(jí)菜單有菜單層級(jí)多且分類明確極簡(jiǎn)布局可折疊極簡(jiǎn)無(wú)追求內(nèi)容區(qū)域最大化選擇哪種布局核心看菜單的層級(jí)深度和用戶的操作習(xí)慣。如果菜單只有兩級(jí)頂部布局完全夠用而且內(nèi)容區(qū)域更寬如果菜單有三到四級(jí)左側(cè)經(jīng)典布局更合適因?yàn)閭?cè)邊欄可以滾動(dòng)不受屏幕寬度限制。實(shí)現(xiàn)布局系統(tǒng)的關(guān)鍵是把各個(gè)區(qū)域做成獨(dú)立的布局組件通過(guò)配置組合。比如Sidebar組件、Navbar組件、TagsView組件、AppMain組件然后在Layout組件里根據(jù)配置決定渲染哪些區(qū)域。這樣切換布局形態(tài)只需要改配置不需要改組件代碼。template div classapp-wrapper Sidebar v-iflayout.showSidebar :collapsedcollapsed / div classmain-container Navbar v-iflayout.showNavbar / TagsView v-iflayout.showTags / AppMain / /div /div /template標(biāo)簽頁(yè)TagsView是一個(gè)值得單獨(dú)說(shuō)的組件。它的核心邏輯是用戶訪問(wèn)過(guò)的頁(yè)面會(huì)被記錄到一個(gè)標(biāo)簽列表里點(diǎn)擊標(biāo)簽可以快速切換關(guān)閉標(biāo)簽會(huì)從列表中移除。實(shí)現(xiàn)時(shí)要注意幾個(gè)細(xì)節(jié)——首頁(yè)標(biāo)簽不可關(guān)閉、當(dāng)前激活標(biāo)簽的樣式區(qū)分、右鍵菜單支持關(guān)閉其他/關(guān)閉右側(cè)、以及標(biāo)簽列表和路由的同步。這些細(xì)節(jié)看起來(lái)瑣碎但直接影響用戶的使用體驗(yàn)。3.3 路由與權(quán)限接入的先后順序接入路由和權(quán)限的時(shí)候順序很重要。我建議的順序是先配靜態(tài)路由再配動(dòng)態(tài)路由然后接路由守衛(wèi)最后做菜單渲染。靜態(tài)路由配好之后項(xiàng)目應(yīng)該能正常跑起來(lái)登錄頁(yè)、404頁(yè)都能訪問(wèn)。這時(shí)候再接動(dòng)態(tài)路由動(dòng)態(tài)路由的數(shù)據(jù)來(lái)源可以是后端接口返回的菜單樹(shù)也可以是前端根據(jù)角色過(guò)濾的本地配置。如果是后端返回菜單樹(shù)需要把菜單樹(shù)轉(zhuǎn)換成路由配置的格式這個(gè)轉(zhuǎn)換函數(shù)要處理好組件路徑的映射——后端返回的可能是字符串路徑前端需要映射到實(shí)際的組件導(dǎo)入。// 菜單樹(shù)轉(zhuǎn)路由配置 function menuToRoutes(menus) { return menus.map(menu { const route { path: menu.path, name: menu.name, meta: { title: menu.title, icon: menu.icon } } if (menu.component Layout) { route.component Layout } else if (menu.component) { route.component () import(/modules/${menu.component}.vue) } if (menu.children menu.children.length) { route.children menuToRoutes(menu.children) } return route }) }路由守衛(wèi)的接入要注意白名單的處理。登錄頁(yè)、404頁(yè)、以及一些不需要登錄就能訪問(wèn)的頁(yè)面要放在白名單里直接放行。白名單的判斷要在token檢查之前否則會(huì)出現(xiàn)“訪問(wèn)登錄頁(yè)被重定向到登錄頁(yè)”的死循環(huán)。菜單渲染則是從路由配置反向生成菜單樹(shù)。這里要注意meta.hidden的處理——有些路由是詳情頁(yè)不應(yīng)該出現(xiàn)在菜單里通過(guò)hidden標(biāo)記過(guò)濾掉。菜單的層級(jí)要和路由的層級(jí)對(duì)應(yīng)但菜單的排序可以通過(guò)meta.sort來(lái)控制不一定完全按照路由定義的順序。3.4 主題切換的實(shí)現(xiàn)細(xì)節(jié)與性能考量主題切換是后臺(tái)模板的標(biāo)配功能但實(shí)現(xiàn)方式直接影響性能。常見(jiàn)的做法有兩種CSS變量和SCSS變量編譯時(shí)切換。CSS變量的做法是在根元素上定義一組變量切換主題時(shí)修改變量的值。這種方式的優(yōu)點(diǎn)是切換速度快不需要重新編譯而且支持動(dòng)態(tài)過(guò)渡動(dòng)畫(huà)。缺點(diǎn)是IE不支持不過(guò)現(xiàn)在后臺(tái)系統(tǒng)基本不考慮IE了以及一些復(fù)雜的樣式計(jì)算用CSS變量表達(dá)起來(lái)比較繞。:root { --primary-color: #1890ff; --bg-color: #f0f2f5; --text-color: #333; } [data-themedark] { --primary-color: #177ddc; --bg-color: #141414; --text-color: #e8e8e8; }SCSS變量編譯時(shí)切換的做法是準(zhǔn)備多套變量文件切換時(shí)重新編譯。這種方式的優(yōu)點(diǎn)是可以用SCSS的函數(shù)和混合樣式表達(dá)能力更強(qiáng)。缺點(diǎn)是切換時(shí)需要重新加載樣式文件有閃爍而且構(gòu)建產(chǎn)物體積會(huì)變大。我的建議是主色調(diào)用CSS變量復(fù)雜樣式用SCSS。主色調(diào)、背景色、文字色這些高頻切換的用CSS變量保證切換流暢陰影、圓角、間距這些不常切換的用SCSS變量保持樣式代碼的可維護(hù)性。還有一個(gè)性能細(xì)節(jié)主題切換時(shí)如果頁(yè)面上有大量使用主題色的元素直接修改變量會(huì)導(dǎo)致大面積重繪。優(yōu)化方式是用transition只對(duì)顏色屬性做過(guò)渡而不是對(duì)所有屬性做過(guò)渡。另外如果主題切換面板是彈窗形式可以在彈窗打開(kāi)時(shí)預(yù)加載主題樣式減少切換時(shí)的等待感。4. 二次改造現(xiàn)有模板時(shí)的拆解策略大多數(shù)情況下我們不是從零搭建而是接手一套現(xiàn)有的模板進(jìn)行改造。這時(shí)候最大的挑戰(zhàn)是模板的代碼風(fēng)格、目錄結(jié)構(gòu)、技術(shù)選型可能和團(tuán)隊(duì)的習(xí)慣不一致直接在上面寫(xiě)業(yè)務(wù)代碼會(huì)越來(lái)越別扭。這一章講的是如何系統(tǒng)性地拆解和改造一套現(xiàn)有模板。4.1 先做減法識(shí)別模板中的冗余依賴拿到一套模板第一步不是急著寫(xiě)業(yè)務(wù)而是做減法。開(kāi)源模板為了展示功能的全面性通常會(huì)引入大量依賴——圖表庫(kù)、富文本編輯器、地圖組件、拖拽庫(kù)等等。這些依賴在你的實(shí)際項(xiàng)目中可能一個(gè)都用不到但它們的代碼會(huì)留在項(xiàng)目里增加構(gòu)建體積和維護(hù)負(fù)擔(dān)。我的做法是先跑一遍npm ls或者用打包分析工具看看依賴樹(shù)然后對(duì)照package.json逐個(gè)確認(rèn)。對(duì)于確定不用的依賴直接卸載同時(shí)刪除對(duì)應(yīng)的示例頁(yè)面和組件。對(duì)于可能用到的依賴先保留但把示例代碼移到單獨(dú)的examples目錄不參與生產(chǎn)構(gòu)建。# 分析打包體積 npx vite-bundle-visualizer # 卸載確認(rèn)不用的依賴 npm uninstall echarts xlsx video.js做減法的時(shí)候要注意一個(gè)坑有些依賴是間接依賴你卸載了直接依賴但間接依賴還在。比如某個(gè)UI組件庫(kù)可能依賴了dayjs你卸載了組件庫(kù)但dayjs還在。所以卸載之后要重新跑一次構(gòu)建確認(rèn)沒(méi)有報(bào)錯(cuò)并且檢查打包體積是否真的下降了。4.2 再調(diào)結(jié)構(gòu)把模板代碼和業(yè)務(wù)代碼隔離減法做完之后下一步是隔離。模板自帶的代碼布局、路由、權(quán)限、工具函數(shù)和你的業(yè)務(wù)代碼要分開(kāi)存放避免混在一起。我的做法是建一個(gè)src/framework目錄把模板的核心代碼移進(jìn)去業(yè)務(wù)代碼放在src/modules下面。src/ ├── framework/ # 模板核心代碼盡量不改 │ ├── layout/ │ ├── router/ │ ├── store/ │ ├── directives/ │ └── utils/ ├── modules/ # 業(yè)務(wù)代碼 │ ├── user/ │ └── order/ └── shared/ # 業(yè)務(wù)公共代碼 ├── components/ └── api/這樣隔離的好處是當(dāng)模板需要升級(jí)時(shí)你只需要替換framework目錄業(yè)務(wù)代碼不受影響。當(dāng)然實(shí)際升級(jí)時(shí)可能還是會(huì)有API變化但至少邊界是清晰的你知道哪些代碼是模板的、哪些是自己的。隔離的過(guò)程中還要注意樣式的隔離。模板的全局樣式可能會(huì)影響業(yè)務(wù)組件的樣式比如模板定義了body的字體大小你的業(yè)務(wù)組件可能不希望繼承。解決方式是在業(yè)務(wù)組件里用scoped樣式或者用CSS Module避免全局污染。4.3 后補(bǔ)測(cè)試給核心鏈路加上回歸保障改造現(xiàn)有模板最大的風(fēng)險(xiǎn)是你改了一個(gè)地方不知道會(huì)不會(huì)影響其他功能。比如你調(diào)整了路由守衛(wèi)的邏輯可能導(dǎo)致某個(gè)頁(yè)面的權(quán)限判斷失效你修改了請(qǐng)求攔截器可能導(dǎo)致某個(gè)接口的token攜帶方式變了。這些問(wèn)題的共同點(diǎn)是改動(dòng)的影響范圍不明確。給核心鏈路加測(cè)試是解決這個(gè)問(wèn)題的有效手段。不需要追求覆蓋率只需要覆蓋幾條關(guān)鍵路徑登錄流程、權(quán)限過(guò)濾、路由跳轉(zhuǎn)、請(qǐng)求攔截。用Vitest或者Jest寫(xiě)單元測(cè)試用Playwright或者Cypress寫(xiě)端到端測(cè)試。// 測(cè)試路由守衛(wèi)的權(quán)限過(guò)濾 describe(permission guard, () { it(should redirect to 403 when role not allowed, async () { const to { path: /user/list, meta: { roles: [admin] } } const next vi.fn() store.getters.role guest await permissionGuard(to, from, next) expect(next).toHaveBeenCalledWith(/403) }) })測(cè)試的另一個(gè)好處是它強(qiáng)迫你把邏輯從組件里抽離出來(lái)。因?yàn)榻M件內(nèi)部的邏輯很難單獨(dú)測(cè)試只有抽成獨(dú)立的函數(shù)或模塊才能方便地寫(xiě)測(cè)試。這個(gè)過(guò)程本身就會(huì)讓代碼結(jié)構(gòu)變得更好。5. 那些文檔里不會(huì)寫(xiě)的踩坑記錄這一章記錄的是我在實(shí)際項(xiàng)目中使用和改造后臺(tái)模板時(shí)踩過(guò)的坑。這些問(wèn)題在官方文檔里基本找不到但每一個(gè)都真實(shí)地浪費(fèi)過(guò)我的時(shí)間。5.1 動(dòng)態(tài)路由刷新后丟失的三種解法對(duì)比動(dòng)態(tài)路由的一個(gè)經(jīng)典問(wèn)題是用戶登錄后動(dòng)態(tài)添加了路由一切正常但刷新頁(yè)面后動(dòng)態(tài)路由丟失了頁(yè)面變成空白或者跳轉(zhuǎn)到404。原因是動(dòng)態(tài)路由是運(yùn)行時(shí)添加的刷新后Vue實(shí)例重新創(chuàng)建之前添加的路由自然就沒(méi)了。解法有三種。第一種是在路由守衛(wèi)里判斷如果已登錄但動(dòng)態(tài)路由未添加就重新拉取用戶信息并添加路由然后再放行。這種解法的關(guān)鍵是加一個(gè)標(biāo)志位避免重復(fù)添加。router.beforeEach(async (to, from, next) { if (store.token !store.routesLoaded) { await store.loadUserInfo() const routes await store.generateRoutes() routes.forEach(route router.addRoute(route)) store.routesLoaded true next({ ...to, replace: true }) // 重新導(dǎo)航確保新路由生效 } else { next() } })第二種是把動(dòng)態(tài)路由持久化到本地存儲(chǔ)刷新時(shí)直接讀取。這種解法的優(yōu)點(diǎn)是速度快不需要重新請(qǐng)求接口缺點(diǎn)是如果權(quán)限在服務(wù)端發(fā)生了變化本地存儲(chǔ)的數(shù)據(jù)會(huì)過(guò)期。第三種是干脆不用動(dòng)態(tài)路由所有路由都靜態(tài)定義權(quán)限控制只做菜單顯示和按鈕級(jí)別的控制。這種解法的優(yōu)點(diǎn)是簡(jiǎn)單沒(méi)有刷新丟失的問(wèn)題缺點(diǎn)是所有路由的代碼都會(huì)被打包包括用戶沒(méi)有權(quán)限訪問(wèn)的頁(yè)面。我個(gè)人的選擇是第一種配合next({ ...to, replace: true })來(lái)確保新添加的路由立即生效。這里有一個(gè)細(xì)節(jié)replace: true是必須的否則會(huì)在歷史記錄里留下一條多余的記錄用戶點(diǎn)后退會(huì)回到空白頁(yè)。5.2 菜單高亮與面包屑不同步的排查過(guò)程菜單高亮和面包屑是后臺(tái)系統(tǒng)的兩個(gè)基礎(chǔ)功能但它們的數(shù)據(jù)來(lái)源不同——菜單高亮依賴當(dāng)前路由的path面包屑依賴當(dāng)前路由的matched數(shù)組。當(dāng)路由配置有嵌套或者有動(dòng)態(tài)參數(shù)時(shí)兩者容易出現(xiàn)不同步。我遇到過(guò)一個(gè)具體場(chǎng)景用戶列表頁(yè)的路由是/user/list詳情頁(yè)的路由是/user/detail/:id。在詳情頁(yè)時(shí)菜單應(yīng)該高亮“用戶管理”面包屑應(yīng)該顯示“用戶管理 / 用戶詳情”。但實(shí)際表現(xiàn)是菜單沒(méi)有高亮面包屑只顯示了“用戶詳情”。排查過(guò)程是這樣的先看菜單高亮的邏輯發(fā)現(xiàn)它是用route.path去匹配菜單項(xiàng)的index。詳情頁(yè)的path是/user/detail/123而菜單項(xiàng)的index是/user/list自然匹配不上。再看面包屑的邏輯它是遍歷route.matched但詳情頁(yè)的路由是平級(jí)的不在/user的children里所以matched數(shù)組里只有詳情頁(yè)自己。解決方案是調(diào)整路由結(jié)構(gòu)把詳情頁(yè)放到/user的children里同時(shí)設(shè)置meta.activeMenu來(lái)指定高亮的菜單項(xiàng)。{ path: /user, meta: { title: 用戶管理 }, children: [ { path: list, component: UserList, meta: { title: 用戶列表 } }, { path: detail/:id, component: UserDetail, meta: { title: 用戶詳情, activeMenu: /user/list } } ] }菜單高亮?xí)r優(yōu)先讀meta.activeMenu沒(méi)有則用path。面包屑則直接遍歷matched因?yàn)樵斍轫?yè)現(xiàn)在在/user的children里matched數(shù)組會(huì)包含/user和詳情頁(yè)兩條記錄面包屑自然就正確了。5.3 請(qǐng)求攔截器里loading狀態(tài)管理的坑請(qǐng)求攔截器里統(tǒng)一管理loading狀態(tài)是一個(gè)常見(jiàn)的優(yōu)化但這里有一個(gè)坑并發(fā)請(qǐng)求。如果頁(yè)面上同時(shí)發(fā)起了三個(gè)請(qǐng)求第一個(gè)請(qǐng)求開(kāi)始時(shí)顯示loading第一個(gè)請(qǐng)求結(jié)束時(shí)隱藏loading但此時(shí)另外兩個(gè)請(qǐng)求還在進(jìn)行中l(wèi)oading就提前消失了。正確的做法是用一個(gè)計(jì)數(shù)器來(lái)管理loading狀態(tài)。每個(gè)請(qǐng)求開(kāi)始時(shí)計(jì)數(shù)器加一結(jié)束時(shí)減一計(jì)數(shù)器大于零時(shí)顯示loading等于零時(shí)隱藏。let loadingCount 0 let loadingInstance null function showLoading() { if (loadingCount 0) { loadingInstance ElLoading.service({ fullscreen: true }) } loadingCount } function hideLoading() { loadingCount-- if (loadingCount 0 loadingInstance) { loadingInstance.close() loadingInstance null } }還有一個(gè)細(xì)節(jié)有些請(qǐng)求是不需要顯示loading的比如輪詢接口、后臺(tái)靜默刷新。這時(shí)候可以在請(qǐng)求配置里加一個(gè)meta: { silent: true }攔截器里判斷這個(gè)標(biāo)記決定是否走loading邏輯。5.4 表格分頁(yè)與篩選條件聯(lián)動(dòng)的常見(jiàn)錯(cuò)誤后臺(tái)系統(tǒng)里表格分頁(yè)和篩選條件的聯(lián)動(dòng)是一個(gè)高頻場(chǎng)景但很容易寫(xiě)出bug。常見(jiàn)的錯(cuò)誤是用戶在第3頁(yè)修改了篩選條件表格重新請(qǐng)求后應(yīng)該回到第1頁(yè)但代碼里沒(méi)有重置頁(yè)碼導(dǎo)致請(qǐng)求了一個(gè)不存在的頁(yè)碼返回空數(shù)據(jù)。正確的做法是在篩選條件變化時(shí)先把頁(yè)碼重置為1再發(fā)起請(qǐng)求。同時(shí)要注意如果篩選條件是通過(guò)watch監(jiān)聽(tīng)的要避免在初始化時(shí)觸發(fā)多余的請(qǐng)求。watch(() searchForm, () { pagination.current 1 fetchList() }, { deep: true }) // 初始化時(shí)手動(dòng)調(diào)用一次避免watch在初始化時(shí)觸發(fā) onMounted(() { fetchList() })另一個(gè)容易忽略的點(diǎn)是刪除表格中的最后一條數(shù)據(jù)后如果當(dāng)前頁(yè)只剩這一條刪除后應(yīng)該自動(dòng)跳到上一頁(yè)。這個(gè)邏輯需要在刪除成功的回調(diào)里判斷當(dāng)前頁(yè)的數(shù)據(jù)條數(shù)如果刪除后當(dāng)前頁(yè)為空且不是第一頁(yè)就把頁(yè)碼減一重新請(qǐng)求。6. 模板選型與長(zhǎng)期維護(hù)的幾點(diǎn)個(gè)人建議聊完了技術(shù)細(xì)節(jié)最后說(shuō)幾個(gè)偏策略層面的建議。這些是我在多個(gè)項(xiàng)目中積累下來(lái)的判斷不一定適用于所有場(chǎng)景但至少可以幫你少走一些彎路。關(guān)于選型不要只看Star數(shù)和UI美觀度。一個(gè)模板是否適合你的項(xiàng)目關(guān)鍵看三點(diǎn)——它的路由和權(quán)限設(shè)計(jì)是否清晰、它的目錄結(jié)構(gòu)是否支持按模塊拆分、它的依賴是否足夠精簡(jiǎn)。我見(jiàn)過(guò)太多項(xiàng)目因?yàn)檫x了一個(gè)“好看但架構(gòu)混亂”的模板后期維護(hù)成本高得離譜。寧可選一個(gè)UI樸素但架構(gòu)清晰的模板也不要選一個(gè)花哨但代碼糾纏的模板。關(guān)于二次開(kāi)發(fā)改造現(xiàn)有模板時(shí)一定要先做減法再做加法。很多人的習(xí)慣是拿到模板就開(kāi)始加功能結(jié)果模板自帶的示例代碼和業(yè)務(wù)代碼混在一起越寫(xiě)越亂。正確的順序是先刪掉不需要的依賴和示例再隔離模板代碼和業(yè)務(wù)代碼最后才開(kāi)始寫(xiě)業(yè)務(wù)功能。關(guān)于升級(jí)如果你打算長(zhǎng)期使用一套模板建議把模板的更新記錄維護(hù)起來(lái)。每次模板發(fā)布新版本不要直接覆蓋而是先看變更日志評(píng)估影響范圍然后在自己的項(xiàng)目里手動(dòng)應(yīng)用需要的改動(dòng)。因?yàn)槟０迳?jí)可能會(huì)引入不兼容的API變化直接覆蓋風(fēng)險(xiǎn)很大。關(guān)于團(tuán)隊(duì)協(xié)作如果團(tuán)隊(duì)多人協(xié)作建議在項(xiàng)目初期就約定好代碼規(guī)范——路由怎么命名、組件怎么拆分、API怎么組織、樣式怎么寫(xiě)。這些約定寫(xiě)進(jìn)項(xiàng)目的README或者貢獻(xiàn)指南里新成員加入時(shí)先讀一遍。后臺(tái)系統(tǒng)的代碼量通常不小沒(méi)有統(tǒng)一的約定后期維護(hù)會(huì)非常痛苦。一個(gè)實(shí)用的判斷標(biāo)準(zhǔn)如果你接手一個(gè)后臺(tái)項(xiàng)目能在半小時(shí)內(nèi)找到“用戶列表頁(yè)的代碼在哪里”“權(quán)限判斷的邏輯在哪里”“主題色的定義在哪里”那這個(gè)項(xiàng)目的結(jié)構(gòu)就是合格的。如果找了半小時(shí)還沒(méi)找到那說(shuō)明模板的架構(gòu)或者使用方式有問(wèn)題。后臺(tái)管理系統(tǒng)模板這個(gè)領(lǐng)域技術(shù)本身并不復(fù)雜難的是在靈活性和約束性之間找到平衡。約束太少項(xiàng)目會(huì)變得混亂約束太多又會(huì)影響開(kāi)發(fā)效率。好的模板應(yīng)該像一套好的交通規(guī)則——它規(guī)定了你不能往哪走但不會(huì)限制你往哪走。希望這篇文章能幫你在使用和改造后臺(tái)模板時(shí)多一份清晰少踩幾個(gè)坑。