記一次先後端分離開發中遇到的各類坑

越學習越感受本身瞭解的少，學習的知識不夠紮實，之前老是感受本身瞭解CORS，先後臺交互遇到那個經典的錯誤信息腦海中就會想起須要後臺設置 cors 錯誤和代碼以下。

 解決的方案也是隨口說來，也就是在後臺設置上以下相似的代碼，

1 res.header("Access-Control-Allow-Origin", "*");

 直到這一次項目..搞得我是真的難受，這一篇文章原本想詳細寫一些 CORS的東西的，沒想到跑題了。

提及來從開始接觸node到如今也有一年多的時間了，平時也是常常看文章，看書中的知識一直積累着知識。通常的後臺的東西也是知道一些的，也能夠作一作。

這一次項目和java後臺對接一個手機端h5的微信公衆號的項目，後臺三個，前端三個，歷時三週，固然我是最菜的那個。

咱們是先後端分離開發，咱們在深圳，後臺在雲南。分離的也夠完全了吧。

平時遇到問題你聽不懂我在說什麼，咱們也不知道大家在幹什麼，常常深刻交流到晚上十一點以後，好在咱們都年輕，經得起折騰。好了不說廢話了，說一說此次遇到的各類問題，在這裏作一下總結。

咱們和後臺關係挺好的，每次的問題都是你們一塊兒努力解決，雖然好多問題，可是仍是一條心，挺好的。

 

1、UI圖 VS 業務

咱們是使用vue-cli開發的項目，(用框架寫代碼仍是很舒服的)剛開始開發幾天咱們解決了前端的靜態頁面，原本以前咱們都是前端來定義項目中的數據格式的，工做不到一年的時間我見到的數據格式不是咱們部長給我定義的，就是在我定義以後詢問他通過他幾回修改的，因此也沒有想那麼多，感受數據都挺好的， 此次後臺都沒有看到UI圖，直接根據業務來寫出來的數據接口。我是真的難受了，幾張錶鏈接一下把全部的數據都返回出來就算完成了嗎，並且也是剛開始，他們那邊也沒有數據，搞得好多字段所有都是 null，弄的頁面非常蛋疼。

一週多的時間都是在企業微信羣裏面問數據接口好了嗎？截圖噼裏啪啦的就懟上去幾張。我仍是感受數據庫的關係表要按照正常的來定義，可是返給前臺的數據格式仍是讓一些經驗豐富的前端來定義好一些，由於此次他們根本都沒有看UI圖致使感受全部的接口都被從新寫了一遍同樣。並且那種格式也就是連表查詢吧。須要什麼加什麼。

 

2、跨域問題

搞不懂爲何在node中那麼簡單的幾行代碼能夠解決跨域的問題，到了java那裏有那麼麻煩嗎。設置一下容許全部的域訪問就能夠了，後來看到他的代碼也就是加了幾個東西，他的截圖。就這一張吧

感受也就是這個不知道他們是否是沒有作過相似的東西，跟他們說跨域，啊？我用PostMan能夠訪問的到啊。我訪問你妹哦。大家怎麼寫的，而後截圖Postman的截圖，咱們寫代碼使用大家的測試工具寫嗎。

 

3、token的驗證

由於咱們作了token驗證，我不知道真正的是否是這樣的，我以前作了兩次都是咱們這樣的。

我不知道那個發送過時（或者錯誤的）後臺要返給咱們一個固定的狀態表明這個token過時了這一步是否是必要的，我以前作的都是這樣的，因此此次也讓他們改了，他們以前都沒有作發送過時token要怎麼樣的感受，並且這個token的接口和另外請求數據的接口在服務器的不一樣的端口上面。

前端這裏最開始是我在搞，最後面就不是我在弄了，由於他們後臺的驗證token的那些東西沒有作好卡了咱們四天多進度，後面仍是讓後臺先把這個東西去掉測試的其餘的東西，昨天他們才加上的token，直到今天才剛把這個發佈到生產環境中。

不知道他們那裏怎麼作的，只要帶上 Authorization 就不會跨域，只要不帶這個東西就會報跨域的錯誤。指了好屢次，說把那個跨域的東西放到這個token的前面，也不知道他們怎麼搞得，也不懂他們的代碼。

 

4、老花眼

