1，傳統(tǒng) Ajax 指的是 XMLHttpRequest(XHR)， 最早出現(xiàn)的發(fā)送后端請求技術(shù)，隸屬于原始js中，核心使用XMLHttpRequest對象，多個請求之間如果有先后關(guān)系的話，就會出現(xiàn)回調(diào)地獄。

JQuery ajax 是對原生XHR的封裝，除此以外還增添了對JSONP的支持。經(jīng)過多年的更新維護，真的已經(jīng)是非常的方便了，優(yōu)點無需多言；如果是硬要舉出幾個缺點，那可能只有：

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

2.基于原生的XHR開發(fā)，XHR本身的架構(gòu)不清晰。

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

4.不符合關(guān)注分離(Separation of Concerns)的原則

5.配置和調(diào)用方式非常混亂，而且基于事件的異步模型不友好。

2.axios它本身具有以下特征：

1.從瀏覽器中創(chuàng)建 XMLHttpRequest

2.支持 Promise API

3.客戶端支持防止CSRF

4.提供了一些并發(fā)請求的接口(重要，方便了很多的操作)

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

6.攔截請求和響應(yīng)

7.轉(zhuǎn)換請求和響應(yīng)數(shù)據(jù)

8.取消請求

9.自動轉(zhuǎn)換JSON數(shù)據(jù)

3.fetch

fetch號稱是AJAX的替代品，是在ES6出現(xiàn)的，使用了ES6中的promise對象。Fetch是基于promise設(shè)計的。Fetch的代碼結(jié)構(gòu)比起ajax簡單多了，參數(shù)有點像jQuery ajax。但是，一定記住fetch不是ajax的進一步封裝，而是原生js，沒有使用XMLHttpRequest對象。

fetch的優(yōu)點：

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

2.更好更方便的寫法

坦白說，上面的理由對我來說完全沒有什么說服力，因為不管是Jquery還是Axios都已經(jīng)幫我們把xhr封裝的足夠好，使用起來也足夠方便，為什么我們還要花費大力氣去學(xué)習(xí)fetch？

我認為fetch的優(yōu)勢主要優(yōu)勢就是：

1. 語法簡潔，更加語義化

2. 基于標(biāo)準(zhǔn) Promise 實現(xiàn)，支持 async/await

3. 同構(gòu)方便，使用 [isomorphic-fetch](https://github.com/matthew-andrews/isomorphic-fetch)

4.更加底層，提供的API豐富(request, response)

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

最近在使用fetch的時候，也遇到了不少的問題：

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

例如：

1)fetch只對網(wǎng)絡(luò)請求報錯，對400，500都當(dāng)做成功的請求，服務(wù)器返回 400，500 錯誤碼時并不會 reject，只有網(wǎng)絡(luò)錯誤這些導(dǎo)致請求不能完成時，fetch 才會被 reject。

2)fetch默認不會帶cookie，需要添加配置項： fetch(url, {credentials: 'include'})

3)fetch不支持abort，不支持超時控制，使用setTimeout及Promise.reject的實現(xiàn)的超時控制并不能阻止請求過程繼續(xù)在后臺運行，造成了流量的浪費

4)fetch沒有辦法原生監(jiān)測請求的進度，而XHR可以

總結(jié)

以上是生活随笔為你收集整理的ajax和fetch哪个好,axios和ajax，fetch的区别的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。