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