摘要：我們都知道因?yàn)橥床呗缘膯栴}，瀏覽器的請(qǐng)求是可能隨便跨域的一定要有跨域頭或者借助，但是，中可以設(shè)置為不跨域，如下所示這樣之后我們會(huì)得到一個(gè)為的返回。

免費(fèi)幫忙內(nèi)推阿里等各大IT公司的崗位，有興趣可以帶簡歷加微信angeltune

前端技術(shù)真是一個(gè)發(fā)展飛快的領(lǐng)域，我三年前入職的時(shí)候只有原生XHR和Jquery ajax，我們還曾被JQuery 1.9版本版本以下不支持大文件請(qǐng)求這個(gè)問題卡了半天（最后自己寫了原生的XHR請(qǐng)求）。一晃眼，JQuery ajax早已不能專美于前，axios和fetch都已經(jīng)開始分別搶占“請(qǐng)求”這個(gè)前端高地。本文將會(huì)嘗試著闡述他們之間的區(qū)別，并給出自己的一些理解。

$.ajax({
   type: "POST",
   url: url,
   data: data,
   dataType: dataType,
   success: function () {},
   error: function () {}
});

這個(gè)我就不用多言了把，是對(duì)原生XHR的封裝，除此以外還增添了對(duì)JSONP的支持。有一說一的說一句，JQuery ajax經(jīng)過多年的更新維護(hù)，真的已經(jīng)是非常的方便了，優(yōu)點(diǎn)無需多言；如果是硬要舉出幾個(gè)缺點(diǎn)，那可能只有

本身是針對(duì)MVC的編程,不符合現(xiàn)在前端MVVM的浪潮

基于原生的XHR開發(fā)，XHR本身的架構(gòu)不清晰，已經(jīng)有了fetch的替代方案

JQuery整個(gè)項(xiàng)目太大，單純使用ajax卻要引入整個(gè)JQuery非常的不合理（采取個(gè)性化打包的方案又不能享受CDN服務(wù)）

盡管JQuery對(duì)我們前端的開發(fā)工作曾有著（現(xiàn)在也仍然有著）深遠(yuǎn)的影響，但是我們可以看到隨著VUE，REACT新一代框架的興起，以及ES規(guī)范的完善，更多API的更新，JQuery這種大而全的JS庫，未來的路會(huì)越走越窄。

總結(jié)：廉頗老矣，尚能飯，但是總有飯不動(dòng)的一天。

axios({
    method: "post",
    url: "/user/12345",
    data: {
        firstName: "Fred",
        lastName: "Flintstone"
    }
})
.then(function (response) {
    console.log(response);
})
.catch(function (error) {
    console.log(error);
});

Vue2.0之后，尤雨溪推薦大家用axios替換JQuery ajax，想必讓Axios進(jìn)入了很多人的目光中。Axios本質(zhì)上也是對(duì)原生XHR的封裝，只不過它是Promise的實(shí)現(xiàn)版本，符合最新的ES規(guī)范，從它的官網(wǎng)上可以看到它有以下幾條特性：

從 node.js 創(chuàng)建 http 請(qǐng)求

支持 Promise API

客戶端支持防止CSRF

提供了一些并發(fā)請(qǐng)求的接口（重要，方便了很多的操作）

這個(gè)支持防止CSRF其實(shí)挺好玩的，是怎么做到的呢，就是讓你的每個(gè)請(qǐng)求都帶一個(gè)從cookie中拿到的key, 根據(jù)瀏覽器同源策略，假冒的網(wǎng)站是拿不到你cookie中得key的，這樣，后臺(tái)就可以輕松辨別出這個(gè)請(qǐng)求是否是用戶在假冒網(wǎng)站上的誤導(dǎo)輸入，從而采取正確的策略。

Axios既提供了并發(fā)的封裝，也沒有下文會(huì)提到的fetch的各種問題，而且體積也較小，當(dāng)之無愧現(xiàn)在最應(yīng)該選用的請(qǐng)求的方式。

總結(jié)：誰敢橫刀立馬，唯我Axios將軍！

fetch號(hào)稱是AJAX的替代品，它的好處在《傳統(tǒng) Ajax 已死，F(xiàn)etch 永生》中提到有以下幾點(diǎn)：

