1. 不懂前後端分離這篇就夠
前後端分離前我們的開發協作模式一般是這樣的：
前端寫好靜態的HTML頁面賀扮交付給後端開發。靜態頁面可以本地開發，也無需考慮業務邏輯只需要實現View即可。
後端使用模板引擎去套模板，同時內嵌一些後端提供的模板變數和一些邏輯操作。
然後前後端集成對接，遇到問題，前台返工，後台返工。
然後在集成，直至集成成功。
這種模式的問題
在前端調試的時候要安裝完整的一套後端開發工具，要把後端程序完全啟動起來。遇到問題需要後端開發來幫忙調試。我們發現前後端嚴重耦合，還要要求後端人員會一些HTML，JS等前端語言。前端頁面里還嵌入了很多後端的代碼。一旦後端換了一種語言開發，簡直就要重做。
像這種增加了大量的溝通成本，調試成本等，而且前後端的開發進度相互影響，從而大大降低了開發效率。
前後端分離並不只是開發模式，而是web應用的一種架構模式。在開發階段，前後端工程師約定好數據交互介面，實現並行開發和測試；在運行階段前後端分離模式需要對web應用進行分離部署，前後端之前使用HTTP或者其他協議進行交互請求。
1. 客戶端和服務端採用RESTFul API的交互方式進行交互
2. 前後端代碼庫分離
在傳統架構模式中，前後端代碼存放於同一個代碼庫中，甚至是同一工程目錄下。頁面中還夾雜著後端代碼。前後端工程師進行開發時，都必須把整個項目導入到開發工具中。
前後端代碼庫分離，前端代碼中有可以消蘆進行Mock測試(通過構造虛擬測試對 象以簡化測試環境的方法)的偽後端，能支持前端的獨立開發和測試。而後端代碼中除了功能實現外，還有著詳細的測試用例，以保證API的可用性，降低集成風險。
3. 並行開發
在開發期間前後端共同商定好數據介面的交互形式和數據格式。然後實現前後端的並行開發，其中前端工程師在開發完成之後可以獨自進行mock測試，而後端也可以使用Postman等介面測試軟體進行介面自測，然後前後端一起進行功能聯調並校驗格式，最終進行自動化測試。
分離後，開發模式是這樣的
為優質產品打造精益團隊
通過將開發團隊前後端分離化，讓前後端工程師只需要專注於前端或後端的開發工作，是的前後端工程師實現自治，培養其獨特的技術特性，然後構建出一個全棧式的精益開發團隊。
提升開發效率
前後端分離以後，可以實現前後端代碼的解耦，只要前後端溝通約定好應用所需介面以及介面參數，便可以開始並行開發，無需等待對方的開發工作結束。與此同時，即使需求發生變更，只要介面與數據格式不變，後端開發人員就不需要修改代碼，只要前端進行變動即可。如此一來整個應用的開發效率必然會有質的提升。
完美應對復雜多變的前端需求
如果開發團隊能完成前後端分離的轉型，打造優秀的前後端團隊，開發獨立化，讓開發人員做到專注專精，開發能力必然會有所提升，能夠完美應對各種復雜多變的前端需求。
增強代碼可維護性
前後端分離後，應用的代碼不再是前後端混合，只有在運行期才會有調用依賴關系。應用代碼將會變得整潔清晰，不論是代碼閱讀還是代碼維護都會比以前輕松。
使用了前後端分離架構後，除了開發模式的變更，我們在開發的過程中還會遇到哪些問題呢？我們接著往下看。
我們先來看看傳統開發，我們是如何進行用戶認證的
前端登錄，後端根據用戶信息生成一個jsessionid，並保存這個 jsessionid 和對應的用戶id到Session中，接著把 jsessionid 傳給用戶，存入瀏覽器 cookie，之後瀏覽器請求帶上這個cookie，後端根據這個cookie值來查詢用戶，驗證是否過期。
HTTP有一個特性：無狀態的，就是前後兩個HTTP事務它們並不知道對方的信息。而為了維護會話信息或用戶信息，一般可用Cookie和Session技術緩存信息。
- Cookie是存儲在客戶端的
- Session是存儲在服務端的
但這樣做問題就很多，拿拍帶如果我們的頁面出現了 XSS 漏洞，由於 cookie 可以被 JavaScript 讀取，XSS 漏洞會導致用戶 token 泄露，而作為後端識別用戶的標識，cookie 的泄露意味著用戶信息不再安全。盡管我們通過轉義輸出內容，使用 CDN 等可以盡量避免 XSS 注入，但誰也不能保證在大型的項目中不會出現這個問題。
在設置 cookie 的時候，其實你還可以設置 httpOnly 以及 secure 項。設置 httpOnly 後 cookie 將不能被 JS 讀取，瀏覽器會自動的把它加在請求的 header 當中，設置 secure 的話，cookie 就只允許通過 HTTPS 傳輸。secure 選項可以過濾掉一些使用 HTTP 協議的 XSS 注入，但並不能完全阻止。
httpOnly 選項使得 JS 不能讀取到 cookie，那麼 XSS 注入的問題也基本不用擔心了。但設置 httpOnly 就帶來了另一個問題，就是很容易的被 XSRF，即跨站請求偽造。當你瀏覽器開著這個頁面的時候，另一個頁面可以很容易的跨站請求這個頁面的內容。因為 cookie 默認被發了出去。
解決方案
JWT（Json Web Token）
JWT 是一個開放標准(RFC 7519)，它定義了一種用於簡潔，自包含的用於通信雙方之間以 JSON 對象的形式安全傳遞信息的方法。該信息可以被驗證和信任，因為它是數字簽名的。JWTS可以使用秘密（使用HMAC演算法）或公鑰/私鑰對使用RSA或ECDSA來簽名。
- 簡潔(Compact)：可以通過URL, POST 參數或者在 HTTP header 發送，因為數據量小，傳輸速度快。
- 自包含(Self-contained)：負載中包含了所有用戶所需要的信息，避免了多次查詢資料庫。
JWT 組成
JWT由3個子字元串組成，分別為Header，Payload以及Signature，結合JWT的格式即：Header.Payload.Signature。（Claim是描述Json的信息的一個Json，將Claim轉碼之後生成Payload）。
Header
Header是由下面這個格式的Json通過Base64編碼（編碼不是加密，是可以通過反編碼的方式獲取到這個原來的Json，所以JWT中存放的一般是不敏感的信息）生成的字元串，Header中存放的內容是說明編碼對象是一個JWT以及使用「SHA-256」的演算法進行加密（加密用於生成Signature）
- 頭部包含了兩部分，token 類型和採用的加密演算法
- Base64是一種編碼，也就是說，它是可以被翻譯回原來的樣子來的。它並不是一種加密過程。
Payload
Payload是通過Claim進行Base64轉碼之後生成的一串字元串，Claim是一個Json，Claim中存放的內容是JWT自身的標准屬性，所有的標准屬性都是可選的，可以自行添加，比如：JWT的簽發者、JWT的接收者、JWT的持續時間等；同時Claim中也可以存放一些自定義的屬性，這個自定義的屬性就是在用戶認證中用於標明用戶身份的一個屬性，比如用戶存放在資料庫中的id，為了安全起見，一般不會將用戶名及密碼這類敏感的信息存放在Claim中。將Claim通過Base64轉碼之後生成的一串字元串稱作 Payload 。
Signature
Signature是由Header和Payload組合而成，將Header和Claim這兩個Json分別使用Base64方式進行編碼，生成字元串Header和Payload，然後將Header和Payload以Header.Payload的格式組合在一起形成一個字元串，然後使用上面定義好的加密演算法和一個密匙（這個密匙存放在伺服器上，用於進行驗證）對這個字元串進行加密，形成一個新的字元串，這個字元串就是 Signature 。
簽名的目的： 最後一步簽名的過程，實際上是對頭部以及負載內容進行簽名，防止內容被竄改。如果有人對頭部以及負載的內容解碼之後進行修改，再進行編碼，最後加上之前的簽名組合形成新的JWT的話，那麼伺服器端會判斷出新的頭部和負載形成的簽名和JWT附帶上的簽名是不一樣的。如果要對新的頭部和負載進行簽名，在不知道伺服器加密時用的密鑰的話，得出來的簽名也是不一樣的。
三個部分通過.連接在一起就是我們的 JWT 了：
JWT認證
伺服器在生成一個JWT之後會將這個token發送到客戶端機器，在客戶端再次訪問受到JWT保護的資源URL鏈接的時候，伺服器會獲取到這個token信息，首先將Header進行反編碼獲取到加密的演算法，在通過存放在伺服器上的密匙對Header.Payload 這個字元串進行加密，比對token中的Signature和實際加密出來的結果是否一致，如果一致那麼說明該token是合法有效的，認證成功，否則認證失敗。
JWT使用總結
1. 首先，前端通過Web表單將自己的用戶名和密碼發送到後端的介面。這一過程一般是一個HTTP POST請求。建議的方式是通過SSL加密的傳輸（https協議），從而避免敏感信息被嗅探。
2. 後端核對用戶名和密碼成功後，將用戶的id等其他信息作為JWT Payload（負載），將其與頭部分別進行Base64編碼拼接後簽名，形成一個JWT。形成的JWT就是一個形同lll.zzz.xxx的字元串。
3. 後端將JWT字元串作為登錄成功的返回結果返回給前端。前端可以將返回的結果保存在Cookie或localStorage或sessionStorage上，退出登錄時前端刪除保存的JWT即可。
4. 前端在每次請求時將JWT放入HTTP Header中的Authorization位。(解決XSS和XSRF問題)
5. 後端檢查是否存在，如存在驗證JWT的有效性。例如，檢查簽名是否正確；檢查Token是否過期；檢查Token的接收方是否是自己（可選）。
6. 驗證通過後後端使用JWT中包含的用戶信息進行其他邏輯操作，返回相應結果。
JWT和Session方式存儲id的差異
Session方式存儲用戶id的最大弊病在於Session是存儲在伺服器端的，所以需要佔用大量伺服器內存，對於較大型應用而言可能還要保存許多的狀態。一般而言，大型應用還需要藉助一些KV資料庫和一系列緩存機制來實現Session的存儲。
而JWT方式將用戶狀態分散到了客戶端中，可以明顯減輕服務端的內存壓力。除了用戶id之外，還可以存儲其他的和用戶相關的信息，例如該用戶是否是管理員、用戶所在的分組等。雖說JWT方式讓伺服器有一些計算壓力（例如加密、編碼和解碼），但是這些壓力相比磁碟存儲而言可能就不算什麼了。
單點登錄
Session方式來存儲用戶id，一開始用戶的Session只會存儲在一台伺服器上。對於有多個子域名的站點，每個子域名至少會對應一台不同的伺服器，例如：
www.taobao.com，nv.taobao.com，nz.taobao.com，login.taobao.com。所以如果要實現在login.taobao.com登錄後，在其他的子域名下依然可以取到Session，這要求我們在多台伺服器上同步Session。使用JWT的方式則沒有這個問題的存在，因為用戶的狀態已經被傳送到了客戶端。
當客戶端和服務端分開部署到不同伺服器的時候，就會遇到跨域訪問的問題，是由瀏覽器同源策略限制的一類請求場景。
跨域解決方案有很多種，下面使用Nginx反向代理的方案
反向代理
代理訪問其實在實際應用中有很多場景，在跨域中應用的原理做法為：通過反向代理伺服器監聽同埠，同域名的訪問，不同路徑映射到不同的地址，比如，在nginx伺服器中，監聽同一個域名和埠，不同路徑轉發到客戶端和伺服器，把不同埠和域名的限制通過反向代理，來解決跨域的問題：
2. 前後端分離方案以及技術選型
作者：關開發
一.什麼是前後端分離？
理解前後端分離大概可以從3個方面理解：
1. 交互形式
2. 代碼組織形式
3. 開發模式與流程
1.1 交互形式
前後端不分離
後端將數據和頁面組裝、渲染好了之後，向瀏覽器輸出最終的html；瀏覽器接收到後會解析html，解析引入的css、執行js腳本，完成最終的頁面展示。
前後端分離
後端只需要和前端約定好接收以及返回的數據格式（一般用JSON格式），向前端提供API介面。前端就可以通過HTTP請求調用API的方式進行交互。前端獲取到數據後，進行頁面組裝、渲染，最終在瀏覽器呈現。
1.2 代碼組織形式
前後端不分離
在web應用早期的時候，前端頁面以及後台業務數據處理的代碼都放在一個工程下，甚至放在同一目錄下，前端頁面夾雜著後端代碼。前、後端開發工程師都需要把整套代碼導入開發工具才能開發。此階段下前後端代碼以及工作耦合度太高，前端不能獨立開發和測試，後端人員也要依賴前端完成頁面後才能完成開發。最糟糕的情況是前端工程師需要會後端模板技術（jsp），後端工程師還要會點前端技術，需要口頭說明頁面數據介面，才能配合完成開發。否則前端只能當一個「切圖仔」，只輸出HTML、CSS、以及很少量與業核或消務邏輯無關的js；然後由後端轉化為後端jsp，並且還要寫業務的js代碼。
前後端分離
前後端代碼放在不同的工程下，前端代碼可以獨立開發，通過mock/easy-mock技術模擬後端API服務可以獨立運行、測試；後端代碼也可以獨立開發，運行、測試，通過swagger技術能自動生成API文檔供前端閱讀，還可以進行自動化介面測試，保證API的可用性，降低集成風險。
1.3 開發模式與流程
前後端不分離
在項目開發階段，前端根據原型和UI設計稿，編寫HTML、CSS以及少量與業務無關的js（純效果那些），完成後交給後台人員，後台人員將HTML轉為jsp，並通過JSP的模板語法進行數據綁定以及一些邏輯操作。後台完成後，將全部代碼打包，包含前端代碼、後端代碼打成一個war，然後部署到同一台伺服器運行。頂多做一下動靜分離，也就是把圖片、css、js分開部署到nginx。
具體開發流程如下：圖略
前後端分離
實現前後端分離之後，前端根據原型和UI設計稿編寫HTML、CSS以及少量與業務無關的js（純效果那些），後端也同時根據原型進行API設計，並與前端協定API數據規范。等到後台API完成，或僅僅是API數據規范設定完成之後。前端即可通過HTTP調用API，或通過mock數據完成數據組裝以及業務邏輯編寫。前後端可以並行，或者改知前端先行於後端開發了。
具體開發流程如下：圖略
二、前後端分離的好處與壞處。
從上面3個方面對比了之後，前後端分離架構和傳統的web架構相比，有很大的變化，看起來好處多多。到底是分還是不分，我們還是要理性分析是否值得才去做。
從目前應用軟體開發的發展趨勢來看，主要有兩方面需要注意：
· 越來越注重團激用戶體驗，隨著互聯網的發展，開始多終端化。
· 大型應用架構模式正在向雲化、微服務化發展。
我們主要通過前後端分離架構，為我們帶來以下四個方面的提升：
· 為優質產品打造精益團隊
通過將開發團隊前後端分離化，讓前後端工程師只需要專注於前端或後端的開發工作，是的前後端工程師實現自治，培養其獨特的技術特性，然後構建出一個全棧式的精益開發團隊。
· 提升開發效率
前後端分離以後，可以實現前後端代碼的解耦，只要前後端溝通約定好應用所需介面以及介面參數，便可以開始並行開發，無需等待對方的開發工作結束。與此同時，即使需求發生變更，只要介面與數據格式不變，後端開發人員就不需要修改代碼，只要前端進行變動即可。如此一來整個應用的開發效率必然會有質的提升。
· 完美應對復雜多變的前端需求
如果開發團隊能完成前後端分離的轉型，打造優秀的前後端團隊，開發獨立化，讓開發人員做到專注專精，開發能力必然會有所提升，能夠完美應對各種復雜多變的前端需求。
· 增強代碼可維護性
前後端分離後，應用的代碼不再是前後端混合，只有在運行期才會有調用依賴關系。應用代碼將會變得整潔清晰，不論是代碼閱讀還是代碼維護都會比以前輕松。
那麼前後端分離有什麼不好的地方嗎？我目前是沒有想到，除非你說會增加前端團隊的配備，後端工程師會變的不全能。。。
二、前後端分離架構方案。
實現前後端分離，主要是前端的技術架構變化較大，後端主要變為restfull 風格API，然後加上Swagger技術自動生成在線介面文檔就差不多了。
對於目前用於前後端分離方案的前端技術架構主要有兩種：
· 傳統SPA
· 服務端渲染SSR
2.1 傳統SPA
傳統SPA指的是單頁面應用，也就是整個網站只有一個頁面，所有功能都通過這一個頁面來呈現。因為一個人的肉眼，某一個時間點看一個頁面，既然如此何必要不同功能做多個頁面呢？只保留一個頁面作為模板，然後通過路由跳轉來更新這個模板頁面的內容不就可以了嗎？確實如此，現在通過reac全家桶、tvue全家桶，模塊化、路由、wabpack等技術輕而易舉就能實現一個單頁面應用。
單頁面應用的運行流程
1.用戶通過瀏覽器訪問網站url
2.單頁面的html文件（index.html）被下載到瀏覽器，接著下載html裡面引用的css，js。
3.css，js下載到瀏覽器完成之後，瀏覽器開始解析執行js向後端服務非同步請求數據。
4.請求數據完成後，進行數據綁定、渲染，最終在用戶瀏覽器呈現完整的頁面。
2.2 服務端渲染
服務端渲染的方案指的是數據綁定，渲染等工作都放在服務端完成，服務端向瀏覽器輸出最終的html。大家看完這個是不是有個疑問，這不是又回到了前後端不分離的時代了嗎？答案是否定的，因為這里的服務端是用來執行前端數據綁定、渲染的，也就是把瀏覽器的一部分工作分擔到了服務端。而目前具備這只種能力的服務端是NodeJs服務端。
它的原理其實就是在瀏覽器與前端代碼中間插入了一個NodeJs服務端。瀏覽器請求前端頁面時，會先經過NodeJS服務端，由NodeJs去讀取前端頁面，並執行非同步後端API，獲取到數據後進行頁面數據綁定，渲染等工作，完成一個最終的html然後返回瀏覽器，最後瀏覽器進行展示。
服務端渲染應用的運行流程：
1.用戶通過瀏覽器訪問網站url
2.NodeJS服務端接收到請求，讀取到對應的前端html，css，js。
3.NodeJS解析執行js向後端API非同步請求數據。
4.NodeJs請求數據完成之後，進行數據綁定、渲染，得到一個最終的html。
5.NodeJs向瀏覽器輸出html，瀏覽器進行展示。
PS：其實本質就是把前端編寫成一個nodeJs的服務端web應用。實施服務端渲染後，我們最終運行的是一個Nodejs服務端應用。而單頁面應用是把靜態頁面部署到靜態資源伺服器進行運行。
看到這里，你是否又有疑問，為什麼要這么麻煩搞服務端渲染呢？
2.3 SPA與服務端渲染方案對比
SPA的優點是開發簡單，部署簡單；缺點是首次載入較慢，需要較好的網路，不友好的SEO。
so，以下就是使用服務端渲染的理由了（摘取vue官方說法）：
與傳統 SPA (單頁應用程序 (Single-Page Application)) 相比，伺服器端渲染 (SSR) 的優勢主要在於：
· 更好的 SEO，由於搜索引擎爬蟲抓取工具可以直接查看完全渲染的頁面。
請注意，截至目前，Google 和 Bing 可以很好對同步 JavaScript 應用程序進行索引。在這里，同步是關鍵。如果你的應用程序初始展示 loading 菊花圖，然後通過 Ajax 獲取內容，抓取工具並不會等待非同步完成後再行抓取頁面內容。也就是說，如果 SEO 對你的站點至關重要，而你的頁面又是非同步獲取內容，則你可能需要伺服器端渲染(SSR)解決此問題。
· 更快的內容到達時間 (time-to-content)，特別是對於緩慢的網路情況或運行緩慢的設備。
無需等待所有的 JavaScript 都完成下載並執行，才顯示伺服器渲染的標記，所以你的用戶將會更快速地看到完整渲染的頁面。通常可以產生更好的用戶體驗，並且對於那些「內容到達時間(time-to-content) 與轉化率直接相關」的應用程序而言，伺服器端渲染 (SSR) 至關重要。
使用伺服器端渲染 (SSR) 時還需要有一些權衡之處：
· 開發條件所限。瀏覽器特定的代碼，只能在某些生命周期鉤子函數 (lifecycle hook) 中使用；一些外部擴展庫 (external library) 可能需要特殊處理，才能在伺服器渲染應用程序中運行。
· 涉及構建設置和部署的更多要求。與可以部署在任何靜態文件伺服器上的完全靜態單頁面應用程序 (SPA) 不同，伺服器渲染應用程序，需要處於 Node.js server 運行環境。
· 更多的伺服器端負載。在 Node.js 中渲染完整的應用程序，顯然會比僅僅提供靜態文件的 server 更加大量佔用 CPU 資源 (CPU-intensive - CPU 密集)，因此如果你預料在高流量環境 (high traffic) 下使用，請准備相應的伺服器負載，並明智地採用緩存策略。
以vue為例，實施服務端渲染可以查看官方指南： https://ssr.vuejs.org ，或選擇Nuxt.js
2.4 預渲染技術
如果你調研伺服器端渲染 (SSR) 只是用來改善少數營銷頁面（例如 /, /about, /contact 等）的 SEO，那麼你可能需要預渲染。無需使用 web 伺服器實時動態編譯 HTML，而是使用預渲染方式，在構建時 (build time) 簡單地生成針對特定路由的靜態 HTML 文件。優點是設置預渲染更簡單，並可以將你的前端作為一個完全靜態的站點。
如果你使用 webpack，你可以使用 prerender-spa-plugin 輕松地添加預渲染。它已經被 Vue 應用程序廣泛測試 - 事實上，作者是 Vue 核心團隊的成員。
prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin
三、前後端分離技術選型
- artTemplate + bootstrap（不推薦， 不算完全前後端分離）
- vue全家桶（推薦）
- react全家桶 （推薦，生態全）
3. 解決前後端分離開發，後端重定向不到前端頁面問題
公司項目使用的是springboot+angularjs這種前後端不完全分離的開發方式，前段時間把項目改成springboot+vue前後端完全分離，開發過程中有個後端重定向問題。後端項目地址： http://localhost:8080/ ，前端項目地址： http://localhost:9090/ ，比如後端 redirct:"/#/main" 重定向到這個頁面猛核，瀏覽器搏廳重定向的卻是 http://localhost:8080/#/基知隱main 後端項目的地址，找了很久最終在webpack中找到解決方案。
我們可以在 devServer.proxy.onProxyRes 中做處理，配置如下:
4. 如何使用webpack，proxy實現前後端分離，並且方便後期前後端聯調
分離的痛點是分離後，介面提供不及時，文檔不完善，模擬數據不方便等。說一下我們的解決辦法：
1）webpack設置proxy，這個通過webpack文檔或GOOGLE一下可以解決。
2）第二步就是需要在後端提供介面及數據和介面文檔，而因為寬賀前後端很可能是並行開發的，所以在真實介面出來蘆源之前需要前端模擬介面及數據，及數據文檔然後在真實介面出來後，切換到真實介面調試，我們之前也遇到過此問題，所以抽時間自己做了個mocksever 系統，功能包括:
支持可視化編輯JSON介面數據及介面文檔
支持GET、POST、PUT、DELETE請求類型
支持指定返回狀態碼，默認200
支持延時返回數據
支持mockjs
支持單個介面代理到真實伺服器(開發過程中某個介面使用模擬數據,當此慎嘩派介面已開發完成後,可將指定介面,通過此服務指向到真實介面上)
5. VB.Net 前後端分離怎麼實現的
1.一般來說，要實現前後端分離，前端就需要開啟一個本地的伺服器來運行自己的前端代碼，以此來模擬真實的線上環境，並且，也是為了更好的開發。因為你在實際開發中，你不可能要求每一個前端都去搭建一個java(php)環境，並且在java環境下開發，這對於前端來說，學習成本太高了。
?2.但如果本地沒有開啟伺服器的話，不僅無法模擬線上的環境，而且還面臨到了跨域的問題，因為你如果寫靜態的html頁面，直接在文件目錄下打開的話，你是無法發出ajax請求的(瀏覽器跨域的限制),因此，你需要在本地運行一個伺服器，可是又不想搭建陌生而龐大的java環境，怎麼辦法呢？nodejs正好解決了這個問題。在我們項目中，我們利用nodejs的express框架來開啟一個本地的伺服器，然後利用nodejs的一個http-proxy-middleware插件將客戶端發往nodejs的請求轉發給真正的伺服器，讓nodejs作為一個中間層。這樣，前端就可以無憂無慮的開發了
?3.由於前後端分離後，前端和後台同時開發時，就可能遇到前端已經開發好一個頁面了，可是卻等待後台API介面的情況返唯。比如說A是負責前端，B是負責後台，A可能用了一周做好了基本的結構，並且需要API介面聯調後，才能繼續開發，
?4.而此時友運B卻還沒有實現好所需要的介面，這種情況，怎麼辦呢？在我們這個項目里，我們是通過了mock來提供一些假數據，我們先規定好了API介面，設計出了一套API文檔，然後我們就可以通過API文檔，利用mock來返回一些假數據，這樣就可以模擬發送API到接受響應的整一個過程，
?5.因此前端也不需要依賴於後端漏告培開發了，可以獨立開發，等到後台的API全部設計完之後，就可以比較快速的聯調。
6. 解決：登錄參數與實體類屬性不一致的問題（前後端分離）
以表單登陸為例
例如：表單中用戶名使悉灶用userName,密碼使用userPass
而實體類LoginVO中對應的睜則扮屬性分別為：username和password
解決方式有兩種：
一：改變前端每盯滾個輸入框的prop值
二是：後端使用註解來解決。
前端用戶名prop本來使用userName,密碼prop本來使用userPass,分別改成username和password
使用@JsonProperty註解，分別指定前端傳來的userName和userPass
成功解決！
from lj 2021-09-02
7. 如何處理好前後端分離的 API 問題
意義很大，但是你的問題本身認識有偏差。
對於前後端分離，認識上有個誤區，那就是很多人自稱：老早就分離了，全AJAX，使用Angular或者什麼什麼就可以了。
這個說法是不合適的，打個比方，別人問的是「如何解決家禽把蛋生在水草邊的問題？」，但實際上人家養的是鴨子御讓鄭，答題的卻是養雞的，所以回答「不讓去水邊就行了」，這顯然不在點子上。
這兩年業界說的前後端分離，是限於偏展示類的系統（用A代替），而不是應用、管控類Web項目（用B代替），在B類項目里，前後端是天然分離的，對此，除了少部分後端開發人員，基本所有人的認識都是一致的。上一段中這樣回答的人一般都是只做B類項目，在B類項目里，前後端分離是共識，不需要討論。
那麼，剩下的問題就是討論A類項目的前後端分離了。這個問題的核心在什麼地方呢，在於模板的與數據結合的位置，以及，模板的控制權在誰手裡。經過這兩年的討論，基本上我們可以達成的共識就是：模板應當由前端人員去控制，主要原因有兩方面：
- 性能優化（尤其是外部資源的管理與發布，請求合並等等）
- 協作的順暢性（已形成模板的界面片段的返工等問題）
那麼，模板到底應該在什麼地方跟數據結合？
這個問題就比較折騰了，有部分人嘗試像B類項目那樣，使用js模板，然後在瀏覽器端執行，這是存在一些問題的，比如說seo不友好，首屏性能不夠，尤其對於首頁DOM量很大的電商類網站，差距很明顯。
所以還是得把主要的模板放在服務端來執行。在這個過程中，阿里作了一些嘗試，那就是引入Node層，在這一層把模板與數據進行合成，然後瀏覽器拿到的就是生成好的HTML了，但也不是所有HTML都是這么生成好的，還是會有一些內容等到鎮頌了滑睜瀏覽器之後，再用js去載入和生成。