每次調(diào)接口前端最繞不開(kāi)的就是兩個(gè)家伙DOM 和 XMLHttpRequest。一個(gè)是頁(yè)面骨架的操作入口一個(gè)是瀏覽器里最原始的數(shù)據(jù)請(qǐng)求通道。雖然現(xiàn)在大家張口閉口都是 fetch、axios但 XHR 這套老底子只要還在瀏覽器里跑一天你就繞不開(kāi)它——尤其你一旦碰上老項(xiàng)目維護(hù)、上傳進(jìn)度條、或者面試官冷不丁甩你一句“講講 XMLHttpRequest 和 DOM 的關(guān)系”沒(méi)有點(diǎn)底層認(rèn)知是真的會(huì)卡殼。這篇文章不打算給你搞那種“復(fù)制粘貼就能用”的玩具代碼而是把 DOM 操作和 XHR 請(qǐng)求這條鏈路上的關(guān)鍵細(xì)節(jié)從頭到尾捋一遍為什么 XHR 有那么多反直覺(jué)的坑readyState 到底怎么理解responseText 和 responseXML 什么時(shí)候能直接用動(dòng)態(tài)渲染時(shí)一旦用到 innerHTML 又是怎么把頁(yè)面搞出 DOM 型 XSS 的。適合剛?cè)腴T前端想打牢基礎(chǔ)的同學(xué)也適合寫過(guò)不少業(yè)務(wù)代碼、但一直沒(méi)時(shí)間把這塊地基補(bǔ)上的老手?？赐昴憧梢灾苯诱罩锩娴姆庋b思路改造自己的項(xiàng)目也能拿去應(yīng)付絕大多數(shù)瀏覽器原理層面的面試題。1. 項(xiàng)目解析為什么 DOM 和 XMLHttpRequest 總被放在一起聊1.1 兩者在瀏覽器里的真實(shí)分工先說(shuō)最基礎(chǔ)的關(guān)系。瀏覽器拿到 HTML 之后會(huì)把它解析成一棵節(jié)點(diǎn)樹(shù)這棵樹(shù)就是 DOMDocument Object Model。你想要頁(yè)面上的按鈕變色、列表刷新、彈窗出現(xiàn)本質(zhì)上都是對(duì) DOM 樹(shù)做增刪改查。而 XMLHttpRequest 呢它是瀏覽器提供的一個(gè) API 對(duì)象專門用來(lái)在頁(yè)面不刷新的情況下向服務(wù)器發(fā) HTTP 請(qǐng)求、拿數(shù)據(jù)。一個(gè)管“畫”一個(gè)管“要數(shù)據(jù)”這兩者單獨(dú)看都不復(fù)雜但一旦把它們串起來(lái)就構(gòu)成了現(xiàn)代 Web 頁(yè)面最核心的運(yùn)作方式通過(guò) XHR 獲取數(shù)據(jù)再把數(shù)據(jù)渲染到 DOM 上。我見(jiàn)過(guò)很多初學(xué)者把這兩件事混著學(xué)以為 XHR 的返回值可以直接“貼”到頁(yè)面上。實(shí)際上 XHR 拿到的只是一段文本或者二進(jìn)制數(shù)據(jù)它跟頁(yè)面上那個(gè) div 之間沒(méi)有任何自動(dòng)關(guān)聯(lián)。你必須在拿到數(shù)據(jù)之后手動(dòng)用 JavaScript 去創(chuàng)建元素、填充文本、插入 DOM或者直接把字符串塞進(jìn)某個(gè)容器節(jié)點(diǎn)的 innerHTML。這個(gè)“手動(dòng)”的過(guò)程恰恰就是前端工程師絕大部分日常工作的本質(zhì)。1.2 熱詞背后真正值得關(guān)注的兩個(gè)延伸點(diǎn)圍繞“DOM XMLHttpRequest”這個(gè)標(biāo)題最近網(wǎng)絡(luò)上高頻出現(xiàn)的幾個(gè)相關(guān)詞很有信息量dom 型 xss、dom 元素、虛擬 dom 和 diff 算法面試。這些詞其實(shí)是在提醒你單純會(huì)用 XHR 不夠你得理解數(shù)據(jù)和 DOM 結(jié)合的邊界在哪里——比如數(shù)據(jù)不可信時(shí)渲染到 DOM 就可能被注入腳本數(shù)據(jù)量大時(shí)頻繁操作 DOM 會(huì)很卡這才催生了虛擬 DOM 和 diff 算法這類優(yōu)化方案。面試?yán)锟肌疤摂M DOM 和 diff 算法”絕大多數(shù)答案都會(huì)提到一個(gè)理由直接操作 DOM 太慢所以先在 JS 里做 diff最后統(tǒng)一更新。但如果你追問(wèn)一句“為什么直接操作 DOM 慢”很多人就答不上來(lái)了。這里面繞不開(kāi) XHR 和 DOM 的關(guān)系XHR 異步拿到大量數(shù)據(jù)后如果逐條 append 到 DOM每一次 append 都可能觸發(fā)布局計(jì)算和重繪這是性能瓶頸的根源。所以這篇文章后面我會(huì)專門用一個(gè)章節(jié)來(lái)說(shuō)這個(gè)事幫你在面試現(xiàn)場(chǎng)把這條鏈路講完整。2. XMLHttpRequest 的底層機(jī)制拆解2.1 readyState 和 status 是不是一回事這是新手最容易混淆的一組概念。我面試別人的時(shí)候每次問(wèn)到 XHR 都有不少人把 readyState 等于 4 和 status 等于 200 混在一起說(shuō)。它們倆完全是兩個(gè)維度readyState描述的是請(qǐng)求生命周期的狀態(tài)從 0 到 4。0 是未初始化1 是已調(diào)用 open 還沒(méi) send2 是已 send 且服務(wù)器響應(yīng)頭已收到3 是正在接收響應(yīng)體4 是響應(yīng)體接收完成。status描述的是 HTTP 響應(yīng)狀態(tài)碼比如 200、404、500。它描述的是“服務(wù)器那端給的業(yè)務(wù)結(jié)果”跟請(qǐng)求有沒(méi)有傳完是兩回事。判斷一個(gè)請(qǐng)求成功必須同時(shí)滿足readyState 4數(shù)據(jù)接收結(jié)束和 status 在 200~299 之間響應(yīng)正常。很多時(shí)候你發(fā)現(xiàn) console 里有響應(yīng)數(shù)據(jù)可頁(yè)面就是沒(méi)渲染出來(lái)八成就是只判斷了 readyState沒(méi)判斷 status 就貿(mào)然把 responseText 拿去用了——比如服務(wù)器返回一個(gè) 500 的 HTML 錯(cuò)誤頁(yè)也被當(dāng)成正常數(shù)據(jù)渲染進(jìn)了頁(yè)面。2.2 open 和 send 到底干了什么new XMLHttpRequest() 創(chuàng)建出來(lái)的對(duì)象只是一個(gè)空殼真正的“網(wǎng)絡(luò)請(qǐng)求發(fā)射”是從調(diào)用 open 開(kāi)始的但這時(shí)候它還沒(méi)發(fā)射只是完成了“瞄準(zhǔn)”。open(method, url, async) 的三個(gè)參數(shù)里async 默認(rèn)是 true表示異步發(fā)送。這里有個(gè)細(xì)節(jié)如果你顯式傳 false請(qǐng)求會(huì)變成同步模式主線程會(huì)被完全阻塞按鈕點(diǎn)了沒(méi)反應(yīng)、頁(yè)面卡死直到服務(wù)器返回響應(yīng)?，F(xiàn)代瀏覽器對(duì)主線程上的同步 XHR 已經(jīng)給出了強(qiáng)烈警告甚至在某些場(chǎng)景直接禁用比如頁(yè)面卸載時(shí)的 sendBeacon 替代所以除非你在處理極特殊的兼容邏輯否則別碰同步模式。send(body) 才是真正把請(qǐng)求發(fā)出去。這里的 body 可以傳字符串、FormData、Blob 等。沒(méi)內(nèi)容時(shí)傳 null 就好但要注意調(diào)用 send 之后服務(wù)器的響應(yīng)不是立刻返回的而是通過(guò)事件機(jī)制觸發(fā)。事件驅(qū)動(dòng)的核心就是你得在 send 之前把 onreadystatechange 或 onload 這些監(jiān)聽(tīng)函數(shù)掛好——掛晚了某些瀏覽器可能因?yàn)闋顟B(tài)已經(jīng)推進(jìn)而錯(cuò)過(guò)回調(diào)。2.3 XHR 的事件模型和回調(diào)陷阱onreadystatechange 是 XHR 最傳統(tǒng)的回調(diào)方式它在每個(gè) readyState 變化時(shí)都會(huì)被觸發(fā)所以你會(huì)在回調(diào)里看到狀態(tài)一路從 1 走到 4。比較現(xiàn)代的做法是直接監(jiān)聽(tīng) load 事件只在請(qǐng)求成功完成時(shí)觸發(fā)代碼更簡(jiǎn)潔const xhr new XMLHttpRequest() xhr.open(GET, /api/users, true) xhr.onload function() { if (xhr.status 200 xhr.status 300) { const data JSON.parse(xhr.responseText) renderUserList(data) } } xhr.onerror function() { console.error(網(wǎng)絡(luò)異常) } xhr.send(null)這里有個(gè)很容易踩的坑load 事件只代表請(qǐng)求傳輸完畢不代表業(yè)務(wù)成功。HTTP 200 也可能返回業(yè)務(wù)錯(cuò)誤碼HTTP 500 也可能在 load 里觸發(fā)。所以 onload 里必須校驗(yàn) status而真正網(wǎng)絡(luò)層面斷了才會(huì)走 onerror——比如斷網(wǎng)、DNS 解析失敗、跨域被攔。把業(yè)務(wù)錯(cuò)誤和網(wǎng)絡(luò)錯(cuò)誤混為一談是很多線上 bug 的來(lái)源。3. DOM 和 XHR 結(jié)合的完整方案設(shè)計(jì)3.1 前后端數(shù)據(jù)格式與 DOM 渲染的銜接思路拿數(shù)據(jù)是為了渲染。但這中間有一個(gè)關(guān)鍵的“翻譯”環(huán)節(jié)XHR 的 responseText 是字符串你得先把它變成 JavaScript 對(duì)象再根據(jù)對(duì)象結(jié)構(gòu)去創(chuàng)建 DOM。最常見(jiàn)的結(jié)構(gòu)是從后端拿到 JSON 數(shù)組然后渲染成一個(gè)列表。在設(shè)計(jì)渲染方案時(shí)你要提前想清楚三件事一是列表項(xiàng)的結(jié)構(gòu)長(zhǎng)什么樣是簡(jiǎn)單的文本節(jié)點(diǎn)還是要帶嵌套元素二是數(shù)據(jù)量級(jí)大概多大幾十條和幾千條的渲染策略完全不同三是用戶會(huì)不會(huì)高頻刷新數(shù)據(jù)如果會(huì)你就得考慮是清空重繪還是局部更新。這一層思考決定了你用 createElement 逐個(gè)構(gòu)建節(jié)點(diǎn)還是用字符串拼 HTML 后一次性插入 innerHTML。3.2 兩種渲染方式的對(duì)比與選擇我先把兩種方式擺出來(lái)給你看再告訴你什么時(shí)候用哪個(gè)。第一種是純 DOM API 方式function renderUserList(users) { const container document.getElementById(user-list) container.innerHTML const fragment document.createDocumentFragment() users.forEach(user { const li document.createElement(li) li.className user-item const nameSpan document.createElement(span) nameSpan.textContent user.name const ageSpan document.createElement(span) ageSpan.textContent user.age 歲 li.appendChild(nameSpan) li.appendChild(ageSpan) fragment.appendChild(li) }) container.appendChild(fragment) }第二種是 innerHTML 方式function renderUserList(users) { const container document.getElementById(user-list) const html users.map(user li classuser-item span${user.name}/span span${user.age}歲/span /li ).join() container.innerHTML html }兩種方式都對(duì)但適用場(chǎng)景不同。純 DOM 方式安全系數(shù)高因?yàn)?textContent 會(huì)自動(dòng)轉(zhuǎn)義不會(huì)把數(shù)據(jù)里的 HTML 標(biāo)簽或腳本當(dāng)代碼執(zhí)行渲染過(guò)程可控適合需要給每個(gè)節(jié)點(diǎn)綁事件、或者要做局部更新的場(chǎng)景。缺點(diǎn)是代碼啰嗦幾千條數(shù)據(jù)時(shí)如果沒(méi)配合 DocumentFragment性能會(huì)肉眼可見(jiàn)地拉胯。innerHTML 方式寫起來(lái)爽適合結(jié)構(gòu)固定、數(shù)據(jù)量大但一次性的渲染場(chǎng)景。但它的風(fēng)險(xiǎn)也很明確如果數(shù)據(jù)里混了img srcx onerroralert(1)這種字符串直接拼接進(jìn) innerHTML 就執(zhí)行了。這就是“DOM 型 XSS”最常見(jiàn)的入口。所以用 innerHTML 有個(gè)鐵律業(yè)務(wù)數(shù)據(jù)必須經(jīng)過(guò)轉(zhuǎn)義函數(shù)處理之后再拼進(jìn)去。后面我在常見(jiàn)問(wèn)題里會(huì)專門給一個(gè)轉(zhuǎn)義函數(shù)。3.3 三要素輔助函數(shù)把 XHR 封裝成好用的小工具原生 XHR 寫多了以后你會(huì)發(fā)現(xiàn)套路高度重復(fù)創(chuàng)建對(duì)象、open、配事件、send、判斷狀態(tài)、解析數(shù)據(jù)。所以我建議直接封裝成一個(gè)通用函數(shù)業(yè)務(wù)代碼里一行調(diào)用省心很多。我平時(shí)項(xiàng)目里會(huì)放一個(gè)這樣的基礎(chǔ)版本function request(options) { return new Promise((resolve, reject) { const xhr new XMLHttpRequest() const method (options.method || GET).toUpperCase() const url options.url const async options.async ! false xhr.open(method, url, async) if (options.headers) { Object.keys(options.headers).forEach(key { xhr.setRequestHeader(key, options.headers[key]) }) } xhr.responseType options.responseType || text xhr.onreadystatechange function() { if (xhr.readyState ! 4) return if (xhr.status 200 xhr.status 300) { let response xhr.response if (xhr.responseType text) { response xhr.responseText } resolve(response) } else { reject(new Error(HTTP ${xhr.status}: ${xhr.statusText})) } } xhr.onerror () reject(new Error(Network Error)) let body null if (options.data) { if (options.data instanceof FormData) { body options.data } else if (typeof options.data object) { body JSON.stringify(options.data) if (!options.headers || !options.headers[Content-Type]) { xhr.setRequestHeader(Content-Type, application/json;charsetUTF-8) } } else { body options.data } } xhr.send(body) }) }調(diào)用方式就清爽了request({ url: /api/users, method: GET }) .then(data renderUserList(data)) .catch(err console.error(err))封裝的時(shí)候有幾個(gè)細(xì)節(jié)值得注意。responseType 的設(shè)置很講究默認(rèn) text 時(shí)拿 responseText設(shè)置為 json 時(shí)瀏覽器會(huì)自動(dòng)幫你解析response 直接是對(duì)象省去手動(dòng) JSON.parse但兼容性在個(gè)別老瀏覽器上會(huì)有問(wèn)題。setRequestHeader 必須在 open 之后、send 之前調(diào)用這是硬性順序要求。Content-Type 的設(shè)置也要小心application/x-www-form-urlencoded和multipart/form-data的提交格式完全不同傳 JSON 字符串時(shí)忘了設(shè)置報(bào)文頭服務(wù)端大概率解析不出來(lái)。4. 手把手實(shí)操?gòu)恼?qǐng)求數(shù)據(jù)到完成 DOM 渲染的完整鏈路4.1 設(shè)計(jì)一個(gè)帶搜索和分頁(yè)的用戶列表紙上談兵差不多夠了現(xiàn)在來(lái)一個(gè)能直接跑的真實(shí)案例。需求是這樣頁(yè)面上有一個(gè)輸入框、一個(gè)搜索按鈕、一個(gè)用戶列表容器還有一個(gè)“加載更多”按鈕。用戶在輸入框輸入關(guān)鍵詞點(diǎn)擊搜索后前端通過(guò) XHR 請(qǐng)求/api/users?keywordxxxpage1拿到第一頁(yè)用戶數(shù)據(jù)渲染到列表里點(diǎn)擊“加載更多”時(shí)請(qǐng)求下一頁(yè)把新數(shù)據(jù)追加到列表底部。這個(gè)場(chǎng)景覆蓋了 XHR 的核心操作、DOM 渲染、拼接式更新數(shù)據(jù)和狀態(tài)維護(hù)是一個(gè)很典型的前端數(shù)據(jù)交互閉環(huán)。我把 HTML 骨架先寫出來(lái)div idapp input typetext idsearch-input placeholder輸入用戶名搜索 / button idsearch-btn搜索/button ul iduser-list/ul button idload-more styledisplay:none;加載更多/button /div這個(gè)骨架很簡(jiǎn)單但你注意load-more按鈕初始是隱藏的——因?yàn)檫€沒(méi)搜索你不知道后面還有沒(méi)有更多數(shù)據(jù)。這個(gè)狀態(tài)設(shè)計(jì)我在后面會(huì)詳細(xì)講。4.2 串聯(lián) XHR 請(qǐng)求流程與 DOM 更新邏輯接下來(lái)是最核心的 JS 邏輯。我傾向于把“請(qǐng)求數(shù)據(jù)”和“渲染 DOM”拆成兩個(gè)函數(shù)中間用數(shù)據(jù)狀態(tài)連接而不是在回調(diào)里直接寫一坨 DOM 操作。這樣職責(zé)清晰排查問(wèn)題也好定位。const state { keyword: , page: 1, pageSize: 10, hasMore: true } function fetchUsers(reset true) { if (reset) { state.page 1 state.hasMore true } const url /api/users?keyword${encodeURIComponent(state.keyword)}page${state.page}pageSize${state.pageSize} request({ url, method: GET }) .then(response { const data JSON.parse(response) if (reset) { document.getElementById(user-list).innerHTML } renderUsers(data.list) state.hasMore data.hasMore document.getElementById(load-more).style.display state.hasMore ? block : none }) .catch(err console.error(加載失敗, err)) } function renderUsers(users) { const container document.getElementById(user-list) const fragment document.createDocumentFragment() users.forEach(user { const li document.createElement(li) li.className user-item li.innerHTML span classuser-name/span span classuser-age/span li.querySelector(.user-name).textContent user.name li.querySelector(.user-age).textContent user.age 歲 fragment.appendChild(li) }) container.appendChild(fragment) }這里我給了一個(gè)很有意思的組合innerHTML 用來(lái)生成穩(wěn)定的結(jié)構(gòu)模板textContent 用來(lái)填充不可信數(shù)據(jù)。這樣既省掉了繁瑣的 createElement 代碼又避免了 XSS 注入。很多有經(jīng)驗(yàn)的前端都會(huì)用這種“模板結(jié)構(gòu) 安全填充”的混合寫法。你在面試?yán)锶绻苤v出這個(gè)細(xì)節(jié)比干巴巴背一個(gè)“不要用 innerHTML”要有說(shuō)服力得多。搜索按鈕和加載更多的邏輯掛在事件里document.getElementById(search-btn).addEventListener(click, function() { state.keyword document.getElementById(search-input).value.trim() fetchUsers(true) }) document.getElementById(load-more).addEventListener(click, function() { state.page 1 fetchUsers(false) })4.3 參數(shù)構(gòu)造和防抖踩坑記錄這個(gè)案例里有一個(gè)容易被忽略的點(diǎn)URL 參數(shù)拼接。keyword 從輸入框里直接拿過(guò)來(lái)如果用戶輸入了中文或者特殊符號(hào)不經(jīng)過(guò) encodeURIComponent 直接拼 URL輕則參數(shù)丟失重則請(qǐng)求直接 400。我在項(xiàng)目里見(jiàn)過(guò)太多因?yàn)?、?之類字符導(dǎo)致的線上 bug。所以凡是用戶輸入的參數(shù)一律 encodeURIComponent這個(gè)習(xí)慣務(wù)必養(yǎng)成。另外一個(gè)實(shí)際體驗(yàn)問(wèn)題搜索按鈕如果被用戶連續(xù)快速點(diǎn)擊就會(huì)連續(xù)發(fā)起相同請(qǐng)求舊響應(yīng)后回來(lái)還會(huì)覆蓋新響應(yīng)造成渲染錯(cuò)亂。解決思路有兩個(gè)低配版是發(fā)請(qǐng)求前禁用按鈕拿完數(shù)據(jù)再恢復(fù)高配版是加 abort 控制把上一次未完成的 XHR 請(qǐng)求 cancel 掉let currentXhr null function fetchUsers(reset true) { if (currentXhr) { currentXhr.abort() } currentXhr request({ url, method: GET }) currentXhr.then(data { currentXhr null // 渲染邏輯... }) }abort 之后之前的 onreadystatechange 不會(huì)再觸發(fā)到 readyState 4也就不會(huì)產(chǎn)生覆蓋渲染。這個(gè)技巧在搜索框自動(dòng)補(bǔ)全、Tab 切換加載數(shù)據(jù)時(shí)非常有用比單純加 loading 鎖體驗(yàn)好很多。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 請(qǐng)求成功但頁(yè)面空白responseType 與 DOM 操作的坑有一種情況很詭異Network 面板里能看到響應(yīng)數(shù)據(jù)控制臺(tái)也沒(méi)報(bào)錯(cuò)但頁(yè)面就是空白。我排查過(guò)幾次最后發(fā)現(xiàn)原因多半出在 responseType 和 DOM 更新時(shí)機(jī)的配合上。比如你把 responseType 設(shè)成了 json然后又在代碼里用了 xhr.responseText此時(shí) responseText 是空字符串——因?yàn)闉g覽器在 responseType 不是 text 的時(shí)候不會(huì)填充 responseText數(shù)據(jù)都在 xhr.response 里。還有一類情況跟 DOM 相關(guān)你渲染數(shù)據(jù)的容器本身的 id 寫錯(cuò)了或者渲染函數(shù)執(zhí)行時(shí)容器還沒(méi)掛載到文檔里。雖然 script 放在 body 底部可以在很大程度上避免“找不到元素”的問(wèn)題但如果你的代碼是動(dòng)態(tài)插入的模塊執(zhí)行時(shí)機(jī)沒(méi)控制好document.getElementById 就有概率返回 null然后你還在 null 上操作 appendChild頁(yè)面自然就空了一截。這種問(wèn)題最簡(jiǎn)單的定位方式是在渲染函數(shù)入口處加一行 console.log(container)別急著懷疑數(shù)據(jù)鏈路。5.2 DOM 型 XSSinnerHTML 注入案例與防御方案剛才提到過(guò) DOM 型 XSS這里必須展開(kāi)講。本質(zhì)上它就是你往 innerHTML、document.write、outerHTML 這類“能解析 HTML 的賦值接口”里塞了不可信的字符串瀏覽器把其中的script標(biāo)簽或事件屬性當(dāng)成了可執(zhí)行代碼。XHR 拿到的響應(yīng)數(shù)據(jù)天然是“不可信”的哪怕它來(lái)自你自己的后端——因?yàn)楹蠖丝赡鼙坏谌轿廴緮?shù)據(jù)庫(kù)可能被注入臟數(shù)據(jù)甚至中間環(huán)節(jié)被篡改。一個(gè)典型的注入案例用戶搜索的關(guān)鍵詞是img srcx onerroralert(document.cookie)如果你的渲染代碼直接container.innerHTML p keyword /p那這段代碼就會(huì)執(zhí)行。防御方案最直接的就是把拼接的字符串全部轉(zhuǎn)義function escapeHtml(str) { const div document.createElement(div) div.appendChild(document.createTextNode(str)) return div.innerHTML }這招的原理是 createTextNode 創(chuàng)建的永遠(yuǎn)是文本節(jié)點(diǎn)瀏覽器不會(huì)把其中的標(biāo)簽當(dāng) HTML 解析然后我們?cè)偃∵@個(gè)文本節(jié)點(diǎn)的 innerHTML得到的自然就是轉(zhuǎn)義后的字符串。用它把 keyword 轉(zhuǎn)義后再拼進(jìn) innerHTML注入就失效了。如果你用的是 Vue 或 React 這類框架它們默認(rèn)的插值語(yǔ)法已經(jīng)做了轉(zhuǎn)義但 v-html / dangerouslySetInnerHTML 仍然是風(fēng)險(xiǎn)面規(guī)則一樣非絕對(duì)可信數(shù)據(jù)永遠(yuǎn)不進(jìn) HTML 解析接口。5.3 跨域報(bào)錯(cuò)、緩存干擾和狀態(tài)碼誤判實(shí)際項(xiàng)目里 XHR 最常見(jiàn)的兩大報(bào)錯(cuò)一個(gè)是跨域一個(gè)是緩存。跨域的典型表現(xiàn)是 Network 面板里請(qǐng)求顯示紅色Console 報(bào) “Access-Control-Allow-Origin” 相關(guān)錯(cuò)誤。處理方式要么后端配置 CORS 頭要么走同域代理轉(zhuǎn)發(fā)。如果你是純前端本地調(diào)試本地起一個(gè) proxy 服務(wù)或者用腳手架自帶的代理配置都能繞開(kāi)。這里有個(gè)值得記的細(xì)節(jié)跨域?qū)懺?XHR 請(qǐng)求失敗時(shí)會(huì)觸發(fā) onerror而錯(cuò)誤信息里不一定能看到 HTTP 狀態(tài)碼因?yàn)闉g覽器直接攔截了響應(yīng)status 會(huì)是 0。所以排查時(shí)可以先用 curl 直接測(cè)接口來(lái)判斷問(wèn)題到底出在服務(wù)端還是瀏覽器側(cè)。緩存干擾也是個(gè)隱形殺手。默認(rèn)情況下 XHR 遵循瀏覽器的 HTTP 緩存策略如果你的 GET 接口返回的響應(yīng)頭沒(méi)有設(shè)置 Cache-Control瀏覽器在某些場(chǎng)景下會(huì)直接命中緩存導(dǎo)致你改了后端代碼前端還是舊數(shù)據(jù)。排查辦法是臨時(shí)給 URL 加個(gè)時(shí)間戳參數(shù)url ?_t Date.now()。也可以在 XHR 上手動(dòng)加上Cache-Control: no-cache請(qǐng)求頭雖然這不是所有場(chǎng)景都有效但配合時(shí)間戳基本能解決開(kāi)發(fā)期 99% 的緩存問(wèn)題。狀態(tài)碼誤判也多說(shuō)一句。很多人只處理 200結(jié)果后端返回 201、204 或者 304 的時(shí)候就走了錯(cuò)誤分支。正確寫法是判斷xhr.status 200 xhr.status 300把 2xx 整個(gè)區(qū)間都視為成功304 根據(jù)場(chǎng)景單獨(dú)判斷是否有內(nèi)容可渲染。我自己封裝的那版 request 就是這么處理的用下來(lái)省了很多溝通成本。6. 性能與面試延伸從 XHR 渲染到虛擬 DOM 和 diff 算法6.1 直接操作 DOM 慢在哪兒這是一個(gè)被面試官反復(fù)蹂躪、但很多人只背結(jié)論不會(huì)展開(kāi)的點(diǎn)。直接操作 DOM 慢具體慢在三個(gè)環(huán)節(jié)一是 DOM 結(jié)構(gòu)變更后會(huì)觸發(fā)樣式計(jì)算Style Recalc、布局Layout、繪制Paint復(fù)雜頁(yè)面里這是一套重量級(jí)流程二是在循環(huán)里逐個(gè)修改節(jié)點(diǎn)會(huì)連續(xù)觸發(fā)這個(gè)過(guò)程比如在 for 循環(huán)里一個(gè)個(gè) appendChild三是頻繁的讀寫操作會(huì)打亂瀏覽器的渲染優(yōu)化機(jī)制造成強(qiáng)制同步布局Forced Synchronous Layout。拿我們的搜索列表來(lái)說(shuō)如果服務(wù)端返回 1000 條數(shù)據(jù)你在 forEach 里逐條 appendChild 而沒(méi)有使用 DocumentFragment瀏覽器就要在每一條插入后重新計(jì)算列表容器的尺寸和位置這種開(kāi)銷在小列表時(shí)無(wú)感數(shù)據(jù)一上量就卡。XHR 異步拿數(shù)據(jù)的場(chǎng)景天然就是“一次性大量數(shù)據(jù)涌入”的高發(fā)區(qū)所以這塊知識(shí)跟 XHR 是強(qiáng)相關(guān)的。6.2 虛擬 DOM 是怎么解決這個(gè)問(wèn)題的虛擬 DOM 的思路說(shuō)白了就是先在 JS 對(duì)象層面模擬出一棵“虛擬的 DOM 樹(shù)”數(shù)據(jù)變化時(shí)不直接動(dòng)真實(shí) DOM而是新生成一棵新的虛擬樹(shù)和舊虛擬樹(shù)做對(duì)比這個(gè)對(duì)比就是 diff找出最小差異集合最后統(tǒng)一把差異一次性提交到真實(shí) DOM。對(duì)比 JSON 對(duì)象屬性的開(kāi)銷要比觸發(fā)瀏覽器的布局和重繪小得多所以數(shù)據(jù)量大、變更頻繁時(shí)虛擬 DOM 能顯著減少真實(shí) DOM 操作次數(shù)。diff 算法面試的考點(diǎn)一般集中在同層對(duì)比、key 的作用、O(n) 復(fù)雜度的原因。你回答時(shí)可以帶著 XHR 的業(yè)務(wù)場(chǎng)景講比如列表數(shù)據(jù)刷新時(shí)如果給每一條列表項(xiàng)一個(gè)穩(wěn)定的 key比如用戶 iddiff 算法就能精確識(shí)別哪些是新增、哪些是刪掉、哪些只是順序變了從而只做最小的節(jié)點(diǎn)操作。如果沒(méi)有 key 或者用了 index 當(dāng) key列表重排時(shí) diff 的成本會(huì)升高甚至造成狀態(tài)錯(cuò)位——比如輸入框內(nèi)容串行。這個(gè)例子一說(shuō)面試官基本就知道你是真懂不是背的。6.3 原生 XHR 還在哪些場(chǎng)景有不可替代性有人可能會(huì)問(wèn)現(xiàn)在 axios 滿地走原生 XHR 還有必要掌握嗎坦誠(chéng)講業(yè)務(wù)代碼里直接裸寫 XHR 的情況越來(lái)越少但有三類場(chǎng)景它仍然有不可替代的江湖地位。第一類是上傳進(jìn)度的精確控制axios 底層用的就是 XHR它的 onprogress 事件可以拿到已上傳字節(jié)數(shù)fetch 的 upload 進(jìn)度到現(xiàn)在都還是“半殘”狀態(tài)。第二類是請(qǐng)求的中斷和超時(shí)控制xhr.abort() 和 xhr.timeout 是穩(wěn)定的多年 APIfetch 的 AbortController 雖然也能用但在兼容性和細(xì)節(jié)上不如 XHR 來(lái)得皮實(shí)。第三類是適配老代碼庫(kù)很多存量系統(tǒng)或者低版本瀏覽器環(huán)境只認(rèn) XHR。所以我的建議是你可以不用原生 XHR但你得有能力隨時(shí)揭開(kāi) axios 那層封裝看到底下是什么。尤其是維護(hù)老項(xiàng)目、或者在一些特殊網(wǎng)絡(luò)環(huán)境下排障時(shí)打開(kāi)控制臺(tái)看到那堆 XMLHttpRequest 相關(guān)的信息如果你腦子里沒(méi)這張圖會(huì)非常被動(dòng)。7. 個(gè)人實(shí)戰(zhàn)經(jīng)驗(yàn)總結(jié)最后分享幾個(gè)我對(duì)這個(gè)主題最真實(shí)的體會(huì)。一是寫 XHR 請(qǐng)求之前先把數(shù)據(jù)結(jié)構(gòu)和渲染容器想清楚再動(dòng)手代碼不是越少越好是越明確越好我在多個(gè)人項(xiàng)目里發(fā)現(xiàn)最痛苦的不是請(qǐng)求失敗而是請(qǐng)求成功后不知道數(shù)據(jù)往哪兒放。二是 DOM 操作守一條底線所有外部輸入和接口返回的數(shù)據(jù)默認(rèn)當(dāng)成“危險(xiǎn)品”處理能用 textContent 絕不直接拼 HTML真要用 innerHTML 先過(guò)一遍轉(zhuǎn)義函數(shù)這個(gè)習(xí)慣能替你擋掉至少五成以上的安全問(wèn)題。三是一定要敢用 XHR 的進(jìn)階能力onprogress、timeout、abort 這些方法看著老實(shí)則在處理大文件上傳、搜索防抖、并發(fā)競(jìng)態(tài)這些場(chǎng)景里異常好用比你在外面找的各種封裝庫(kù)反而更穩(wěn)。XHR 和 DOM 這對(duì)組合說(shuō)穿了就是數(shù)據(jù)與呈現(xiàn)的關(guān)系。你把它倆的原理吃透再看任何現(xiàn)代前端框架——不管是虛擬 DOM 還是各種請(qǐng)求庫(kù)——都會(huì)有一種“原來(lái)都是從這里長(zhǎng)出來(lái)”的通透感。項(xiàng)目里多用幾次踩過(guò)幾個(gè)真實(shí)的坑這些東西就會(huì)變成你身體里的肌肉記憶遇到問(wèn)題不用翻文檔就能下意識(shí)地排除掉一片可能性。