XMLHttpRequest對象解析詳情 - 前端,ajax,xmlhttprequest 李不要熬夜博客

<!DOCTYPE html><html><body>    <script>        function reqListener () {            console.log(this);            console.log(this.getAllResponseHeaders());            console.log(this.responseText);        }        var params = "lorem=ipsum&name=binny";        var oReq = new XMLHttpRequest();        oReq.upload.onloadstart = function(){//            alert('onloadstart');        };        oReq.upload.onprogress = function(){            alert('onprogress');        };        oReq.onprogress = function(){            alert('download onprogress');        }        oReq.onload  = reqListener;        oReq.onreadystatechange = function(){            alert(this.readyState);        }        oReq.onerror = function(){            alert('error');        }        oReq.open("POST", "http://localhost:81/DeviceRegisters/ajax", true);        oReq.setRequestHeader("Content-type", "application/x-www-form-urlencoded");         oReq.send(params);    </script></body></html>

什麼是readyState

　　readyState是XMLHttpRequest對象的一個屬性，用來標識當前XMLHttpRequest對象處於什麼狀態。

　　readyState總共有5個狀態值，分別為0~4，每個值代表了不同的含義，如下表所示：

| 0 | 未初始化狀態：此時，已經創建了一個XMLHttpRequest對象 |
| 1 | 準備發送狀態：此時，已經調用了XMLHttpRequest對象的open方法，並且XMLHttpRequest對象已經準備好將一個請求發送到服務器端 |
| 2 | 已經發送狀態：此時，已經通過send方法把一個請求發送到服務器端，但是還沒有收到一個響應 |
| 3 | 正在接收狀態：此時，已經接收到HTTP響應頭部信息，但是消息體部分還沒有完全接收到 |
| 4 | 完成響應狀態：此時，已經完成了HTTP響應的接收 |

什麼是status

　　status是XMLHttpRequest對象的一個屬性，表示響應的HTTP狀態碼。

　　在HTTP1.1協議下，HTTP狀態碼總共可分為5大類，如下表所示：

| 1XX | 服務器收到請求，需要繼續處理。例如101狀態碼，表示服務器將通知客户端使用更高版本的HTTP協議。 |
| 2XX | 請求成功。例如200狀態碼，表示請求所希望的響應頭或數據體將隨此響應返回。 |
| 3XX | 重定向。例如302狀態碼，表示臨時重定向，請求將包含一個新的URL地址，客户端將對新的地址進行GET請求。 |
| 4XX | 客户端錯誤。例如404狀態碼，表示客户端請求的資源不存在。 |
| 5XX | 服務器錯誤。例如500狀態碼，表示服務器遇到了一個未曾預料的情況，導致了它無法完成響應，一般來説，這個問題會在程序代碼出錯時出現。 |

看到標題時，有些同學可能會想：“我已經用xhr成功地發過很多個Ajax請求了，對它的基本操作已經算挺熟練了。” 我之前的想法和你們一樣，直到最近我使用xhr時踩了不少坑兒，我才突然發現其實自己並不夠了解xhr，我知道的只是最最基本的使用。
於是我決定好好地研究一番xhr的真面目，可拜讀了不少博客後都不甚滿意，於是我決定認真閲讀一遍W3C的XMLHttpRequest標準。看完標準後我如同醍醐灌頂一般，感覺到了從未有過的清澈。這篇文章就是參考W3C的XMLHttpRequest標準和結合一些實踐驗證總結而來的。

`Ajax`和`XMLHttpRequest`

我們通常將Ajax等同於XMLHttpRequest，但細究起來它們兩個是屬於不同維度的2個概念。

以下是我認為對Ajax較為準確的解釋：（摘自what is Ajax）
AJAX stands for Asynchronous JavaScript and XML. AJAX is a new technique for creating better, faster, and more interactive web applications with the help of XML, HTML, CSS, and Java Script.

AJAX is based on the following open standards:

Browser-based presentation using HTML and Cascading Style Sheets (CSS).

Data is stored in XML format and fetched from the server.

Behind-the-scenes data fetches using XMLHttpRequest objects in the browser.

JavaScript to make everything happen.

從上面的解釋中可以知道：ajax是一種技術方案，但並不是一種新技術。它依賴的是現有的CSS/HTML/Javascript，而其中最核心的依賴是瀏覽器提供的XMLHttpRequest對象，是這個對象使得瀏覽器可以發出HTTP請求與接收HTTP響應。

所以我用一句話來總結兩者的關係：我們使用XMLHttpRequest對象來發送一個Ajax請求。

`XMLHttpRequest`的發展歷程

XMLHttpRequest一開始只是微軟瀏覽器提供的一個接口，後來各大瀏覽器紛紛效仿也提供了這個接口，再後來W3C對它進行了標準化，提出了XMLHttpRequest標準。XMLHttpRequest標準又分為Level 1和Level 2。
XMLHttpRequest Level 1主要存在以下缺點：

受同源策略的限制，不能發送跨域請求；
不能發送二進制文件（如圖片、視頻、音頻等），只能發送純文本數據；
在發送和獲取數據的過程中，無法實時獲取進度信息，只能判斷是否完成；

那麼Level 2對Level 1 進行了改進，XMLHttpRequest Level 2中新增了以下功能：

可以發送跨域請求，在服務端允許的情況下；
支持發送和接收二進制數據；
新增formData對象，支持發送表單數據；
發送和獲取數據時，可以獲取進度信息；
可以設置請求的超時時間；

`XMLHttpRequest`兼容性

關於xhr的瀏覽器兼容性，大家可以直接查看“Can I use”這個網站提供的結果XMLHttpRequest兼容性，下面提供一個截圖。

[圖片上傳失敗...(image-129fa5-1615342548990)]

從圖中可以看到：

IE8/IE9、Opera Mini 完全不支持xhr對象
IE10/IE11部分支持，不支持 xhr.responseType為json
部分瀏覽器不支持設置請求超時，即無法使用xhr.timeout
部分瀏覽器不支持xhr.responseType為blob

細説`XMLHttpRequest`如何使用

先來看一段使用XMLHttpRequest發送Ajax請求的簡單示例代碼。

function sendAjax() {  //構造表單數據 var formData = new FormData(); formData.append('username', 'johndoe'); formData.append('id', 123456); //創建xhr對象 var xhr = new XMLHttpRequest(); //設置xhr請求的超時時間 xhr.timeout = 3000; //設置響應返回的數據格式 xhr.responseType = "text"; //創建一個 post 請求，採用異步 xhr.open('POST', '/server', true); //註冊相關事件回調處理函數 xhr.onload = function(e) { if(this.status == 200||this.status == 304){ alert(this.responseText); } }; xhr.ontimeout = function(e) { ... }; xhr.onerror = function(e) { ... }; xhr.upload.onprogress = function(e) { ... }; //發送數據 xhr.send(formData); }

上面是一個使用xhr發送表單數據的示例，整個流程可以參考註釋。

接下來我將站在使用者的角度，以問題的形式介紹xhr的基本使用。
我對每一個問題涉及到的知識點都會進行比較細緻地介紹，有些知識點可能是你平時忽略關注的。

如何設置request header

在發送Ajax請求（實質是一個HTTP請求）時，我們可能需要設置一些請求頭部信息，比如content-type、connection、cookie、accept-xxx等。xhr提供了setRequestHeader來允許我們修改請求 header。

void setRequestHeader(DOMString header, DOMString value);

注意點：

方法的第一個參數 header 大小寫不敏感，即可以寫成content-type，也可以寫成Content-Type，甚至寫成content-Type;
Content-Type的默認值與具體發送的數據類型有關，請參考本文【可以發送什麼類型的數據】一節；
setRequestHeader必須在open()方法之後，send()方法之前調用，否則會拋錯；
setRequestHeader可以調用多次，最終的值不會採用覆蓋override的方式，而是採用追加append的方式。下面是一個示例代碼：

var client = new XMLHttpRequest();client.open('GET', 'demo.cgi');client.setRequestHeader('X-Test', 'one'); client.setRequestHeader('X-Test', 'two'); // 最終request header中"X-Test"為: one, two client.send();

如何獲取response header

xhr提供了2個用來獲取響應頭部的方法：getAllResponseHeaders和getResponseHeader。前者是獲取 response 中的所有header 字段，後者只是獲取某個指定 header 字段的值。另外，getResponseHeader(header)的header參數不區分大小寫。

DOMString getAllResponseHeaders();
DOMString getResponseHeader(DOMString header);

這2個方法看起來簡單，但卻處處是坑兒。

你是否遇到過下面的坑兒?——反正我是遇到了。。。

使用getAllResponseHeaders()看到的所有response header與實際在控制枱 Network 中看到的 response header 不一樣
使用getResponseHeader()獲取某個 header 的值時，瀏覽器拋錯Refused to get unsafe header "XXX"

經過一番尋找最終在 Stack Overflow找到了答案。

原因1：W3C的 xhr 標準中做了限制，規定客户端無法獲取 response 中的 Set-Cookie、Set-Cookie2這2個字段，無論是同域還是跨域請求；
原因2：W3C 的 cors 標準對於跨域請求也做了限制，規定對於跨域請求，客户端允許獲取的response header字段只限於“simple response header”和“Access-Control-Expose-Headers” （兩個名詞的解釋見下方）。

"simple response header"包括的 header 字段有：Cache-Control,Content-Language,Content-Type,Expires,Last-Modified,Pragma;
"Access-Control-Expose-Headers"：首先得注意是"Access-Control-Expose-Headers"進行跨域請求時響應頭部中的一個字段，對於同域請求，響應頭部是沒有這個字段的。這個字段中列舉的 header 字段就是服務器允許暴露給客户端訪問的字段。

所以getAllResponseHeaders()只能拿到限制以外（即被視為safe）的header字段，而不是全部字段；而調用getResponseHeader(header)方法時，header參數必須是限制以外的header字段，否則調用就會報Refused to get unsafe header的錯誤。

如何指定`xhr.response`的數據類型

有些時候我們希望xhr.response返回的就是我們想要的數據類型。比如：響應返回的數據是純JSON字符串，但我們期望最終通過xhr.response拿到的直接就是一個 js 對象，我們該怎麼實現呢？
有2種方法可以實現，一個是level 1就提供的overrideMimeType()方法，另一個是level 2才提供的xhr.responseType屬性。

`xhr.overrideMimeType()`

overrideMimeType是xhr level 1就有的方法，所以瀏覽器兼容性良好。這個方法的作用就是用來重寫response的content-type，這樣做有什麼意義呢？比如：server 端給客户端返回了一份document或者是 xml文檔，我們希望最終通過xhr.response拿到的就是一個DOM對象，那麼就可以用xhr.overrideMimeType('text/xml; charset = utf-8')來實現。

再舉一個使用場景，我們都知道xhr level 1不支持直接傳輸blob二進制數據，那如果真要傳輸 blob 該怎麼辦呢？當時就是利用overrideMimeType方法來解決這個問題的。

下面是一個獲取圖片文件的代碼示例：

var xhr = new XMLHttpRequest();//向 server 端獲取一張圖片xhr.open('GET', '/path/to/image.png', true); // 這行是關鍵！ //將響應數據按照純文本格式來解析，字符集替換為用户自己定義的字符集 xhr.overrideMimeType('text/plain; charset=x-user-defined'); xhr.onreadystatechange = function(e) { if (this.readyState == 4 && this.status == 200) { //通過 responseText 來獲取圖片文件對應的二進制字符串 var binStr = this.responseText; //然後自己再想方法將逐個字節還原為二進制數據 for (var i = 0, len = binStr.length; i < len; ++i) { var c = binStr.charCodeAt(i); //String.fromCharCode(c & 0xff); var byte = c & 0xff; } } }; xhr.send();

代碼示例中xhr請求的是一張圖片，通過將 response 的 content-type 改為'text/plain; charset=x-user-defined'，使得 xhr 以純文本格式來解析接收到的blob 數據，最終用户通過this.responseText拿到的就是圖片文件對應的二進制字符串，最後再將其轉換為 blob 數據。

`xhr.responseType`

responseType是xhr level 2新增的屬性，用來指定xhr.response的數據類型，目前還存在些兼容性問題，可以參考本文的【XMLHttpRequest的兼容性】這一小節。那麼responseType可以設置為哪些格式呢，我簡單做了一個表，如下：

值	`xhr.response` 數據類型	説明
`""`	`String`字符串	默認值(在不設置`responseType`時)
`"text"`	`String`字符串
`"document"`	`Document`對象	希望返回 `XML` 格式數據時使用
`"json"`	`javascript` 對象	存在兼容性問題，IE10/IE11不支持
`"blob"`	`Blob`對象
`"arrayBuffer"`	`ArrayBuffer`對象

下面是同樣是獲取一張圖片的代碼示例，相比xhr.overrideMimeType,用xhr.response來實現簡單得多。

var xhr = new XMLHttpRequest();xhr.open('GET', '/path/to/image.png', true); //可以將`xhr.responseType`設置為`"blob"`也可以設置為`" arrayBuffer"` //xhr.responseType = 'arrayBuffer'; xhr.responseType = 'blob'; xhr.onload = function(e) { if (this.status == 200) { var blob = this.response; ... } }; xhr.send();

小結

雖然在xhr level 2中，2者是共同存在的。但其實不難發現，xhr.responseType就是用來取代xhr.overrideMimeType()的，xhr.responseType功能強大的多，xhr.overrideMimeType()能做到的xhr.responseType都能做到。所以我們現在完全可以摒棄使用xhr.overrideMimeType()了。

如何獲取response數據

xhr提供了3個屬性來獲取請求返回的數據，分別是：xhr.response、xhr.responseText、xhr.responseXML

xhr.response
- 默認值：空字符串""
- 當請求完成時，此屬性才有正確的值
- 請求未完成時，此屬性的值可能是""或者 null，具體與 xhr.responseType有關：當responseType為""或"text"時，值為""；responseType為其他值時，值為 null
xhr.responseText
- 默認值為空字符串""
- 只有當 responseType 為"text"、""時，xhr對象上才有此屬性，此時才能調用xhr.responseText，否則拋錯
- 只有當請求成功時，才能拿到正確值。以下2種情況下值都為空字符串""：請求未完成、請求失敗
xhr.responseXML
- 默認值為 null
- 只有當 responseType 為"text"、""、"document"時，xhr對象上才有此屬性，此時才能調用xhr.responseXML，否則拋錯
- 只有當請求成功且返回數據被正確解析時，才能拿到正確值。以下3種情況下值都為null：請求未完成、請求失敗、請求成功但返回數據無法被正確解析時

如何追蹤`ajax`請求的當前狀態

在發一個ajax請求後，如果想追蹤請求當前處於哪種狀態，該怎麼做呢？

用xhr.readyState這個屬性即可追蹤到。這個屬性是隻讀屬性，總共有5種可能值，分別對應xhr不同的不同階段。每次xhr.readyState的值發生變化時，都會觸發xhr.onreadystatechange事件，我們可以在這個事件中進行相關狀態判斷。

  xhr.onreadystatechange = function () {    switch(xhr.readyState){      case 1://OPENED //do something break; case 2://HEADERS_RECEIVED //do something break; case 3://LOADING //do something break; case 4://DONE //do something break; }

值	狀態	描述
`0`	`UNSENT` (初始狀態，未打開)	此時`xhr`對象被成功構造，`open()`方法還未被調用
`1`	`OPENED` (已打開，未發送)	`open()`方法已被成功調用，`send()`方法還未被調用。注意：只有`xhr`處於`OPENED`狀態，才能調用`xhr.setRequestHeader()`和`xhr.send()`,否則會報錯
`2`	`HEADERS_RECEIVED`(已獲取響應頭)	`send()`方法已經被調用, 響應頭和響應狀態已經返回
`3`	`LOADING` (正在下載響應體)	響應體(`response entity body`)正在下載中，此狀態下通過`xhr.response`可能已經有了響應數據
`4`	`DONE` (整個數據傳輸過程結束)	整個數據傳輸過程結束，不管本次請求是成功還是失敗

如何設置請求的超時時間

如果請求過了很久還沒有成功，為了不會白白佔用的網絡資源，我們一般會主動終止請求。XMLHttpRequest提供了timeout屬性來允許設置請求的超時時間。

xhr.timeout

單位：milliseconds 毫秒
默認值：0，即不設置超時

很多同學都知道：從請求開始 算起，若超過 timeout 時間請求還沒有結束（包括成功/失敗），則會觸發ontimeout事件，主動結束該請求。

【那麼到底什麼時候才算是請求開始 ？】
——xhr.onloadstart事件觸發的時候，也就是你調用xhr.send()方法的時候。
因為xhr.open()只是創建了一個連接，但並沒有真正開始數據的傳輸，而xhr.send()才是真正開始了數據的傳輸過程。只有調用了xhr.send()，才會觸發xhr.onloadstart 。

【那麼什麼時候才算是請求結束 ？】
—— xhr.loadend事件觸發的時候。

另外，還有2個需要注意的坑兒：

可以在 send()之後再設置此xhr.timeout，但計時起始點仍為調用xhr.send()方法的時刻。
當xhr為一個sync同步請求時，xhr.timeout必須置為0，否則會拋錯。原因可以參考本文的【如何發一個同步請求】一節。

如何發一個同步請求

xhr默認發的是異步請求，但也支持發同步請求（當然實際開發中應該儘量避免使用）。到底是異步還是同步請求，由xhr.open（）傳入的async參數決定。

open(method, url [, async = true [, username = null [, password = null]]])

method: 請求的方式，如GET/POST/HEADER等，這個參數不區分大小寫
url: 請求的地址，可以是相對地址如example.php，這個相對是相對於當前網頁的url路徑；也可以是絕對地址如http://www.example.com/example.php
async: 默認值為true，即為異步請求，若async=false，則為同步請求

在我認真研讀W3C 的 xhr 標準前，我總以為同步請求和異步請求只是阻塞和非阻塞的區別，其他什麼事件觸發、參數設置應該是一樣的，事實證明我錯了。

W3C 的 xhr標準中關於open()方法有這樣一段説明：

Throws an "InvalidAccessError" exception if async is false, the JavaScript global environment is a document environment, and either the timeout attribute is not zero, the withCredentials attribute is true, or the responseType attribute is not the empty string.

從上面一段説明可以知道，當xhr為同步請求時，有如下限制：

xhr.timeout必須為0
xhr.withCredentials必須為 false
xhr.responseType必須為""（注意置為"text"也不允許）

若上面任何一個限制不滿足，都會拋錯，而對於異步請求，則沒有這些參數設置上的限制。

之前説過頁面中應該儘量避免使用sync同步請求，為什麼呢？
因為我們無法設置請求超時時間（xhr.timeout為0，即不限時）。在不限制超時的情況下，有可能同步請求一直處於pending狀態，服務端遲遲不返回響應，這樣整個頁面就會一直阻塞，無法響應用户的其他交互。

另外，標準中並沒有提及同步請求時事件觸發的限制，但實際開發中我確實遇到過部分應該觸發的事件並沒有觸發的現象。如在 chrome中，當xhr為同步請求時，在xhr.readyState由2變成3時，並不會觸發 onreadystatechange事件，xhr.upload.onprogress和 xhr.onprogress事件也不會觸發。

如何獲取上傳、下載的進度

在上傳或者下載比較大的文件時，實時顯示當前的上傳、下載進度是很普遍的產品需求。
我們可以通過onprogress事件來實時顯示進度，默認情況下這個事件每50ms觸發一次。需要注意的是，上傳過程和下載過程觸發的是不同對象的onprogress事件：

上傳觸發的是xhr.upload對象的 onprogress事件
下載觸發的是xhr對象的onprogress事件

xhr.onprogress = updateProgress;xhr.upload.onprogress = updateProgress;function updateProgress(event) {    if (event.lengthComputable) { var completedPercent = event.loaded / event.total; } }

可以發送什麼類型的數據

void send(data);

xhr.send(data)的參數data可以是以下幾種類型：

ArrayBuffer
Blob
Document
DOMString
FormData
null

如果是 GET/HEAD請求，send()方法一般不傳參或傳 null。不過即使你真傳入了參數，參數也最終被忽略，xhr.send(data)中的data會被置為 null.

xhr.send(data)中data參數的數據類型會影響請求頭部content-type的默認值：

如果data是 Document 類型，同時也是HTML Document類型，則content-type默認值為text/html;charset=UTF-8;否則為application/xml;charset=UTF-8；
如果data是 DOMString 類型，content-type默認值為text/plain;charset=UTF-8；
如果data是 FormData 類型，content-type默認值為multipart/form-data; boundary=[xxx]
如果data是其他類型，則不會設置content-type的默認值

當然這些只是content-type的默認值，但如果用xhr.setRequestHeader()手動設置了中content-type的值，以上默認值就會被覆蓋。

另外需要注意的是，若在斷網狀態下調用xhr.send(data)方法，則會拋錯：Uncaught NetworkError: Failed to execute 'send' on 'XMLHttpRequest'。一旦程序拋出錯誤，如果不 catch 就無法繼續執行後面的代碼，所以調用 xhr.send(data)方法時，應該用 try-catch捕捉錯誤。

try{    xhr.send(data)  }catch(e) {    //doSomething...  };

`xhr.withCredentials`與 `CORS` 什麼關係

我們都知道，在發同域請求時，瀏覽器會將cookie自動加在request header中。但大家是否遇到過這樣的場景：在發送跨域請求時，cookie並沒有自動加在request header中。

造成這個問題的原因是：在CORS標準中做了規定，默認情況下，瀏覽器在發送跨域請求時，不能發送任何認證信息（credentials）如"cookies"和"HTTP authentication schemes"。除非xhr.withCredentials為true（xhr對象有一個屬性叫withCredentials，默認值為false）。

所以根本原因是cookies也是一種認證信息，在跨域請求中，client端必須手動設置xhr.withCredentials=true，且server端也必須允許request能攜帶認證信息（即response header中包含Access-Control-Allow-Credentials:true），這樣瀏覽器才會自動將cookie加在request header中。

另外，要特別注意一點，一旦跨域request能夠攜帶認證信息，server端一定不能將Access-Control-Allow-Origin設置為*，而必須設置為請求頁面的域名。

`xhr`相關事件

事件分類

xhr相關事件有很多，有時記起來還挺容易混亂。但當我瞭解了具體代碼實現後，就容易理清楚了。下面是XMLHttpRequest的部分實現代碼：

interface XMLHttpRequestEventTarget : EventTarget {  // event handlers attribute EventHandler onloadstart; attribute EventHandler onprogress; attribute EventHandler onabort; attribute EventHandler onerror; attribute EventHandler onload; attribute EventHandler ontimeout; attribute EventHandler onloadend; }; interface XMLHttpRequestUpload : XMLHttpRequestEventTarget { }; interface XMLHttpRequest : XMLHttpRequestEventTarget { // event handler attribute EventHandler onreadystatechange; readonly attribute XMLHttpRequestUpload upload; };

從代碼中我們可以看出：

XMLHttpRequestEventTarget接口定義了7個事件：
- onloadstart
- onprogress
- onabort
- ontimeout
- onerror
- onload
- onloadend
每一個XMLHttpRequest裏面都有一個upload屬性，而upload是一個XMLHttpRequestUpload對象
XMLHttpRequest和XMLHttpRequestUpload都繼承了同一個XMLHttpRequestEventTarget接口，所以xhr和xhr.upload都有第一條列舉的7個事件
onreadystatechange是XMLHttpRequest獨有的事件

所以這麼一看就很清晰了：
xhr一共有8個相關事件：7個XMLHttpRequestEventTarget事件+1個獨有的onreadystatechange事件；而xhr.upload只有7個XMLHttpRequestEventTarget事件。

事件觸發條件

下面是我自己整理的一張xhr相關事件觸發條件表，其中最需要注意的是 onerror 事件的觸發條件。

事件	觸發條件
`onreadystatechange`	每當`xhr.readyState`改變時觸發；但`xhr.readyState`由非`0`值變為`0`時不觸發。
`onloadstart`	調用`xhr.send()`方法後立即觸發，若`xhr.send()`未被調用則不會觸發此事件。
`onprogress`	`xhr.upload.onprogress`在上傳階段(即`xhr.send()`之後，`xhr.readystate=2`之前)觸發，每50ms觸發一次；`xhr.onprogress`在下載階段（即`xhr.readystate=3`時）觸發，每50ms觸發一次。
`onload`	當請求成功完成時觸發，此時`xhr.readystate=4`
`onloadend`	當請求結束（包括請求成功和請求失敗）時觸發
`onabort`	當調用`xhr.abort()`後觸發
`ontimeout`	`xhr.timeout`不等於0，由請求開始即`onloadstart`開始算起，當到達`xhr.timeout`所設置時間請求還未結束即`onloadend`，則觸發此事件。
`onerror`	在請求過程中，若發生`Network error`則會觸發此事件（若發生`Network error`時，上傳還沒有結束，則會先觸發`xhr.upload.onerror`，再觸發`xhr.onerror`；若發生`Network error`時，上傳已經結束，則只會觸發`xhr.onerror`）。注意，只有發生了網絡層級別的異常才會觸發此事件，對於應用層級別的異常，如響應返回的`xhr.statusCode`是`4xx`時，並不屬於`Network error`，所以不會觸發`onerror`事件，而是會觸發`onload`事件。

事件觸發順序

當請求一切正常時，相關的事件觸發順序如下：

觸發xhr.onreadystatechange(之後每次readyState變化時，都會觸發一次)
觸發xhr.onloadstart
//上傳階段開始：
觸發xhr.upload.onloadstart
觸發xhr.upload.onprogress
觸發xhr.upload.onload
觸發xhr.upload.onloadend
//上傳結束，下載階段開始：
觸發xhr.onprogress
觸發xhr.onload
觸發xhr.onloadend

發生`abort`/`timeout`/`error`異常的處理

在請求的過程中，有可能發生 abort/timeout/error這3種異常。那麼一旦發生這些異常，xhr後續會進行哪些處理呢？後續處理如下：

一旦發生abort或timeout或error異常，先立即中止當前請求
將 readystate 置為4，並觸發 xhr.onreadystatechange事件
如果上傳階段還沒有結束，則依次觸發以下事件：
- xhr.upload.onprogress
- xhr.upload.[onabort或ontimeout或onerror]
- xhr.upload.onloadend
觸發 xhr.onprogress事件
觸發 xhr.[onabort或ontimeout或onerror]事件
觸發xhr.onloadend 事件

在哪個`xhr`事件中註冊成功回調？

從上面介紹的事件中，可以知道若xhr請求成功，就會觸發xhr.onreadystatechange和xhr.onload兩個事件。那麼我們到底要將成功回調註冊在哪個事件中呢？我傾向於 xhr.onload事件，因為xhr.onreadystatechange是每次xhr.readyState變化時都會觸發，而不是xhr.readyState=4時才觸發。

xhr.onload = function () {    //如果請求成功    if(xhr.status == 200){ //do successCallback } }

上面的示例代碼是很常見的寫法：先判斷http狀態碼是否是200，如果是，則認為請求是成功的，接着執行成功回調。這樣的判斷是有坑兒的，比如當返回的http狀態碼不是200，而是201時，請求雖然也是成功的，但並沒有執行成功回調邏輯。所以更靠譜的判斷方法應該是：當http狀態碼為2xx或304時才認為成功。

  xhr.onload = function () {    //如果請求成功    if((xhr.status >= 200 && xhr.status < 300) || xhr.status == 304){ //do successCallback } }

結語

終於寫完了......
希望這篇總結能幫助剛開始接觸XMLHttpRequest的你。

李不要熬夜博客

李不要熬夜博客

博客 / 詳情