有接口文檔老是對錯名字，搞半天還要後臺那裏給我找問題，有一個接口他們那裏字母寫錯了，我這裏搞很久不知道哪裏錯了，兩我的找半天，還有就是我寫錯了。

 

5、post請求數據格式

用jQuery的ajax和 axios的請求有一點不同，他們請求數據是不同的。用jQuery請求的話默認的是application/x-www-form-urlencoded的（這裏以前寫錯了，通過指正修改了），用axios就是json格式。咱們是用的axios，後臺那裏識別不了json格式的。這個東西也搞了近一天當時。。我也真的是有點難受。要仔細好好看請求頭信息。

 

要仔細看好這兩種是不同的。

 

6、上傳圖片文件

說真的，以前工做中作的東西上傳圖片這個東西用的最多的仍是微信自帶的那個上傳圖片，拿到那個文件信息直接上傳就行了，在瀏覽器裏面以前上傳過一次是上傳的 base64 位的轉碼轉成圖片了。這一次後臺又是在postman裏面測試的，當時也不知道怎麼去寫，好在知道了  FormData 這個對象能夠模擬form表單發送數據。

 

7、vuex

在項目開始的時候都應該先看看要不要用這個東西，因爲要緩存數據，在後期的時候又加上這個東西，咱們三我的只有我用了，他們也有好多跨頁面的數據要保存，後面只有我本身用了一點這個。若是一開始就規定好這個就好一些了。

 

8、axios的options請求

 我覺得只有axios有那個options請求來檢測是否跨域。原來這個東西是 CORS 規範規定的，引用一下阮一峯大佬的話。

 跨域資源共享 CORS 詳解   http://www.ruanyifeng.com/blog/2016/04/cors.html  點擊連接進入

 

瀏覽器將CORS請求分紅兩類：簡單請求（simple request）和非簡單請求（not-so-simple request）。

只要同時知足如下兩大條件，就屬於簡單請求。

（1) 請求方法是如下三種方法之一：

• HEAD
• GET
• POST

（2）HTTP的頭信息不超出如下幾種字段：

• Accept
• Accept-Language
• Content-Language
• Last-Event-ID
• Content-Type：只限於三個值application/x-www-form-urlencoded、multipart/form-data、text/plain

凡是不一樣時知足上面兩個條件，就屬於非簡單請求。

瀏覽器對這兩種請求的處理，是不同的。

 

 

9、Request header filed Authorization is not allowed by Access-Control-Allow-Headers in pregglight response

 

原本這個錯誤沒有什麼打大不了的，真的是倒黴。確定不是前端的問題，這個也是我這裏想要重點講一下的東西。坑死人。

1 res.header("Access-Control-Allow-Origin", "*");
2 res.header("Access-Control-Allow-Headers", "Content-Type,Content-Length, Authorization, Accept,X-Requested-With");
3 res.header("Access-Control-Allow-Methods","PUT,POST,GET,DELETE,OPTIONS");

以前那個 Access-Control-Allow-Origin : * 這裏的*能夠表明容許全部的origin訪問。

我說讓後臺那裏加上  Access-Control-Allow-Headers： Authorization 這個東西應該就能夠了，他加了一個 * ，也就是下面的相似的這樣

說這個*能夠表明全部的東西，找了快一天的緣由了，後來又讓他加上了另一個響應頭。

理所固然的都是不行的，後來終於找到了官網上面的文檔。終於找到錯誤的緣由了。

 

能夠看到響應頭那裏是一個 * 

我相信只要是咱們項目成員的人看到這個截圖絕對會終身難忘，確定會想起我了，真的把人卡死了要。

除了那個 容許全部的域能夠用 * 來表示，其餘的都不能夠，都必需要一個一個寫出來，後臺改了以後這個token終於加上去了。

其餘還有一些粗心的小問題,也就想起來這麼多。

 

原本這篇文章想着重寫一下最後一個問題的心路歷程的，可是寫着寫着寫跑偏了，咱們的人都挺有耐心的，也總算開發完了，把項目成果的一個二維碼截圖放到這裏，也不知道之後能夠不能夠訪問到。

還好咱們團隊有一個厲害的人，能堅持住，後臺開發的同事也很好，接口調整的也很是及時，只要好好溝通，不要急眼，確定會成功上線的。

2019.4.9日 20:31 記