符合關(guān)注分離，沒有將輸入、輸出和用事件來跟蹤的狀態(tài)混雜在一個(gè)對(duì)象里

更好更方便的寫法，諸如：

try {
  let response = await fetch(url);
  let data = response.json();
  console.log(data);
} catch(e) {
  console.log("Oops, error", e);
}

坦白說，上面的理由對(duì)我來說完全沒有什么說服力，因?yàn)椴还苁荍query還是Axios都已經(jīng)幫我們把xhr封裝的足夠好，使用起來也足夠方便，為什么我們還要花費(fèi)大力氣去學(xué)習(xí)fetch？

我認(rèn)為fetch的優(yōu)勢(shì)主要優(yōu)勢(shì)就是：

更加底層，提供的API豐富（request, response）

脫離了XHR，是ES規(guī)范里新的實(shí)現(xiàn)方式

大家都喜歡新的東西，坦白說，作為一個(gè)前端工程師，我在使用原生XHR的時(shí)候，盡管偶爾覺得寫的丑陋，但是在使用了JQuery和axios之后，已經(jīng)對(duì)這一塊完全無所謂了。當(dāng)然，如果新的fetch能做的同樣好，我為了不掉隊(duì)也會(huì)選擇使用fetch。這個(gè)道理其實(shí)很好理解：你有一架殲8，魔改了N次，性能達(dá)到了殲10的水準(zhǔn)，但是要是有個(gè)人給你拿來一架新的殲10，你也會(huì)毫不猶豫的選擇新的殲10——不僅僅是新，也代表了還有新的魔改潛力。

但是我最近在使用fetch的時(shí)候，也遇到了不少的問題：

fetch是一個(gè)低層次的API，你可以把它考慮成原生的XHR，所以使用起來并不是那么舒服，需要進(jìn)行封裝

例如：

1）fetch只對(duì)網(wǎng)絡(luò)請(qǐng)求報(bào)錯(cuò)，對(duì)400，500都當(dāng)做成功的請(qǐng)求，需要封裝去處理
2）fetch默認(rèn)不會(huì)帶cookie，需要添加配置項(xiàng)
3）fetch不支持abort，不支持超時(shí)控制，使用setTimeout及Promise.reject的實(shí)現(xiàn)的超時(shí)控制并不能阻止請(qǐng)求過程繼續(xù)在后臺(tái)運(yùn)行，造成了流量的浪費(fèi)
4）fetch沒有辦法原生監(jiān)測(cè)請(qǐng)求的進(jìn)度，而XHR可以

PS: fetch的具體問題大家可以參考：《fetch沒有你想象的那么美》《fetch使用的常見問題及解決方法》

看到這里，你心里一定有個(gè)疑問，這鬼東西就是個(gè)半拉子工程嘛，我還是回去用Jquery或者Axios算了——其實(shí)我就是這么打算的。但是，必須要提出的是，我發(fā)現(xiàn)fetch在前端的應(yīng)用上有一項(xiàng)xhr怎么也比不上的能力：跨域的處理。

我們都知道因?yàn)橥床呗缘膯栴}，瀏覽器的請(qǐng)求是可能隨便跨域的——一定要有跨域頭或者借助JSONP，但是，fetch中可以設(shè)置mode為"no-cors"（不跨域），如下所示：

fetch("/users.json", {
    method: "post", 
    mode: "no-cors",
    data: {}
}).then(function() { /* handle response */ });

這樣之后我們會(huì)得到一個(gè)type為“opaque”的返回。需要指出的是，這個(gè)請(qǐng)求是真正抵達(dá)過后臺(tái)的，所以我們可以使用這種方法來進(jìn)行信息上報(bào)，在我們之前的image.src方法中多出了一種選擇，另外，我們?cè)趎etwork中可以看到這個(gè)請(qǐng)求后臺(tái)設(shè)置跨域頭之后的實(shí)際返回，有助于我們提前調(diào)試接口（當(dāng)然，通過chrome插件我們也可以做的到）。總之，fetch現(xiàn)在還不是很好用，我嘗試過幾個(gè)fetch封裝的包，都還不盡如人意。

總結(jié)：酋長的孩子，還需成長

如果你是直接拉到文章底部的，只需要知道現(xiàn)在無腦使用axios即可，Jquery老邁笨拙，fetch年輕稚嫩，只有Axios正當(dāng)其年！