最近在小伙伴們的強(qiáng)烈要求下，我們研究了下 RuoYi-Vue，感覺真的還挺好玩的，可以算是一個(gè)非常成熟的腳手架了，我們可以基于此快速開發(fā)一個(gè)商用項(xiàng)目。

有小伙伴想讓松哥幫忙捋一捋這個(gè)項(xiàng)目，怎么說呢，如果你看過 vhr 的視頻的話，我覺得這個(gè)項(xiàng)目應(yīng)該是很容易懂的，基本上技術(shù)點(diǎn)都是一致的。

不過最近也剛好有空，博客也不知道寫啥了，那么我試試能不能手把手帶領(lǐng)小伙伴們以 RuoYi-Vue 為腳手架，開發(fā)一個(gè)健身房的會(huì)員管理系統(tǒng)。如果小伙伴們對(duì)此感興趣的話，可以多多點(diǎn)贊轉(zhuǎn)發(fā)，這樣這個(gè)系列就不會(huì)爛尾～另外這個(gè)系列我假設(shè)大家已經(jīng)做過 vhr 項(xiàng)目了，所以一些非?；A(chǔ)的知識(shí)點(diǎn)我就不重復(fù)啰嗦了。

1. 現(xiàn)有動(dòng)態(tài)菜單分析

1.1 兩種方案

動(dòng)態(tài)菜單就是用戶登錄之后看到的菜單，不用角色的用戶登錄成功之后，會(huì)看到不用的菜單項(xiàng)，這個(gè)動(dòng)態(tài)菜單要怎么實(shí)現(xiàn)呢?整體來說，有兩種不同的方案，松哥曾經(jīng)做過的項(xiàng)目中，兩種方案也都有用過，這里分別來和大家分享一下。

1.1.1 后端動(dòng)態(tài)返回

后端動(dòng)態(tài)返回，這是我在微人事中采用的方案。微人事中，權(quán)限管理相關(guān)的表一共有五張表，如下：

其中 hr 表就是用戶表，用戶登錄成功之后，可以查詢到用戶的角色，再根據(jù)用戶角色去查詢出來用戶可以操作的菜單(資源)，然后把這些可以操作的資源，組織成一個(gè) JSON 數(shù)據(jù)，返回給前端，前端再根據(jù)這個(gè) JSON 渲染出相應(yīng)的菜單。以微人事為例，我們返回的 JSON 數(shù)據(jù)格式如下：

[
    {
        "id":2,
        "path":"/home",
        "component":"Home",
        "name":"員工資料",
        "iconCls":"fa fa-user-circle-o",
        "children":[
            {
                "id":null,
                "path":"/emp/basic",
                "component":"EmpBasic",
                "name":"基本資料",
                "iconCls":null,
                "children":[

                ],
                "meta":{
                    "keepAlive":false,
                    "requireAuth":true
                }
            }
        ],
        "meta":{
            "keepAlive":false,
            "requireAuth":true
        }
    }
]

這樣的 JSON 在前端中再進(jìn)行二次處理之后，就可以使用了，前端的二次處理主要是把 component 屬性的字符串值轉(zhuǎn)為對(duì)象。這一塊具體操作大家可以參考微人事項(xiàng)目(具體在：https://github.com/lenve/vhr/blob/master/vuehr/src/utils/utils.js)，我就不再贅述了。

這種方式的一個(gè)好處是前端的判斷邏輯少一些，后端也不算復(fù)雜，就是一個(gè) SQL 操作，前端拿到后端的返回的菜單數(shù)據(jù)，稍微處理一下就可以直接使用了。另外這種方式還有一個(gè)優(yōu)勢就是可以動(dòng)態(tài)配置資源-角色以及用戶-角色之間的關(guān)系，進(jìn)而調(diào)整用戶可以操作的資源(菜單)。

1.1.2 前端動(dòng)態(tài)渲染

另一種方式就是前端動(dòng)態(tài)渲染，這種方式后端的工作要輕松一些，前端處理起來麻煩一些，松哥去年年末幫一個(gè)律所做的一個(gè)管理系統(tǒng)，因?yàn)闄?quán)限上比較容易，我就采用了這種方案。

