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.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依然有其不可替代的价值，尤其是在处理特定需求（如进度条）和维护老旧代码时。理解两者，才能在实际开发中做出更合适的选择。
