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

有小伙伴想讓松哥幫忙捋一捋這個項目，怎么說呢，如果你看過 vhr 的視頻的話，我覺得這個項目應該是很容易懂的，基本上技術點都是一致的。

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

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

1.1 兩種方案

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

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

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

其中 hr 表就是用戶表，用戶登錄成功之后，可以查詢到用戶的角色，再根據(jù)用戶角色去查詢出來用戶可以操作的菜單(資源)，然后把這些可以操作的資源，組織成一個 JSON 數(shù)據(jù)，返回給前端，前端再根據(jù)這個 JSON 渲染出相應的菜單。以微人事為例，我們返回的 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 在前端中再進行二次處理之后，就可以使用了，前端的二次處理主要是把 component 屬性的字符串值轉為對象。這一塊具體操作大家可以參考微人事項目(具體在：https://github.com/lenve/vhr/blob/master/vuehr/src/utils/utils.js)，我就不再贅述了。

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

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

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

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

[
    {
        "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
        }
    }
]

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

這樣的話，后端只需要在登錄成功后返回當前用戶的角色就可以了，剩下的事情則交給前端來做。不過這種方式有一個弊端就是菜單和角色的關系在前端代碼中寫死了，以后如果想要動態(tài)調整會有一些不方便，可能需要改代碼。特別是大項目，權限比較復雜的時候，調整就更麻煩了，所以這種方式我一般建議在一些簡單的項目中使用。

1.2 菜單分析

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

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

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

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

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

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

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

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

1.3 代碼分析

我們再來看看服務端菜單相關的代碼。

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

但是在這個項目中，菜單沒有固定的層級，可以有 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));
}

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

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

大致就是這樣。

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

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

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

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

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

3. 自定義頁面

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

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

后期再補充。

好啦，這樣，前端 vue 登錄成功之后，就可以看到相應的頁面了，頁面也都可以點擊。

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

4. 項目地址

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

https://github.com/lenve/tienchin