這種方式就是我直接在前端把所有頁面都在路由表里邊定義好，然后在 meta 屬性中定義每一個(gè)頁面需要哪些角色才能訪問，例如下面這樣：

[
    {
        "id":2,
        "path":"/home",
        "component":Home,
        "name":"員工資料",
        "iconCls":"fa fa-user-circle-o",
        "children":[
            {
                "id":null,
                "path":"/emp/basic",
                "component":EmpBasic,
                "name":"基本資料",
                "iconCls":null,
                "children":[

                ],
                "meta":{
                    "keepAlive":false,
                    "requireAuth":true,
                    "roles":['admin','user']
                }
            }
        ],
        "meta":{
            "keepAlive":false,
            "requireAuth":true
        }
    }
]

這樣定義表示當(dāng)前登錄用戶需要具備 admin 或者 user 角色，才可以訪問 EmpBasic 組件，當(dāng)然這里不是說我這樣定義了就行，這個(gè)定義只是一個(gè)標(biāo)記，在項(xiàng)目首頁中，我會(huì)遍歷這個(gè)數(shù)組做菜單動(dòng)態(tài)渲染，然后根據(jù)當(dāng)前登錄用戶的角色，再結(jié)合當(dāng)前組件需要的角色，來決定是否把當(dāng)前組件所對(duì)應(yīng)的菜單項(xiàng)渲染出來。

這樣的話，后端只需要在登錄成功后返回當(dāng)前用戶的角色就可以了，剩下的事情則交給前端來做。不過這種方式有一個(gè)弊端就是菜單和角色的關(guān)系在前端代碼中寫死了，以后如果想要?jiǎng)討B(tài)調(diào)整會(huì)有一些不方便，可能需要改代碼。特別是大項(xiàng)目，權(quán)限比較復(fù)雜的時(shí)候，調(diào)整就更麻煩了，所以這種方式我一般建議在一些簡單的項(xiàng)目中使用。

1.2 菜單分析

在 RuoYi-Vue 中，采用的是方案一，即和 vhr 的方案是一樣的：服務(wù)端動(dòng)態(tài)返回菜單信息，前端再去渲染就行了。

所以如果我們想要定制自己的項(xiàng)目菜單，那就非常容易了，只需要搞明白這個(gè)項(xiàng)目中的菜單表，然后直接修改菜單表就可以了。

系統(tǒng)的菜單表是 sys_menu，各個(gè)字段含義如下：

這個(gè)我就不多說了，各個(gè)字段的含義作者都寫的很清楚了。對(duì)于一些新手小伙伴，我著重解釋一個(gè)跟前端顯示相關(guān)的字段：

• order_num：這個(gè)菜單項(xiàng)在前端頁面展示的順序，例如一級(jí)菜單系統(tǒng)管理中有用戶管理和菜單管理，那么用戶管理和菜單管理這兩個(gè)子項(xiàng)之間就存在一個(gè)展示順序的問題，這個(gè)字段就是用來解決這個(gè)問題的。
• path：這個(gè)是前端的路由地址，可以簡單理解為前端頁面的跳轉(zhuǎn)地址，假設(shè)系統(tǒng)管理菜單項(xiàng)的 path 為 system，系統(tǒng)管理下有一個(gè)子菜單日志管理，日志管理的 path 為 log，日志管理下有一個(gè)子菜單是操作日志，操作日志的 path 為 operlog，那么最終，前端訪問操作日志時(shí)候的頁面路由地址為 /system/log/operlog。
• component：這是前端的組件地址，因?yàn)榍岸说?vue 文件是動(dòng)態(tài)加載的，這個(gè)參數(shù)表示組件的名稱。

這幾個(gè)參數(shù)可能對(duì)于新手小伙伴不好理解，其他的參數(shù)大家看注釋就明白啥意思了，我也就不啰嗦了。

看明白了表，那么就可以直接上手了，直接在表上改了。

不過作者非常貼心的提供了管理頁面，所以你要是懶得分析表，也可以直接在 系統(tǒng)管理->菜單管理中修改菜單，這個(gè)網(wǎng)頁上的操作就比較簡單了，我就不演示了。

