最近我的朋友Jack進入一家新的公司，正好公司項目采用的是前后端分離架構，技術棧是Jack非常熟悉的vue全家桶，后端用的是Java語言。
在前后端開發人員碰面之后，協商確定好了前端需要的數據接口（扯那么多，其實也就是關于json數據的字段的定義），然后前后端程序猿就嗨皮地并線開發去了。
我的朋友Jack他們這家公司做本地旅游項目的，安排到他手上的活兒是該旅游項目的webapp工程。
項目動工伊始，一切都得從頭來做。在公司沒日沒夜的開發了一天之后，Jack在沒有借助vue-cli官方提供的腳手架工具下，徒手從零開始，搭建了一套基于公司特定要求的vue項目的工程架構目錄。（關于如何從零開始搭建vue項目的腳手架工程，后面我會單獨寫一個系列）。
前端項目環境搭建好之后，就正式進入了項目首頁的業務編碼工作。Jack又沒日沒夜的敲了一天代碼之后，首頁header區域、輪播圖以及導航圖標的頁面布局和邏輯開發都實現了，此時他想調用后端數據測試下流程，但是后端程序猿還沒有將該數據的接口開發出來，沒辦法，我的朋友Jack此時只能在本地模擬點假數據，逼格高點的說法叫mock數據。
搗鼓半天，首頁的mock數據終于弄好了，如下圖所示：
但是現在有一個問題讓Jack很困惑，他的axios寫的url路徑是與后端程序猿商量好的絕對路徑（域名+請求路徑+請求參數），因為這是以后真正的請求路徑，所以我朋友Jack又不想先寫本地相對路徑，后期再來修改，萬一后端程序猿開發的慢了，鬼知道到時候有多少接口需要修改，所以他就迷茫不知所措了。
其實，仔細看看，這就是前后端分離中的mock數據和接口聯調的問題。要想弄懂其中緣由，下面讓我們分幾點來聊聊。
之前開發寫代碼的時候，所有的ajax數據都不是后端返回的真實數據，而是我們自己通過接口mock模擬的假數據，當前端的代碼編寫完畢，后端的接口也已經寫好之后，我們就需要把mock數據干掉，嘗試使用后端提供的數據，進行前后端的一個調試，這個過程我們就把它稱之為前后端的接口聯調。
本地的mock數據是黃俊自己寫的，肯定符合前端需求，但是后端接口首先需要測試通不通，還需要測試數據格式對不對，還有后端有沒有填寫足夠的數據，比如寫列表頁，前端想分頁，如果后端就寫了兩條測試數據，你咋整？
所以，Jack需要根據后端對接口的調整，不斷地來回切換url，這樣豈不是還在受后端的影響，還談什么毛線的前后端分離，名存實亡嘛！
首先，我們已經知道，目前的前后端分離的架構應用分為兩種情況：
雖然架構可以采用前后端分離，但是部署有可能就不一樣了，這和項目的大小，公司的情況等等都有關系了，一個百八十人用的小系統，還得兩臺服務器兩個域名，你不覺著浪費嗎？
兩種不同的部署情況直接導致了前期在設計聯調方案的時候就不同了。
如果你們公司的項目在部署時是兩臺服務器對應兩個域名，恭喜你，這是最nice的方案，也是聯調最舒服的方式。
但是，我朋友Jack呆的這家公司是一家剛起步的小公司，肯定是怎么節省成本怎么來，問過后端，才知道他們公司是屬于第二種情況，也就是開發時前后端分離，部署時是一個域名和一臺服務器。知道這個之后，他就明白接下來該怎么操作了。
Jack之前在項目根目錄static文件夾下新建了一個mock文件夾，里面寫了一些json文件，當我們做聯調的時候，這些mock數據就沒用了，我們要把mock數據切換成后端提供給我們的真實的數據。
當我的朋友Jack把static文件夾下的mock數據刪除之后，在運行項目，發現報錯了，瀏覽器告訴他，你訪問的mock下面的index.json文件找不到404。
我們平時本地前端開發環境dev地址大多是 localhost:8080，而后臺服務器的訪問地址就有很多種情況了，比如 后端程序猿本地IP（127.0.0.1:8889），或者外網域名，當前端與后臺進行數據交互時，自然就出現跨域問題（后臺服務沒做處理情況下）。axios不支持jsonp, 所以我們就要使用http-proxy-middleware中間件做代理。
現在通過在前端修改 vue-cli 的配置可解決： vue-cli中的 config/index.js 下配置 dev選項的 {proxyTable}:
proxyTable: {
'/api': {
target: '127.0.0.1:8889', // 真實請求的地址
changeOrigin: true, // 是否跨域
}
}
如果你想在公司的vue項目中實現前后端聯調，不需要再使用類似于fiddler charles的抓包代理工具了，你只需要使用proxyTable這個配置項，把你需要請求的后端的服務器地址寫在target值里就OK了。
解決完跨域問題后，接下來Jack該想想怎么在一臺服務器一個域名下進行聯調的問題了。比較常見的做法是前端在本地修改，本地查看，測試好了以后上傳到服務器，看看線上環境可不可以，OK的話一切都好；不行就本地接著改，然后在上傳。
聯調完之后，如何將前端打包的項目文件發給后端，這里也需要注意兩點：
（1）css、js和圖片等靜態文件
這時候的靜態文件在開發階段不需要任何考慮，按照你喜歡的相對路徑或者相對于項目的根路徑的形式寫就行了，因為早晚還得交給后端。但是，需要注意：
如果你采用 相對項目根路徑的書寫方式來寫你的靜態文件路徑 時，一定要先和后端商量好，將來項目部署的時候他會把你的前端整個項目放在哪里？如果不是根目錄下，你就掛了。比如：你的reset.css的路徑是 /exports/styles/common/reset.css ，后端把你前端項目放在了根目錄下的 frontEnd 文件夾下， reset.css 文件就報404了。
如果后端采用的java，你需要特別注意的是， tomcat的根目錄 并不是 webapps 文件，而后端項目默認是部署在 webapps/ROOT 文件下的，所以你如果使用了相對項目根路徑的書寫方式來寫你的靜態文件路徑時，對不起又是404了。
（2）ajax后端數據
因為現在唯一的一臺服務器還是在后端程序猿那里，所以此時你還是可以寫絕對路徑（域名+請求路徑），利用hosts文件來改變域名映射實現聯調。
看這篇文章的朋友，不管你是在大公司還是在小公司，都需要知道，并不是說你將dist文件打包發給后端就完事了，就不需要了解leader后面操作的點擊部署、合并分支的事兒了。
基礎命令、拉取分支、構建編譯包、copy生產包到服務器、備份資料、啟動腳本、灰度發布、等等流程其實都是很有必要了解的。
要不然最開始沒有這些基礎設施、基礎組件，誰來搭建+運行呢，畢竟還是需要第一批吃螃蟹的人.
即使大公司，也有小團隊的，有的小團隊不一定遵循大公司那一套自動化部署教程，也有自己玩自己的輪子+工具。
就算是大公司， 如果基礎架構組的工具做好了，但是沒有總監以上的大佬面向公司推廣， 這些基礎設施不一定能面向公司內部使用。
基礎設施、基礎組件能夠面向公司內部大量使用，離不開公司高層領導的支撐、當然也有基礎設施團隊的辛苦開發、還需要有使用基礎組件的機遇和業務場景。
總結：當你處在前后端分離的大浪潮下，做前端的要將眼光放在整個項目上，統籌全局，不要偏安一隅，待在前端的小角落里獨自玩耍。
一句話，格局要放大，步子要邁開，然后才是低頭前行。
