好多人私信我，是不是北京疫情嚴重被隔離了，這裡先謝謝大家的關係。是因為最近不是要考核了，都在做考核的事情，也在國家應急部對這次南方的洪澇災害進行支援。
這次我們聊一聊litemall中的shiro和自定義註解的組合
通過上面的介紹，我們可以得知，litemall本次採用的方式，是沒有將前端與按鈕的權限一起放到資料庫中，而是將前端的頁面和權限和按鈕權限，通過註解的方式獲取。
通過上面兩張圖我們可以看出，傳統的權限表，是會有接口，按鈕，頁面不同類型的按鈕的。但是我們在第二張圖上，只看到了shiro格式的後臺權限，這裡是資料庫層次上的不通，當然個人更推薦資料庫保存，因為我沒有想litemall 作者這樣開發過，不知奧會不會有什麼不方便的地方，感覺使用作者的方法不是很靈活，優點是不用再去關注前端和按鈕權限的。
我們可以看見作者這裡採用了自定義註解，我先來解釋一下注解：
RetentionPolicy.RUNTIME：註解不僅被保存到class文件中，jvm加載class文件之後，仍然存在
@Target - 標記這個註解應該是哪種 Java 成員，TYPE:用於描述類、接口(包括註解類型) 或enum聲明，METHOD:用於描述方法
@RequiresPermissionsDesc(menu = {"商場管理", "品牌管理"}, button = "查詢")
menu 菜單，button 按鈕，這裡的意思說明，前端的那些按鈕或頁面是可以調用這個接口的。
剛才我們看過資料庫，資料庫中的數據是 admin:brand:list
但是接口返回的和前端獲取到的是 GET /admin/brand/list
說明前端的頁面權限不是資料庫的而是通過處理過返回的，下面的是代碼了的一段debug，我們通過圖中看出，通過toApi()方法，將後端的權限，改成了前端Api權限。 前端獲取對應的權限進行權限管理。
下面兩個截圖是權限由 admin:brand:list 到 GET /admin/brand/list 的大體轉換流程
通過上面的幾個截圖，相信大家對我說的shiro+自定義註解有了基本的了解。
了解完了，我們就要開始思考，思考比看一遍或則敲一遍代碼有意義。
總結梳理：
前端發送請求獲取當前用戶權限-->
後臺shiro進行攔截，查看用戶是否登錄-->
shiro獲取當前用戶信息，獲取角色及後端接口權限-->
檢查緩存中是否已經有當前用戶的前端和按鈕權限-->
沒有通過掃描自定義註解，拿到註解中menu和button的值，進行數據整理-->
整理後的數據和用戶的權限校驗，返回用戶擁有的權限-->
前端拿到權限信息，進行頁面顯示控制。
首先我來總結一下，如果是簡單的項目使用litemall的這種權限方式我覺得挺好，簡單實用。
但是當項目比較大，或者前端使用的插件都不相同，所以有點時候會經常涉及到權限的改動，比方權限過期的問題，這個時候如果使用這種方法，每一次改動都需要修改代碼，在大項目的每一次發版都是嚴謹的，所以就不是很實用了。
看開源項目最重要的目的是學習，然後根據自己的實際清空去選擇使用，這裡謝謝作者給提供了一個新的思路。
喜歡點下關注，你的關注是我寫作的最大支持