01 前後端分離的基本概念
前端後端互動，基本上是基於http+json的形式。後端專注於提供資料，更重要職責是維護系統架構的穩定，保證資料的安全。前端人員專注於互動，快速響應ui的變化。
雙方互動基於http+json介面，後端人員基本只對介面負責，無需負責js和html的**。前端人員只對介面展示互動負責，對於後端http介面如何提供正確的資料無需負責。
前後端分離的主要概念就是：後台只需提供api介面，前端呼叫ajax實現資料呈現。
02 前後端分離的意義
1：徹底解放前端，前端不再需要向後台提供模板或是後台在前端html中嵌入後台**
2：提高工作效率，分工更加明確，前後端分離的工作流程可以使前端只關注前端的事，後台只關心後台的活，兩者開發可以同時進行，在後台還沒有時間提供介面的時候，前端可以先將資料寫死或者呼叫本地的json檔案即可，頁面的增加和路由的修改也不必再去麻煩後台，開發更加靈活。
4：降低維護成本，通過目前主流的前端mvc框架，我們可以非常快速的定位及發現問題的所在，客戶端的問題不再需要後台人員參與及除錯，**重構及可維護性增強。
5、有利於產品的元件化，由於前後端分離，有利於迅速二次開發推出新產品。
6、減少後端新人上手專案的難度，提高產品的可維護性和可拓展性。
03 實現分離的基本合作思路
1、評審階段：產品經理與前後端進行需求評審，各自理解清楚自己的業務量以及聯調的工作量，評估開發時間。
2、開發準備階段：前後端一起商量需求中需要聯調的部分，進行介面的口頭協議交流。
3、介面定義階段：前後端一方中，前後端中的一方根據之前的口頭協議擬定出乙份詳細的介面，並編寫服務介面定義，完成後由另一方確認。有疑問的地方重新商量直至雙方都沒有問題。
4、開發階段：雙方根據協商出來的介面為基礎進行開發，如在開發過程中發現需要新增或刪除一些字段，重複步驟3。
(注意：前端在開發過程中記得跟進介面，mock資料進行本地測試，後端修改介面需要跟前端協商清楚再改。 )
5、聯調階段：雙方獨自的工作完成，開始前後端聯調，如在聯調過程發現有疑問，重複步驟3，直至聯調完成。
6、提測階段：將完成的需求提給測試人員，讓其對該需求進行測試，如發現問題，及時通知開發並讓其修改，直至需求沒有bug。
04 相關問題及解決建議
1、前後端分離會帶來前後端溝通成本的問題，相比不分離，能減少開發的總時間嗎？
能減少開發的總時間，理由如下：
(1)、基於對介面負責的原則，前後端分離後，只需做好各種熟悉領域的事情。
後端專注於提供資料，更重要職責是維護系統架構的穩定，保證資料的安全。
前端人員專注於互動，快速響應ui的變化。
(2)、前後端分離確實會帶來溝通成本的問題，這方面需要前後端遵守合作流程，適應新的合作模式，可以提高溝通效率。總體而言，利大於弊。
2、介面定義階段，介面誰定？
回答：建議後端開發人員定，需要前端人員評審。
3、聯調階段，前端是基於後端的開發人員的機器聯調，還是基於後端乙個開發公共環境聯調？
回答：前端應該基於後端的乙個公共開發環境聯調，理由如下：
(1)、開發過程中，後端開發人員機器環境不穩定，後端人員在調速中會時不時進行斷點除錯，重啟機器的伺服器。
(2)、公共開發環境由開發人員負責更新程式，並需要在更新程式前把**提交**倉庫，這樣有利於前端有乙個實時更新，穩定的除錯環境。
git分工協作
一張很經典的圖 當多人協同工作時，一般有乙個master分支，用於將小夥伴 合併到一起後的dev分支，基於dev分支建立的每位小夥伴各自分支如mybranch。當你剛進入專案組，需要基於dev分支進行開發時，就要 1 轉殖 2 基於dev分支，建立屬於自己的分支 3 基於自己分支開發，再提交到遠端自...
前後端協作新模式的實踐
1 開發階段，介面頻繁變更，每次文件都要更新？好煩。2 介面文件格式五花八門，完全統一準確無誤？好難。3 維護檔案費時費力還不算產出，毫無動力。1 介面文件幾乎沒見過更新 2 找介面得直接找對口人 於是乎 qq成為後端聯調的主要工具。1 知識不能積澱下來！最終介面文件不能從天上掉下來！2 溝通難免有...
前後端 13 前後端小試牛刀
餘生還長，你別慌。別回頭，別糾纏，別念舊。準備工作 對nginx檔案下的nginx.conf進行配置 將檔案拖進vscode中 找到nginx.conf檔案中 server 部分，對其進行修改。server error page 404 404.html redirect server error ...