1.3 代碼分析

我們?cè)賮砜纯捶?wù)端菜單相關(guān)的代碼。

菜單主要是有一個(gè)層級(jí)的問題，但是菜單的層級(jí)不會(huì)特別深，太深了前端不僅不好使用，也不方便展示。在 vhr 中，我假設(shè)菜單是三個(gè)層級(jí)，然后用了一個(gè)左連接就將所有的菜單信息查出來了。

但是在這個(gè)項(xiàng)目中，菜單沒有固定的層級(jí)，可以有 N 層，所以查詢也跟 vhr 不太一樣，我們一起來看下。

返回菜單數(shù)據(jù)的接口是 org.javaboy.web.controller.system.SysLoginController#getRouters，我們來看下：

@GetMapping("getRouters")
public AjaxResult getRouters() {
    Long userId = SecurityUtils.getUserId();
    List<SysMenu> menus = menuService.selectMenuTreeByUserId(userId);
    return AjaxResult.success(menuService.buildMenus(menus));
}

具體的實(shí)現(xiàn)代碼我就不說了，這里就和大家說一下他這里的查詢邏輯，這里的核心操作實(shí)際上就兩步：

• menuService.selectMenuTreeByUserId 方法查詢出來當(dāng)前所有的菜單項(xiàng)，這里的查詢思路是根據(jù)當(dāng)前用戶的 id，找到用戶對(duì)應(yīng)的菜單，查詢的時(shí)候只查詢類行為 M 和 C 的菜單項(xiàng)，M 表示目錄(即里邊有子菜單)，C 表示菜單，全部查詢出來之后，再遍歷，歸類，將 C 作為某一個(gè) M 的 children。在松哥的 vhr 里邊，我是直接用了一對(duì)多的思路去查詢的，查詢出來后不用再二次處理，這里則是查詢出來后遞歸處理的，這一塊的實(shí)現(xiàn)思路不同，做過 vhr 項(xiàng)目的小伙伴注意區(qū)分(小伙伴們也可以按照 vhr 的思路來改改這里的邏輯)。
• 由于剛查詢出來的菜單并不滿足前端渲染的要求，所以在 menuService.buildMenus 方法中，再對(duì)剛剛查詢出來的 List 集合進(jìn)行二次處理，這里主要是把 component、path 等屬性的值捋清楚。

大致就是這樣。

2. 自定義菜單數(shù)據(jù)

那我們自己這個(gè)健身會(huì)員的菜單會(huì)有所不同，我想要自己重新定義一下，根據(jù)前面第一小節(jié)的分析，這里我來創(chuàng)建八個(gè)和健身會(huì)員管理系統(tǒng)相關(guān)的菜單，如下：

系統(tǒng)原本的功能被我都收到系統(tǒng)管理這個(gè)菜單。

這個(gè) SQL 腳本是比較簡單的，大家在文末可以下載。我簡單截個(gè)圖大家看下：

根據(jù)第一小節(jié)的分析直接修改表即可(也可以在菜單管理頁面手動(dòng)進(jìn)行添加)。

3. 自定義頁面

后端加了數(shù)據(jù)，前端當(dāng)然也要加頁面。component 字段其實(shí)已經(jīng)暗示了前端的頁面地址，所以，我們根據(jù)后端的 component 字段，來創(chuàng)建前端頁面即可：

每一個(gè) .vue 文件都還沒寫內(nèi)容，就一句話，類似下面這樣：

后期再補(bǔ)充。

好啦，這樣，前端 vue 登錄成功之后，就可以看到相應(yīng)的頁面了，頁面也都可以點(diǎn)擊。

好啦，這樣，我們初步實(shí)現(xiàn)了根據(jù)自己的需求在這個(gè)項(xiàng)目上自定義自己的菜單。

4. 項(xiàng)目地址

最后，文末給出一個(gè)項(xiàng)目地址，大家可以去看看。每篇文章的代碼我都會(huì)提交上去，一步步完善，大家可以據(jù)此看到一個(gè)項(xiàng)目的成長過程，現(xiàn)在 star 就是老粉啦。

https://github.com/lenve/tienchin