微信掃二維碼打開項目測試實例。

 

附加：評論中大哥的指導, 感謝了 @Adming   https://www.cnblogs.com/weapon/

這些全部的「坑」都是你對HTTP協議不瞭解，不熟悉形成的。
不少人不重視基礎，對HTTP協議只瞭解一些皮毛，整天都在折騰各類高大上的框架，張口閉口談的也是各類聽不懂的名詞，彷彿討論HTTP協議就很low同樣。
但你可知道，大家討論的這些各類框架、各類名詞都終都只是HTTP協議不一樣實現方式而已，asp、jsp、php、asp.net(asp.net core) 、nodejs、app、小程序、公衆號、服務號這些耳熟能詳框架（或名詞）那個不是創建在HTTP之上的（或能離開HTTP協議）。
能夠這樣說，作Web開發不深刻理解HTTP協議的人在這個行業的前途有限。
也不是說就必定幹不了這行了，我見過不少掛着「高級」頭銜的前端或後端開發對HTTP協議的瞭解也僅限於知道GET、POST、200、40四、500而已，也能工做，看起來幹得還不錯，但和他們交流起來真的打人的衝動都有。
例如：我寫好一個api接口給他，他說調不通，返回404，我說我那個api接口只接受json格式的數據，他說我是傳的json格式啊，我說必需要在HTTP請求頭加入Content-Type:application/json，他說不會，還說我要求多，又說請求是組件封裝好了的，無法加，老子隨手百度一下他用的那個組件的用法而後寫個示例給他就或以了（我很確定一個成熟的前端HTTP組件不可能弱智到連設置經常使用的HTTP頭都不行）。
反之，你理解了HTTP協議就是找到了Web開發的捷徑，一個一通百通的閥門，深刻了解HTTP協議對Web開發中遇到的不少問題跟本不是問題，就算有問題也能夠很天然的迎刃而解，像做者文章中那些問題，在你深刻了解HTTP協議後我相信你本身都會嘲笑本身，人窮怪屋基,沒米吃怪筲箕,

-------------

別之後了，如今就能夠看，百度一下HTTP協議中文版，內容又很少，抓重點理解就能夠了（後面最好買一本HTTP權威指南之類的書系統學習一下）。其實HTTP協議就那點東西，抓重點理解就行。1.HTTP協議三個最重要的特性：無狀態、短鏈接、單向(只能客戶端請求，服務端在接到請求後處理後返回，不能由服務器端向客戶端推數據)。2.經常使用的請求方式，get、post、put、delete，並瞭解get和post的區別。常見的HTTP狀態碼，200、400、500、40四、403等等。3.無論是請求仍是返回老是包含header和body兩部分，又稱請求頭、請求內容，返回頭，返回內容。header是鍵值對，絕大多數狀況下都是HTTP協議定義好或推薦的用法，只有在極少數的狀況下須要自定義。body的格式通常和header指定的Content-Type值一致。4.關於Content-Type，它的做用是告訴接收方用什麼方式來解析對應的body數據，不少時候能夠省略，但你必定要知道有這個東西。好比：請求頭Content-Type經常使用值有：application/x-www-form-urlencoded(表單提交)、multipart/form-data（文件上傳）、text/plain（純文本）、application/json。返回經常使用的有：text/plain、text/xml、text/html等等（完整的Content-Type列表自行百度，只須要記一些經常使用的就行）。爲何JQuery和axios的默認Content-Type不同呢？由於，JQuery流行的時候尚未大規模的應用先後端分離，全部默認仍是傳統的表單提交方式（Content-Type值是application/x-www-form-urlencoded不是你說的Form-Data），而axios天生就是爲先後端分離而生的，全部默認Content-Type值就是application/json。我強調這一點的緣由就是想說，這個默認在HTTP協議中並無強制規範，都是各個瀏覽器，Web服務器或HTTP組件自行定義的。也許你有疑問，我經過抓包發現好像請求頭或返回頭並無Content-Type樣，那是由於大多數Web服務器或瀏覽器均可以本身根據內容推斷出格式。5.一些其餘經常使用的http header 鍵/值的做用。6.POST Content-Type:Multipart/form-data 有一些特殊，它是在早先的HTTP請求中沒有定義，後來專門添加的用來文件上傳的，詳見RFC1867。7.也就這些了