干前端這些年我有個(gè)很深的感受很多同學(xué) JS 基礎(chǔ)背得滾瓜爛熟但一碰到數(shù)據(jù)交互就露怯。項(xiàng)目里十個(gè)報(bào)錯(cuò)至少有五個(gè)和 JS AJAX 這條鏈路有關(guān)。AJAX 不是一個(gè)庫(kù)也不是某個(gè)框架獨(dú)有的能力它是瀏覽器提供的一套異步通信方案。理解它你才能理解網(wǎng)絡(luò)面板里那些請(qǐng)求為什么會(huì)有 preflight、為什么 GET 會(huì)被緩存、為什么接口明明返回 200 卻拿不到數(shù)據(jù)。這篇文章不講空泛的 API 羅列我會(huì)從 AJAX 的核心機(jī)制講到原生手寫(xiě)封裝再聊到 fetch、取消請(qǐng)求、跨域、競(jìng)態(tài)和安全問(wèn)題最后用一個(gè)帶 loading 和錯(cuò)誤處理的用戶(hù)列表案例把整個(gè)流程串起來(lái)。無(wú)論你是剛?cè)腴T(mén)的前端新人還是被各種請(qǐng)求問(wèn)題折磨過(guò)的“野生程序員”這篇都值得花十分鐘細(xì)讀。1. 先把 AJAX 這條線捋清楚1.1 從整頁(yè)刷新到局部更新在 AJAX 出現(xiàn)之前網(wǎng)頁(yè)的數(shù)據(jù)交互模式非常原始用戶(hù)在頁(yè)面上點(diǎn)擊提交瀏覽器把整個(gè)表單打包發(fā)給服務(wù)器服務(wù)器返回一整個(gè)新的 HTML 頁(yè)面瀏覽器再重新渲染。這個(gè)過(guò)程中用戶(hù)看到的是白屏、轉(zhuǎn)圈、頁(yè)面跳轉(zhuǎn)。如果只是點(diǎn)贊、翻頁(yè)、提交一條備注也要整個(gè)頁(yè)面刷新體驗(yàn)相當(dāng)糟糕。AJAX 的全稱(chēng)是 Asynchronous JavaScript And XML核心思想是“頁(yè)面不跳轉(zhuǎn)也能和服務(wù)器交換數(shù)據(jù)”。它讓瀏覽器在后臺(tái)發(fā)請(qǐng)求拿到數(shù)據(jù)后通過(guò) JavaScript 動(dòng)態(tài)更新頁(yè)面局部?jī)?nèi)容。比如微博點(diǎn)贊你點(diǎn)擊后立刻變紅這個(gè)操作背后就是一個(gè)異步請(qǐng)求服務(wù)器返回“已點(diǎn)贊”狀態(tài)前端據(jù)此更新按鈕樣式。整個(gè)過(guò)程用戶(hù)無(wú)感知不用等頁(yè)面重新加載。之所以能做到這一點(diǎn)依賴(lài)的是瀏覽器內(nèi)置的 XMLHttpRequest 對(duì)象。注意它名字里帶著 XML但實(shí)際傳輸什么格式都行現(xiàn)在主流是 JSON。你不用管名字只要知道它是一套底層的 HTTP 通信接口就行。1.2 瀏覽器里的一次完整請(qǐng)求長(zhǎng)什么樣一個(gè)完整的 AJAX 請(qǐng)求本質(zhì)上就是一個(gè)普通 HTTP 請(qǐng)求只不過(guò)由 JavaScript 發(fā)起、由 JavaScript 接收。整個(gè)流程可以概括為創(chuàng)建 XMLHttpRequest 實(shí)例。調(diào)用 open 方法設(shè)置請(qǐng)求方法、URL、是否異步。綁定事件監(jiān)聽(tīng)比如 onreadystatechange、onload、onerror。調(diào)用 send 方法把請(qǐng)求發(fā)出去。瀏覽器在后臺(tái)完成網(wǎng)絡(luò)通信觸發(fā)回調(diào)函數(shù)。這里最關(guān)鍵的概念是 readyState 和 status。readyState 表示請(qǐng)求當(dāng)前處于哪個(gè)階段0 是未初始化1 是已建立連接2 是已收到響應(yīng)頭3 是正在接收響應(yīng)體4 是響應(yīng)體接收完畢。千萬(wàn)不要一看到 readyState 變成 4 就以為成功還需要再看 status也就是 HTTP 狀態(tài)碼。status 是 200 到 299 才表示請(qǐng)求成功304 表示走緩存404、500 這些都屬于失敗。新手最容易犯的錯(cuò)是只判斷 readyState不判斷 status導(dǎo)致接口報(bào)錯(cuò)時(shí)前端毫無(wú)感知。所以學(xué)習(xí) AJAX第一步就是把這兩個(gè)狀態(tài)的關(guān)系刻在腦子里。2. 手寫(xiě) AJAX 請(qǐng)求從零開(kāi)始理解每一步2.1 最基本的 GET 請(qǐng)求很多人工作第一天就用第三方請(qǐng)求庫(kù)反而不會(huì)寫(xiě)原生的 XMLHttpRequest。但原生寫(xiě)法才是理解一切請(qǐng)求庫(kù)的基礎(chǔ)。一個(gè)最簡(jiǎn)單的 GET 請(qǐng)求是這樣const xhr new XMLHttpRequest() xhr.open(GET, /api/users?id1, true) xhr.onreadystatechange function () { if (xhr.readyState 4) { if (xhr.status 200 xhr.status 300) { console.log(xhr.responseText) } else { console.error(請(qǐng)求失敗, xhr.status) } } } xhr.send(null)這段代碼有幾個(gè)點(diǎn)值得琢磨。open 方法的第三個(gè)參數(shù)是 async必須傳 true。如果傳 false請(qǐng)求會(huì)變成同步阻塞瀏覽器主線程卡死頁(yè)面假死現(xiàn)代瀏覽器甚至?xí)苯訄?bào)廢這個(gè)用法。服務(wù)端響應(yīng)慢的時(shí)候用戶(hù)會(huì)看到頁(yè)面像凍住了一樣點(diǎn)哪里都沒(méi)反應(yīng)。另外GET 請(qǐng)求沒(méi)有請(qǐng)求體所以 send 的參數(shù)傳 null 或不傳都行。我習(xí)慣顯式寫(xiě) null意思是“我沒(méi)有 body”看起來(lái)更清晰。等到 readyState 變成 4responseText 里面就是服務(wù)器返回的字符串。如果接口返回的是 JSON你還得手動(dòng) JSON.parse 一下。這一步經(jīng)常被忽略因?yàn)楹芏嗾?qǐng)求庫(kù)自動(dòng)做了原生不會(huì)。2.2 POST 請(qǐng)求、請(qǐng)求頭和參數(shù)序列化POST 請(qǐng)求和 GET 最大的區(qū)別是參數(shù)放在請(qǐng)求體里同時(shí)要正確設(shè)置 Content-Type 請(qǐng)求頭。否則服務(wù)器可能解析不出你的參數(shù)?？聪旅娴睦觕onst xhr new XMLHttpRequest() xhr.open(POST, /api/users, true) xhr.setRequestHeader(Content-Type, application/x-www-form-urlencoded) xhr.onload function () { if (xhr.status 200 xhr.status 300) { const data JSON.parse(xhr.responseText) console.log(data) } } xhr.send(namezhangsanage18)這里我們把請(qǐng)求體拼成了namezhangsanage18這種查詢(xún)字符串格式對(duì)應(yīng)的 Content-Type 是application/x-www-form-urlencoded。如果你改成application/json就必須先JSON.stringify再發(fā)送比如xhr.setRequestHeader(Content-Type, application/json) xhr.send(JSON.stringify({ name: zhangsan, age: 18 }))很多后端框架接收 JSON 和表單參數(shù)的解析方式完全不同。前端如果設(shè)置錯(cuò)了 Content-Type后端會(huì)一臉茫然地返回 400。實(shí)際開(kāi)發(fā)中先和后端確認(rèn)接口約定的提交格式比啥都重要。還有一個(gè)容易踩的坑是中文編碼。直接用name張三這種字符串發(fā)出去瀏覽器可能發(fā)出 UTF-8 編碼但服務(wù)端解析時(shí)按錯(cuò)誤編碼解碼就亂碼了。表單格式下最保險(xiǎn)的做法是用encodeURIComponent編碼每個(gè)參數(shù)值const name encodeURIComponent(張三) xhr.send(name name age18)GET 請(qǐng)求的 URL 參數(shù)同樣需要 encodeURIComponent尤其是關(guān)鍵詞搜索這種場(chǎng)景不然特殊字符會(huì)把 URL 搞壞。2.3 封裝一個(gè)夠用的 ajax 函數(shù)理解了原生寫(xiě)法之后推薦自己封裝一層不是為了造輪子而是為了真正理解 Promise 是怎么把回調(diào)地獄變成扁平鏈?zhǔn)降?。一個(gè)夠用的封裝大概長(zhǎng)這樣function ajax(options) { return new Promise((resolve, reject) { const xhr new XMLHttpRequest() const method options.method || GET const url options.url const timeout options.timeout || 10000 xhr.open(method, url, true) xhr.timeout timeout xhr.onreadystatechange function () { if (xhr.readyState ! 4) return if (xhr.status 200 xhr.status 300) { let result xhr.responseText try { result JSON.parse(result) } catch (e) { // 保留原始字符串 } resolve(result) } else { reject(new Error(請(qǐng)求失敗 xhr.status xhr.statusText)) } } xhr.onerror function () { reject(new Error(網(wǎng)絡(luò)異常)) } xhr.ontimeout function () { reject(new Error(請(qǐng)求超時(shí))) } const headers options.headers || {} Object.keys(headers).forEach(function (key) { xhr.setRequestHeader(key, headers[key]) }) let body null if (options.data) { body JSON.stringify(options.data) xhr.setRequestHeader(Content-Type, application/json) } xhr.send(body) }) } // 使用 ajax({ url: /api/users, method: GET }) .then(function (data) { console.log(data) }) .catch(function (err) { console.error(err) })為什么要把 onreadystatechange 包在 Promise 里因?yàn)?Promise 的狀態(tài)只能從 pending 變?yōu)?fulfilled 或 rejected而且只會(huì)變一次。這正好符合我們對(duì)一次請(qǐng)求的預(yù)期要么成功要么失敗絕對(duì)不會(huì)回調(diào)兩次。這也倒逼你把“請(qǐng)求中”的狀態(tài)管理放到 Promise 外部用變量或狀態(tài)機(jī)來(lái)控制。不過(guò)要注意這個(gè)封裝為了簡(jiǎn)單沒(méi)有處理 GET 參數(shù)拼接也沒(méi)有做請(qǐng)求取消。真實(shí)項(xiàng)目里取消請(qǐng)求非常常用后面我會(huì)單獨(dú)講。3. Fetch 和第三方請(qǐng)求庫(kù)它們和 AJAX 是什么關(guān)系3.1 Fetch 到底是不是 AJAX 的替代品很多新人會(huì)問(wèn)現(xiàn)在不都用 fetch 嗎為什么還要學(xué) XMLHttpRequest準(zhǔn)確地說(shuō)fetch 是瀏覽器提供的另一種異步請(qǐng)求 API和 XMLHttpRequest 是平級(jí)關(guān)系都是原生能力。但由于 fetch 基于 Promise寫(xiě)法更現(xiàn)代所以被很多人當(dāng)作 AJAX 的“下一代”。一個(gè)基本 fetch 請(qǐng)求長(zhǎng)這樣fetch(/api/users, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ name: zhangsan }) }) .then(function (response) { if (!response.ok) { throw new Error(HTTP response.status) } return response.json() }) .then(function (data) { console.log(data) })看起來(lái)比 XMLHttpRequest 清爽不少。但有三個(gè)坑特別容易踩第一fetch 默認(rèn)不會(huì)攜帶同源請(qǐng)求的 cookie。在 XMLHttpRequest 里同源請(qǐng)求默認(rèn)帶 cookie而 fetch 需要通過(guò)credentials: same-origin或credentials: include顯式聲明。如果接口依賴(lài)登錄態(tài)你會(huì)發(fā)現(xiàn)用 fetch 登錄之后下一次請(qǐng)求依然拿不到 session。第二fetch 只在網(wǎng)絡(luò)錯(cuò)誤或請(qǐng)求被取消時(shí) reject。HTTP 404、500 這些狀態(tài)碼response.ok 是 false但 fetch 本身不會(huì)拋異常只會(huì)正常 resolve。所以必須在 then 里面手動(dòng)判斷 response.ok。第三response.json() 也是異步操作如果返回的不是合法 JSON會(huì)在這里拋異常。實(shí)際調(diào)試時(shí)我喜歡先用 response.text() 把原始字符串打出來(lái)確認(rèn)服務(wù)端到底返回了什么再?zèng)Q定怎么解析。3.2 取消請(qǐng)求與超時(shí)AbortController原生 XMLHttpRequest 有 abort 方法也有 timeout 屬性和 ontimeout 事件。fetch 本身沒(méi)有 timeout 概念但可以通過(guò) AbortController 來(lái)取消請(qǐng)求。const controller new AbortController() fetch(/api/users, { signal: controller.signal }) .then(function (response) { return response.json() }) .catch(function (err) { if (err.name AbortError) { console.log(請(qǐng)求被主動(dòng)取消) } else { console.error(err) } }) // 5 秒超時(shí) setTimeout(function () { controller.abort() }, 5000)這個(gè)模式很實(shí)用。比如用戶(hù)在搜索框里輸入快速敲擊的時(shí)候會(huì)觸發(fā)很多請(qǐng)求。如果每次輸入都發(fā)一個(gè)請(qǐng)求上一條還沒(méi)返回下一條就已經(jīng)發(fā)出去了。這時(shí)候用 AbortController 把舊請(qǐng)求取消掉就能避免無(wú)謂的網(wǎng)絡(luò)消耗和狀態(tài)覆蓋。注意 catch 里要判斷 err.name 是不是 AbortError。因?yàn)橛脩?hù)主動(dòng)取消和網(wǎng)絡(luò)錯(cuò)誤是兩回事不區(qū)分的話頁(yè)面上可能會(huì)錯(cuò)誤地彈出“網(wǎng)絡(luò)異?！碧崾?。3.3 第三方請(qǐng)求庫(kù)到底幫你做了什么事市面上流行的 HTTP 請(qǐng)求庫(kù)在瀏覽器環(huán)境里的底層能力大多還是建立在 XMLHttpRequest 或 fetch 之上。它們并沒(méi)有發(fā)明新的網(wǎng)絡(luò)協(xié)議只是幫你把很多繁瑣細(xì)節(jié)封裝好了。比如自動(dòng)拼接 URL 參數(shù)并且處理數(shù)組、嵌套對(duì)象這些復(fù)雜結(jié)構(gòu)。自動(dòng)序列化請(qǐng)求體和解析響應(yīng)體。根據(jù)狀態(tài)碼自動(dòng)決定 resolve 還是 reject。提供攔截器讓你在請(qǐng)求發(fā)出前統(tǒng)一加 token在響應(yīng)回來(lái)后統(tǒng)一處理錯(cuò)誤碼。提供更完善的取消機(jī)制和超時(shí)控制。所以如果你已經(jīng)理解了原生 AJAX再用第三方庫(kù)會(huì)非常順手如果沒(méi)理解出了問(wèn)題只會(huì)覺(jué)得是庫(kù)有 bug然后到處查配置。我的建議是項(xiàng)目里可以用封裝好的庫(kù)提高效率但至少要能手寫(xiě)原生請(qǐng)求。面試考 AJAX 底層時(shí)這幾乎是必問(wèn)題。4. 真實(shí)項(xiàng)目中常見(jiàn)的 AJAX 坑與排查思路4.1 跨域問(wèn)題為什么接口調(diào)不通前端開(kāi)發(fā)中幾乎天天遇到跨域。瀏覽器出于安全考慮默認(rèn)禁止頁(yè)面腳本訪問(wèn)不同源協(xié)議、域名、端口任意一個(gè)不同的資源。你用 AJAX 請(qǐng)求一個(gè)不同域的接口控制臺(tái)會(huì)報(bào) CORS 錯(cuò)誤。解決辦法有幾類(lèi)。最直接的是后端在響應(yīng)頭里加允許跨域的字段Access-Control-Allow-Origin: https://your-domain.com如果請(qǐng)求帶自定義請(qǐng)求頭或者用了 PUT、DELETE 這些方法瀏覽器會(huì)先發(fā)一個(gè) OPTIONS 預(yù)檢請(qǐng)求詢(xún)問(wèn)服務(wù)器允不允許。服務(wù)器如果沒(méi)正確響應(yīng)預(yù)檢正式請(qǐng)求就不會(huì)發(fā)出。這也是為什么有些人發(fā)現(xiàn)網(wǎng)絡(luò)面板里只有一個(gè) OPTIONS 請(qǐng)求卻沒(méi)有真正的業(yè)務(wù)請(qǐng)求。開(kāi)發(fā)環(huán)境下更好的做法是通過(guò)本地開(kāi)發(fā)服務(wù)器做代理。配置一個(gè)代理規(guī)則把/api開(kāi)頭的請(qǐng)求轉(zhuǎn)發(fā)到目標(biāo)服務(wù)器。這樣瀏覽器看到的請(qǐng)求是同源的就不會(huì)有跨域問(wèn)題。生產(chǎn)環(huán)境則可以用服務(wù)器反向代理或網(wǎng)關(guān)統(tǒng)一處理?？缬虿皇乔岸四軉畏矫娼鉀Q的它需要前后端配合。4.2 返回?cái)?shù)據(jù)是字符串還是對(duì)象這也是高頻問(wèn)題。接口明明返回了 JSON你打印出來(lái)卻是字符串。原因通常有兩個(gè)一是服務(wù)端返回的 Content-Type 不是 application/json而是 text/plain二是前端沒(méi)有做 JSON.parse。使用原生 XMLHttpRequest 時(shí)responseText 永遠(yuǎn)是字符串必須自己 parse。使用 fetch 時(shí)你調(diào)用了 response.json() 它會(huì)自己 parse但如果服務(wù)端返回的是空內(nèi)容或錯(cuò)誤頁(yè)面解析會(huì)報(bào)錯(cuò)。遇到這種情況我建議先在 network 面板里看 Response 標(biāo)簽確認(rèn)原始返回內(nèi)容再去檢查代碼。很多時(shí)候錯(cuò)誤不在前端而是后端把錯(cuò)誤堆棧直接當(dāng)成響應(yīng)體返回了。還有一類(lèi)問(wèn)題是 JSON.parse 成功了但數(shù)據(jù)結(jié)構(gòu)跟預(yù)期不一樣。比如你期待一個(gè)數(shù)組結(jié)果拿到一個(gè)對(duì)象。這時(shí)候不要瞎猜把數(shù)據(jù)打印出來(lái)對(duì)照接口文檔逐一核對(duì)字段。4.3 請(qǐng)求競(jìng)態(tài)最后發(fā)出的不一定最后到達(dá)請(qǐng)求競(jìng)態(tài)是很容易被忽視的坑。假設(shè)頁(yè)面上有兩個(gè)并行的請(qǐng)求第二個(gè)請(qǐng)求比第一個(gè)快后發(fā)先至界面就可能顯示舊數(shù)據(jù)。更常見(jiàn)的是搜索建議用戶(hù)輸入“a”發(fā)送請(qǐng)求 A又輸入“ab”發(fā)送請(qǐng)求 B。如果 A 比 B 慢A 的響應(yīng)后到會(huì)把 B 的結(jié)果覆蓋掉。解決辦法有兩種思路。一是用請(qǐng)求序號(hào)拿到響應(yīng)后比對(duì)序號(hào)如果當(dāng)前響應(yīng)不是最新一次請(qǐng)求就直接丟棄let requestSeq 0 async function search(keyword) { const current requestSeq const data await ajax({ url: /api/search?q encodeURIComponent(keyword) }) if (current ! requestSeq) { // 過(guò)期響應(yīng)丟棄 return } renderResult(data) }二是直接取消上一次請(qǐng)求。用 XMLHttpRequest 就調(diào) abort用 fetch 就調(diào) AbortController 的 abort。兩種方式都可以實(shí)際項(xiàng)目中我更喜歡“序號(hào)法”因?yàn)檫壿嬛庇^、不依賴(lài)取消機(jī)制而且不會(huì)因?yàn)槿∠?qǐng)求產(chǎn)生不必要的錯(cuò)誤日志。4.4 緩存、亂碼與狀態(tài)碼誤判GET 請(qǐng)求容易被瀏覽器緩存。明明后端數(shù)據(jù)改了前端拿到的卻是舊數(shù)據(jù)。兩種最常用的規(guī)避辦法加時(shí)間戳參數(shù)比如/api/users?t${Date.now()}或者在后端響應(yīng)頭里設(shè)置 Cache-Control: no-cache。我通常只在排查問(wèn)題時(shí)手動(dòng)加時(shí)間戳生產(chǎn)環(huán)境應(yīng)該由后端統(tǒng)一控制緩存策略。亂碼問(wèn)題常見(jiàn)于服務(wù)端返回的編碼和前端聲明的編碼不一致。頁(yè)面用的是 UTF-8服務(wù)端返回 GBK瀏覽器就會(huì)顯示亂碼。這個(gè)不推薦在前端硬解應(yīng)該讓后端改響應(yīng)頭統(tǒng)一用 UTF-8。如果實(shí)在改不了后端再考慮在請(qǐng)求時(shí)用responseType arraybuffer然后手動(dòng)解碼但這是下策。狀態(tài)碼方面不要只判斷 status 200。201 表示創(chuàng)建成功304 表示未修改走緩存這些都應(yīng)該算成功范圍。所以前面封裝里用status 200 status 300就是避免漏掉這些合法狀態(tài)。另外302 重定向在 AJAX 場(chǎng)景下通常會(huì)被瀏覽器透明處理前端拿到的可能是最終資源的響應(yīng)這個(gè)特性有時(shí)候會(huì)讓人困惑。5. 完整案例用原生 JS 實(shí)現(xiàn)一個(gè)帶 loading 的用戶(hù)列表5.1 頁(yè)面結(jié)構(gòu)與接口約定用一個(gè)實(shí)際場(chǎng)景把上面的知識(shí)點(diǎn)串起來(lái)。假設(shè)我們要做一個(gè)用戶(hù)列表頁(yè)面進(jìn)入頁(yè)面后請(qǐng)求/api/users實(shí)時(shí)顯示加載狀態(tài)加載完成渲染用戶(hù)名稱(chēng)。接口約定如下請(qǐng)求方法GET響應(yīng)格式JSON成功返回{ code: 0, data: [{ id: 1, name: 張三 }, ...] }失敗返回{ code: 500, message: 服務(wù)器開(kāi)小差了 }頁(yè)面結(jié)構(gòu)很簡(jiǎn)單div idapp div idloading加載中.../div ul iduser-list/ul button idload-btn重新加載/button /div5.2 加載并渲染數(shù)據(jù)渲染用戶(hù)列表時(shí)最關(guān)鍵的一條不要用 innerHTML 去拼name字段。用戶(hù)昵稱(chēng)什么內(nèi)容都可能包含比如script標(biāo)簽或者img onerror一旦拼進(jìn) HTML就可能變成 XSS 漏洞。用 textContent 最安全function renderUsers(users) { const list document.getElementById(user-list) list.innerHTML users.forEach(function (user) { const li document.createElement(li) li.textContent user.name list.appendChild(li) }) }加載數(shù)據(jù)部分我會(huì)把 loading、錯(cuò)誤、成功三種狀態(tài)拆分開(kāi)處理async function loadUsers() { const loading document.getElementById(loading) const list document.getElementById(user-list) loading.style.display block list.innerHTML try { const result await ajax({ url: /api/users, method: GET, timeout: 8000 }) if (result.code ! 0) { throw new Error(result.message || 未知錯(cuò)誤) } renderUsers(result.data) } catch (err) { const item document.createElement(li) item.textContent 加載失敗 err.message list.appendChild(item) } finally { loading.style.display none } } document.getElementById(load-btn).addEventListener(click, function () { loadUsers() }) loadUsers()這個(gè)案例雖然簡(jiǎn)單但體現(xiàn)了幾個(gè)關(guān)鍵思路狀態(tài)分離、錯(cuò)誤處理、結(jié)果校驗(yàn)。很多人寫(xiě) AJAX 只處理成功路徑失敗路徑全靠瀏覽器默認(rèn)報(bào)錯(cuò)這在正式項(xiàng)目里是沒(méi)法用的。5.3 給案例加上取消和競(jìng)態(tài)保護(hù)再進(jìn)一步。如果用戶(hù)快速點(diǎn)擊“重新加載”多次就會(huì)發(fā)出多個(gè)并發(fā)請(qǐng)求響應(yīng)順序不確定頁(yè)面可能被舊數(shù)據(jù)覆蓋。我加一個(gè)簡(jiǎn)單的序號(hào)保護(hù)let loadSeq 0 async function loadUsers() { const current loadSeq // ... 其他代碼不變 const result await ajax({ url: /api/users, method: GET, timeout: 8000 }) if (current ! loadSeq) { return // 已經(jīng)有更新的請(qǐng)求發(fā)出了丟棄本次結(jié)果 } renderUsers(result.data) }這樣做的好處是不需要真的取消請(qǐng)求舊的請(qǐng)求依然會(huì)返回但不會(huì)再觸發(fā)渲染。頁(yè)面始終只展示最后一次請(qǐng)求的結(jié)果。6. 安全底線AJAX 請(qǐng)求需要注意什么6.1 渲染數(shù)據(jù)時(shí)如何防 XSS前面提到的 textContent 是一種最直接的防護(hù)方式。凡是把外部數(shù)據(jù)插入 DOM 的地方都要默認(rèn)不可信。如果業(yè)務(wù)確實(shí)需要渲染富文本比如后臺(tái)返回一段帶有標(biāo)簽的公告不建議自己寫(xiě)正則過(guò)濾更不能用正則把script去掉就完事。更穩(wěn)妥的做法是使用成熟的 HTML 清洗庫(kù)或者讓后端直接返回安全的 JSON 結(jié)構(gòu)由前端用創(chuàng)建節(jié)點(diǎn)的方式來(lái)構(gòu)建。XSS 的危害不只是彈個(gè)窗。攻擊者可以竊取 cookie、模擬用戶(hù)操作、篡改頁(yè)面內(nèi)容。所以在 AJAX 相關(guān)代碼里所有從服務(wù)端來(lái)的字符串在進(jìn)入 innerHTML、document.write、eval 之前都要多問(wèn)一句這東西能不能直接用。6.2 請(qǐng)求偽造與基礎(chǔ)防護(hù)CSRF 攻擊的原理是用戶(hù)登錄了你的網(wǎng)站瀏覽器里留有登錄狀態(tài)此時(shí)攻擊者在另一個(gè)網(wǎng)站誘導(dǎo)用戶(hù)發(fā)起請(qǐng)求瀏覽器會(huì)帶著 cookie 自動(dòng)發(fā)送服務(wù)器沒(méi)有能力區(qū)分這是用戶(hù)主動(dòng)操作還是被誘導(dǎo)的操作。常見(jiàn)的防護(hù)手段包括在請(qǐng)求頭里加入自定義字段并讓后端校驗(yàn)使用 CSRF Token把隨機(jī)字符串放到頁(yè)面和 cookie 中提交請(qǐng)求時(shí)帶上后端比對(duì)一致性設(shè)置 cookie 的 SameSite 屬性限制跨站請(qǐng)求攜帶 cookie。作為前端我們能做的是配合后端在封裝 AJAX 時(shí)統(tǒng)一為請(qǐng)求添加必要的 token 頭同時(shí)避免在 URL 參數(shù)里攜帶敏感信息因?yàn)?URL 會(huì)被記錄到訪問(wèn)日志中安全性更低。AJAX 的安全問(wèn)題很容易被忽視因?yàn)槠綍r(shí)開(kāi)發(fā)環(huán)境沒(méi)有攻擊者但一旦上線各種掃描和惡意請(qǐng)求就會(huì)涌過(guò)來(lái)。寫(xiě)代碼的時(shí)候養(yǎng)成好習(xí)慣能省去以后很多麻煩。老實(shí)說(shuō)JS AJAX 這套東西表面上看是“瀏覽器發(fā)請(qǐng)求、收響應(yīng)”八個(gè)字真正吃透卻需要把協(xié)議、狀態(tài)、異步、安全這些問(wèn)題串起來(lái)。我自己帶過(guò)不少新人發(fā)現(xiàn)他們最常卡住的不是語(yǔ)法而是遇到問(wèn)題不知道從哪下手分析。每次接口調(diào)不通我都建議先打開(kāi)網(wǎng)絡(luò)面板看請(qǐng)求體、響應(yīng)體和狀態(tài)碼再對(duì)照代碼逐步排查。這個(gè)方法聽(tīng)起來(lái)原始但比盲目改代碼有效得多。如果你也想真正掌握 AJAX不妨抽個(gè)下午把原生 XMLHttpRequest 的封裝手寫(xiě)一遍再在項(xiàng)目里試著自己加請(qǐng)求取消和競(jìng)態(tài)保護(hù)。做完這些很多看似玄學(xué)的 bug 都會(huì)變得有跡可循。