關於前後端分離開發中的許可權處理問題，松哥之前寫過一篇文章和大家聊這個問題：
做許可權管理，乙個核心思想就是後端做許可權控制，前端做的所有工作都只是為了提高使用者體驗，我們不能依靠前端展示或者隱藏乙個按鈕來實現許可權控制，這樣肯定是不安全的。
就像使用者註冊時需要輸入郵箱位址，前端校驗之後，後端還是要校驗，兩個校驗目的不同，前端校驗是為了提高響應速度，優化使用者體驗，後端校驗則是為了確保資料完整性。許可權管理也是如此，前端按鈕的展示/隱藏都只是為了提高使用者體驗，真正的許可權管理需要後端來實現。
這是非常重要的一點，做前後端分離開發中的許可權管理，我們首先要建立上面這樣的思考框架，然後在這樣的框架下，去考慮其他問題。
因此，下文我會和大家分享兩種方式實現動態選單，這兩種方式僅僅只是**如何更好的給使用者展示選單，而不是**許可權管理，因為許可權管理是在後端完成的，也必須在後端完成。
一旦建立起這樣的思考框架，你會發現動態選單的實現辦法太多了。
動態選單就是使用者登入之後看到的選單，不用角色的使用者登入成功之後，會看到不用的選單項，這個動態選單要怎麼實現呢？整體來說，有兩種不同的方案，松哥曾經做過的專案中，兩種方案也都有用過，這裡分別來和大家分享一下。
其中hr表就是使用者表，使用者登入成功之後，可以查詢到使用者的角色，再根據使用者角色去查詢出來使用者可以操作的選單（資源），然後把這些可以操作的資源，組織成乙個 json 資料，返回給前端，前端再根據這個 json 渲染出相應的選單。以微人事為例，我們返回的 json 資料格式如下：
[}],
"meta":}]
這種方式的乙個好處是前端的判斷邏輯少一些，後端也不算複雜，就是乙個 sql 操作，前端拿到後端的返回的選單資料，稍微處理一下就可以直接使用了。另外這種方式還有乙個優勢就是可以動態配置資源-角色以及使用者-角色之間的關係，進而調整使用者可以操作的資源(選單)。
另一種方式就是前端動態渲染，這種方式後端的工作要輕鬆一些，前端處理起來麻煩一些，松哥去年年末幫乙個律所做的乙個管理系統，因為許可權上比較容易，我就採用了這種方案。
這種方式就是我直接在前端把所有頁面都在路由表裡邊定義好，然後在 meta 屬性中定義每乙個頁面需要哪些角色才能訪問，例如下面這樣：
[}],
"meta":}]
這樣的話，後端只需要在登入成功後返回當前使用者的角色就可以了，剩下的事情則交給前端來做。不過這種方式有乙個弊端就是選單和角色的關係在前端**中寫死了，以後如果想要動態調整會有一些不方便，可能需要改**。特別是大專案，許可權比較複雜的時候，調整就更麻煩了，所以這種方式我一般建議在一些簡單的專案中使用。
雖然我在微人事中使用了第一種方式，不過如果小夥伴是乙個新專案，並且許可權問題不是很複雜的話，我還是建議嘗試一下第二種方式，感覺要方便一些。
不過在公司中，動態選單到底在前端做還是後端做，可能會有乙個前後端團隊溝（si）通（bi）的過程，贏了的一方就可以少寫幾行**了。
前後端分離開發中動態選單的兩種實現方案
做許可權管理，乙個核心思想就是後端做許可權控制，前端做的所有工作都只是為了提高使用者體驗，我們不能依靠前端展示或者隱藏乙個按鈕來實現許可權控制，這樣肯定是不安全的。就像使用者註冊時需要輸入郵箱位址，前端校驗之後，後端還是要校驗，兩個校驗目的不同，前端校驗是為了提高響應速度，優化使用者體驗，後端校驗則...
前後端分離開發的利與弊
事物總是多面性的，開發也不例外。現在開發流行前後端分離，分離的好處當然很多 1 後端專注業務及邏輯，前端專注於展示和互動，前後端分離的好處就是專業分工和前端展示可以多樣化。耦合度的降低增加了靈活性 2 前後端分離還是比較適合目前的應用方式 saas化 的。但前後端分離也有很多不利的地方 1 增加靈活...
前後端分離開發中的跨域問題
在controller類上面新增 crossorigin，例如 出現的問題 你可以這樣理解，第一次請求 請求方式為options 的目的是測試介面是否能夠調通，後端不會給它返回任何的資料，而第二次請求才是真正的請求，然後響應頭中就會收到資料 解決跨域問題方案2 使用gateway閘道器來解決，直接在...