可以從用戶 體驗、開發效率和運維效率三方面來看待前后端是否分離。

我認為在絕大部分 場景下，前后端分離優于不分離。

接下來我會從三個主要的場景來分 析前后端分離與否：用戶體驗、開發效率和運維效率。

用戶體驗

如果你正在做一個門店點餐系統，那么用戶對該系統最基本的要求就是界面美觀、加載速度快。對于這種側重于前端效果的項目，如果使用傳統的前后端一體項目，界面交互方面，除非有專業的前端程序員，一般的服務端程序員是無法通過JSP來實現如果復雜的前端交互邏輯，并且在其中加上豐富的主題和動效的，極大的可能性就是UI畫的是保時捷，開發出來是夏利。大家可以回憶下10年前的網站風格就可以想象了。加載速度方面，因為資源全部放在服務端，首次加載沒有瀏覽器緩存，需要加載大量的js、css以及靜態資源，這在今天幾乎是不可接受的，即使將資源放在Ngnix服務器，也沒辦法做到極致加速。如果使用的前后端分離的開發模式，前端由前端項目負責，界面交互方面，可以直接使用現有的前端腳手架來實現，業內已經有專門設計師設計的UI框架供選擇，均實現了豐富的動效和復雜交互，一鍵引入即可。加載速度方面，前端資源單獨發布部署，可以通過cdn預熱和極致加速。

如果你正在做一個僅用戶服務端接口調用的工具類項目，那用戶對該系統的基本要求就是能看懂、能操作成功即可，對于這種側重于服務端結果的項目，如果功能變化概率較低，完全可以使用前后端一體開發模式，光速開發上線！一套系統解決所有問題。

如果項目是側重前端交互的，那么最好使用前后端分離，如果項目側重服務端功能，無復雜交互，前后端一體速度更快。它的服務端就是下單支付這種基本邏輯，很明顯，基于傳統前后端一體的JSP模式來實現需要有復雜交互的前端頁面是很難的，難度一在于頁面開發，首先開發html然后由服務端轉化為jsp，實現功能的復雜度已經很高了，美觀程度更無法保證，這對前端有很高的技術要求。難度二在于流暢性，前后端一體項目加載頁面需要經過Nginx打到服務端，如果首次訪問沒有流量器緩存可能需要多次下載靜態資源，頁面加載非常的慢，并且服務端沒辦法解決這個問題。如果選擇前后端分離，前端頁面可以直接使用現有的前端腳手架來實現，各種優秀的前端框架已經支持了絕大部分的UI組件，集成了動效、樣式和交互，綁定服務端數據集即可。加載速度方面前端的資源可以通過cdn加速，實現急速加載。 當然如果你開發的是內部使用的工具類項目，前端邏輯簡單并且變化很少，使用前后端一體效率可能更高。

對于側重前端效果的項目，建議前后端分離。

• 開發效率

前后端一體的項目，僅在前端界面交互簡單且變更頻次低的服務型項目上占有微小優勢，因為此類項目核心是服務，前端僅僅是服務調用入口，只是比postman調用接口稍微產品化一點點的界面而已，不需要投入前端人力，服務端可以順手開發，這種場景下使用jsp成本最低，效率最高。

而對于任意一個對前端界面以及交互又要求，并且會長期迭代的項目，不管項目大小，使用前后端分離的效率都要比前后端一體要高，前后端分離可以通過定義服務接口并行開發，互不影響，實現雙倍提效。專業的人做專業的事，并且專業的領域有更多專業的工具，可以達到事半功倍的效果。

前后端一體的適用場景非常有限，任何一個對前端交互有要求的項目，都應該采用前后端分離的方式去開發。

• 運維效率

前后端一體的項目，前后端完全耦合，一次部署可實現前后端同時上線，但是一旦服務端宕機，前端頁面無法展示，影響全部用戶，而且不管是服務端還是前端的迭代都需要重新發布，無法保證前后端互不影響，增大了迭代風險。

對于前后端分離項目，前后端由不同的應用承載，迭代和發布都可以獨立進行，實現完全解耦，幾乎沒有依賴，服務端宕機可以由前端兜底頁面交互降低影響面，單獨運維極大降低迭代風險，在前端發展到如今，運維工具非常完善，成本很低，相對于諸多風險，單獨運維帶來的成本增加可以忽略不計。前后端分離在絕大部分場景下的運維效率高于前后端一體。

綜上所述，前后端分離在當前的技術環境下已經是大勢所趨，其在用戶體驗、開發效率以及運維效率上均領先于前后端一體的方案，在互聯網技術深度發展的今天，行業對技術人員的要求從技術廣度轉變為技術深度，專業人做專業事，所以，即使小項目也依然推薦前后端分離！

03

淘系技術部  三半

結語

大多數情況下，前后端分離是更加普適、先進且合理的方式。