摘要：前言做過前后端聯(lián)調(diào)的小伙伴，可能有時會遇到一些問題。它是請求中空行的后面那部分。這就是它向你展示的。值得形式是以的形式提交的。傳遞對象的時候，默認為類型的值，與非時，的區(qū)別。如果是字符串的話，后端解析的內(nèi)容時候，肯定要去解析啦。

做過前后端聯(lián)調(diào)的小伙伴，可能有時會遇到一些問題。例如，我明明傳遞數(shù)據(jù)給后端了，后端為什么說沒收到呢？這時候可能就會就會有小伙伴陷入迷茫，本文從chrome-dev-tools（F12調(diào)試器）中看到的FormData與RequestBody，給小伙伴們提供一種可能的思路。也給小伙伴們提供一些問題的探究方法。

什么是FormData？什么是RequestPayload？不解釋，直接上圖：

因為這里觸及了我的知識盲區(qū)，所以有了本文。這個答案是我在stackoverflow上得到的。首先還是貼問題，貼答案。

What"s the difference between “Request Payload” vs “Form Data” as seen in Chrome dev tools Network tab。
中文翻譯：chrome開發(fā)者工具中的Request Payload與Form Data有什么區(qū)別？

高票回答：

The Request Payload - or to be more precise: payload body of a HTTP Request - is the data normally send by a POST or PUT Request. It"s the part after the headers and the CRLF of a HTTP Request.
A request with Content-Type: application/json may look like this:
POST /some-path HTTP/1.1
Content-Type: application/json

{ "foo" : "bar", "name" : "John" }

If you submit this per AJAX the browser simply shows you what it is submitting as payload body. That’s all it can do because it has no idea where the data is coming from.
If you submit a HTML-Form with method="POST" and Content-Type: application/x-www-form-urlencoded or Content-Type: multipart/form-data your request may look like this:
POST /some-path HTTP/1.1
Content-Type: application/x-www-form-urlencoded

foo=bar&name=John
In this case the form-data is the request payload. Here the Browser knows more: it knows that bar is the value of the input-field foo of the submitted form. And that’s what it is showing to you.
So, they differ in the Content-Type but not in the way data is submitted. In both cases the data is in the message-body. And Chrome distinguishes how the data is presented to you in the Developer Tools.

翻譯過來是說：
Request Payload更準確的說是http request的payload body。一般用在數(shù)據(jù)通過POST請求或者PUT請求。它是HTTP請求中空行的后面那部分。（PS:這里涉及一個http常被問到的問題，http請求由哪幾部分組成，一般是請求行，請求頭，空行，請求體。payload body應該是對應請求體。）

一個請求伴隨著header設(shè)置為Content-Type: application/json時候，看起來可能像這樣：

POST /some-path HTTP/1.1
Content-Type: application/json

{ "foo" : "bar", "name" : "John" }

如果你正常請求一個ajax。瀏覽器會簡單的將你提交的內(nèi)容作為payload展示出來，這就是它所能做的，因為它不知道數(shù)據(jù)來自哪里。

如果你提交了一個html表單并且配置上了method="post"，并且設(shè)置了Content-Type: application/x-www-form-urlencoded或者Content-Type: multipart/form-data。那么你的請求可能長這個樣：

POST /some-path HTTP/1.1
Content-Type: application/x-www-form-urlencoded

foo=bar&name=John

這里的form-data就是request payload。在這里，瀏覽器知道更多：它知道bar是提交表單的輸入字段foo的值。這就是它向你展示的。

所以區(qū)別就是，他們只是因為Content-Type設(shè)置的不同，并不是數(shù)據(jù)提交方式的不同，這兩種提交都會將數(shù)據(jù)放在message-body中。但是chrome瀏覽器的開發(fā)者工具會根據(jù)這個ContentType區(qū)分顯示方式。

好了，到這里我們知道了，其實都是放到了payload中。那么具體有什么區(qū)別呢？為什么有時候后端拿不到值呢？這就不得不說對payload的解析方式了。我們以幾個chrome下的測試案例，來理一理這個邏輯。

    
    
    提交

如果我這里點擊提交按鈕，就會觸發(fā)瀏覽器的提交功能，那結(jié)果是什么樣呢？

可以看到Content-Type為application/x-www-form-urlencoded。
值得形式是以key1=value1&key2=value2的形式提交的。

function submit2() {
    var xhr = new XMLHttpRequest();
    xhr.timeout = 3000;
    var obj = {a: 1, b: 2};
    xhr.open("POST", "/");
    xhr.send(obj);
}

首先我們構(gòu)造一個簡單的函數(shù)，然后觸發(fā)它。通過chrome反饋來看：

1.默認的Content-Type為text/plain。
2.Request Payload會對非字符串做字符串轉(zhuǎn)換。
3.通過xhr.send(JSON.stringify(obj));可修正要發(fā)的內(nèi)容

由于axios已經(jīng)是vue、react的準標配請求方式了，所以這里探究一下它。
首先我門看axios的文檔，當post提交時候可以傳遞什么類型參數(shù)：

注意這個類型，我們分別構(gòu)造兩個場景。對應它。

function submit3() {
    var sence1 = "name=123&val=456";
    var sence2 = {name: 123, val: 456};
    axios.post("/", sence1)
}

分別傳遞字符串與對象，提交post請求，然后觀察結(jié)果:

場景1——傳遞字符串時候的結(jié)果：

場景2——傳遞對象的結(jié)果：

1.當我們傳遞字符串的時候，Content-Type自動轉(zhuǎn)為xxx-form-xxx的形式。當為對象的時候，自動轉(zhuǎn)化為xxx/json。
2.字符串的時候以key1=val1&key2=val2的形式體現(xiàn)，對象以JSON字符串形式體現(xiàn)。

探索了這么多種情況之后，那么我們回顧一下：

1.傳統(tǒng)的ajax請求時候，Content-Type默認為"文本"類型。
2.傳統(tǒng)的form提交的時候，Content-Type默認為"Form"類型。
3.axios傳遞字符串的時候，Content-Type默認為"Form"類型。
4.axios傳遞對象的時候，Content-Type默認為"JSON"類型

1.都只支持字符串類型(以上探究的幾種情況)
2.Form需要傳遞的格式為key1=value1&key2=value2,類似GET請求的QueryString格式
3.非Form一般為JSON.stringify(formDataObject)形式

無論何種形式傳遞，后端解析表單信息的時候，會考慮Content-Type。如果是JSON字符串的話，后端解析payload的內(nèi)容時候，肯定要去解析JSON啦。如果是key1=value1&key2=value2的形式，則需要去分割字符串。

當然這些事情一般后端使用的框架會去處理，但是框架給后端提供取值接口有可能是不同的，所以前端的小伙伴在處理請求問題時，一定要跟后端小伙伴商量好，是用JSON還是FormData哈。

本來只是小小的一個問題，仔細研究起來發(fā)現(xiàn)挺多細節(jié)。今天就花時間整理了一下，希望能給大家一些幫助。碼字不容易，如果感到這篇文章對你有用。點個贊，收個藏唄。