xmlhttprequest（xhr）在前端与服务器交互中依然有其价值，主要原因有三点：1. 浏览器兼容性极佳，适用于维护老旧项目；2. 提供底层控制能力，如请求进度监听，适合大文件上传等场景；3. 许多旧库基于xhr封装，理解其原理有助于调试和深入掌握网络请求机制。
谈到前端与服务器交互，XMLHttpRequest（XHR）无疑是一个绕不开的话题。简单来说，它就是浏览器提供的一套API，让JavaScript能够发送HTTP请求到服务器，并在不刷新整个页面的情况下接收响应。这正是我们常说的AJAX（Asynchronous JavaScript and XML）技术的核心，它让网页体验从“点击刷新”走向了“无缝加载”的时代。
解决方案
使用XMLHttpRequest进行网络请求，基本步骤是这样的：
-
创建XHR对象：这是所有操作的起点。
立即学习“Java免费学习笔记（深入）”；
const xhr = new XMLHttpRequest();
-
配置请求：使用
open()方法指定请求方法（GET, POST等）、URL和是否异步。xhr.open('GET', '/api/data', true); // GET请求到/api/data，异步 -
设置回调函数：监听请求状态的变化。最常用的是
onreadystatechange，它会在readyState属性改变时触发。readyState有五个值：
- 0: UNSENT (未初始化)
- 1: OPENED (已打开)
- 2: HEADERS_RECEIVED (已发送，接收到头信息)
- 3: LOADING (下载中，接收到部分数据)
- 4: DONE (完成，所有数据已接收)
当
readyState为4且status为200时，表示请求成功并接收到完整响应。 也可以使用更现代的onload和onerror事件监听。xhr.onreadystatechange = function() { if (xhr.readyState === 4) { if (xhr.status >= 200 && xhr.status < 300) { // 请求成功 console.log('响应数据:', xhr.responseText); } else { // 请求失败 console.error('请求失败，状态码:', xhr.status); } } };
// 或者使用更简洁的事件监听 xhr.onload = function() { if (xhr.status >= 200 && xhr.status
xhr.onerror = function() { console.error('网络错误或请求被阻止。'); };
-
发送请求：使用
send()方法发送请求。如果是POST请求，数据会作为参数传给send()。xhr.send(); // 对于GET请求，send()通常不带参数 // 对于POST请求，可能需要设置Content-Type并发送数据 // xhr.setRequestHeader('Content-Type', 'application/json'); // xhr.send(JSON.stringify({ key: 'value' }));
为什么在现代Web开发中，XMLHttpRequest依然有其一席之地？
尽管前端世界日新月异，fetch API等新星层出不穷，但XMLHttpRequest这老伙计依然没有完全退出历史舞台。我个人觉得，这主要有几个原因。首先，它的浏览器兼容性简直是无敌的。你几乎不用担心任何主流甚至一些老旧浏览器不支持XHR，这对于维护一些历史项目或者需要极致兼容性的场景来说，是个巨大的优势。
其次，XHR提供了一些底层控制能力，比如它内置了对请求进度（onprogress事件）的良好支持，这在上传大文件或者需要展示精确进度条的场景下，用起来比fetch要直观方便不少，fetch需要一些额外的操作才能实现类似效果。再者，很多现有的JavaScript库和框架，特别是那些年代稍久远的，它们的底层网络请求依然是基于XHR封装的。理解XHR的工作原理，对于我们深入理解这些库的运作机制，以及调试一些老代码中的网络问题，都是非常有帮助的。它就像是Web请求的“根基”，即便上面盖了高楼大厦，地基的知识依然重要。
当然，这并不是说它比fetch更好，而是说它有其存在的合理性，特别是在特定的需求和历史背景下。
如何处理XMLHttpRequest的异步操作和常见的错误？
处理XHR的异步操作，最经典的方式就是依赖回调函数。就像前面提到的onreadystatechange，它会在请求的不同生命周期阶段被触发。这种基于事件和回调的模式，在处理简单请求时没问题，但如果你的业务逻辑涉及到多个串联的请求，或者需要复杂的错误处理和状态管理，就很容易陷入所谓的“回调地狱”（Callback Hell），代码会变得层层嵌套，难以阅读和维护。
为了缓解这个问题，现代JavaScript中我们通常会用Promise来封装XHR，或者直接使用async/await语法糖。虽然XHR本身不返回Promise，但我们可以很容易地把它包装起来：
function makeRequest(method, url, data = null) {
return new Promise((resolve, reject) => {
const xhr = new XMLHttpRequest();
xhr.open(method, url, true);
xhr.onload = function() {
if (xhr.status >= 200 && xhr.status < 300) {
resolve(xhr.responseText);
} else {
reject(new Error(`HTTP Error: ${xhr.status} ${xhr.statusText}`));
}
};
xhr.onerror = function() {
reject(new Error('Network error or request aborted.'));
};
if (data) {
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.send(JSON.stringify(data));
} else {
xhr.send();
}
});
}
// 使用Promise封装后的XHR
makeRequest('GET', '/api/users')
.then(response => {
console.log('用户数据:', response);
})
.catch(error => {
console.error('获取用户数据失败:', error);
});至于常见的错误，主要有几类：
-
网络错误（Network Error）：这通常发生在请求无法发送或在传输过程中中断时，比如用户断网、服务器宕机、DNS解析失败等。
onerror事件就是用来捕获这类错误的。 -
HTTP状态码错误：服务器成功接收并处理了请求，但返回了一个非2xx的状态码，比如404（未找到）、401（未授权）、500（服务器内部错误）等。这类错误需要你在
onreadystatechange或onload中通过检查xhr.status来判断。 -
跨域请求（CORS）问题：当你的前端页面尝试请求一个与当前页面不同源（协议、域名、端口任一不同）的资源时，浏览器会执行同源策略。如果服务器没有正确配置CORS响应头（如
Access-Control-Allow-Origin），请求就会被浏览器拦截，导致onerror触发，或者虽然请求发出了但响应被浏览器屏蔽。这是前端开发中非常常见且让人头疼的问题，通常需要在后端进行配置。 -
超时（Timeout）：如果请求在设定的时间内没有得到响应，XHR会触发
ontimeout事件。你可以通过xhr.timeout = milliseconds来设置超时时间。
处理这些错误的关键在于细致的错误捕获和清晰的错误信息反馈，让用户知道发生了什么，或者方便开发者调试。
XMLHttpRequest与Fetch API相比，有哪些优劣势？
当我们在讨论XHR时，很难不把它和现代的fetch API拿出来比较。它们都是浏览器提供的网络请求方式，但设计理念和使用方式上有着明显的差异。
XMLHttpRequest的优势：
- 成熟且兼容性极佳：这是它最大的资本，几乎所有浏览器都支持，无需担心兼容性问题。
-
内置进度事件：
onprogress、onloadstart、onloadend等事件，对于文件上传下载等需要实时进度反馈的场景，用起来非常直接方便。 -
可中断请求：通过
xhr.abort()方法，可以随时取消一个正在进行的请求。
XMLHttpRequest的劣势：
- API设计相对老旧和繁琐：基于事件和回调的模式，对于复杂的异步流程，容易导致代码可读性差，陷入回调地狱。
- 不直接支持Promise：虽然可以通过封装实现Promise化，但原生API并非基于Promise，与现代JavaScript的异步编程风格不符。
-
处理JSON不够直接：通常需要手动解析
responseText为JSON。
Fetch API的优势：
-
Promise化设计：原生返回Promise，与
async/await结合使用，使得异步代码更加简洁、直观、易读，彻底摆脱回调地狱。 -
API设计更现代化和模块化：
Request和Response对象的使用，让请求和响应的处理更加清晰和灵活。 -
默认处理JSON：
response.json()方法直接返回解析后的JSON数据，非常方便。 - 支持流（Streams）：可以处理大型响应数据流，提高性能。
Fetch API的劣势：
-
不直接支持请求进度：虽然可以通过
ReadableStream实现，但不如XHR的onprogress事件直接。 -
对HTTP错误码不抛出异常：
fetch只有在网络错误时才reject Promise，对于4xx或5xx等HTTP错误码，它依然会resolve，需要手动检查response.ok或response.status来判断请求是否成功。这在使用时需要特别注意，否则很容易漏掉服务器返回的业务错误。 -
无法直接中断请求：需要配合
AbortController才能实现请求的取消。 - 兼容性不如XHR：虽然现在主流浏览器支持度已经很高，但在一些老旧环境中可能仍需polyfill。
总的来说，对于新的项目开发，fetch API因其现代化的Promise设计和简洁的API，通常是首选。但XHR依然有其不可替代的价值，尤其是在处理特定需求（如进度条）和维护老旧代码时。理解两者，才能在实际开发中做出更合适的选择。
