（1）開發階段，介面頻繁變更，每次文件都要更新？好煩。。。
（2）介面文件格式五花八門，完全統一準確無誤？好難。。
（3）維護檔案費時費力還不算產出，毫無動力。。
（1）介面文件幾乎沒見過更新
（2）找介面得直接找對口人
於是乎… qq成為後端聯調的主要工具。
（1）知識不能積澱下來！！！最終介面文件不能從天上掉下來！！！
（2）溝通難免有歧義，呼叫方式、引數易用錯，bug頻發！！！
（3）後人維護困難！！！
（1）根據**生成介面文件！springfox + swaggger ui
（2）引入成本：只在現有業務controller上加一點註解！！！
（3）怎麼實現：且聽下回分解
（1）列印入參log
（2）對引數長度、格式進行校驗，若不過則給fe返回引數錯誤提示
（3）對引數進行業務校驗，若通不過則給fe返回業務校驗錯誤提示
（4）呼叫業務service，獲得返回值
（5）若service異常，則記錄log並給fe返回異常提示
（6）列印出參log
（7）給fe返回結果json資料
（1）面面俱到，但職責不單一，controller裡業務無關的**太多。
（2）單靠約定，並不是所有人都可以如此規範、面面俱到。
（3）對引數長度、格式的校驗太過繁瑣。
（4）通過返回值返回service中的業務校驗結果太複雜
（5）千篇一律的引數列印、異常處理、fe資料返回
（6）不一致的log輸出格式，後期自動化分析和自動報警困難
（1）自動列印controller的入參和出參，統一規範，業務controller裡不用再手寫log了
（2）使用jsr303對引數進行預校驗，不用手寫**判斷字串長度、空串等了。
（3）業務controller裡不再需要對jsr303校驗結果和業務校驗結果進行判斷和返回fe了。
（4）統一處理引數異常、業務異常和系統異常，自動列印異常棧，並返回fe異常提示
（5）統一給fe返回資料，業務controller的方法返回vo即可，不用手動呼叫responsejsonp
（6）業務controller裡依舊可以打log，處理異常，無影響。
前後端分工協作
01 前後端分離的基本概念 前端後端互動，基本上是基於http json的形式。後端專注於提供資料，更重要職責是維護系統架構的穩定，保證資料的安全。前端人員專注於互動，快速響應ui的變化。雙方互動基於http json介面，後端人員基本只對介面負責，無需負責js和html的 前端人員只對介面展示互動...
前後端專案部署實踐
當我們之前的專案前後端 編碼完成。就要最後一步部署。我們先來看一下專案目錄。1.node modules 依賴檔案。這個是依據package.json安裝的。前文介紹到，package.json記錄生產和開發對應的依賴檔名及版本號。node modules體積較大。對於這個專案來說就 150m,在上...
vue 前後端互動模式
介面呼叫方式 url位址格式 schema 協議。例如http，https，ftp等 port 埠，http預設埠80，可以省略 path 路徑，例如 abc a b c query 查詢引數，例如uname lisi age 13 fragment 錨點 雜湊hash 用於定位頁面的某個位置 a ...