XMLHttpRequest作用与使用详解

在JavaScript中，XMLHttpRequest（XHR）作为前端与服务器交互的重要桥梁，至今仍发挥着不可替代的作用。尽管现代Web开发涌现出如Fetch API等更为先进的技术，但XHR凭借其卓越的浏览器兼容性，尤其是在维护老旧项目时，优势显著。此外，XHR提供的底层控制能力，例如对请求进度的监听，使其在大文件上传等场景中表现出色。同时，理解XHR的原理，有助于开发者深入掌握基于XHR封装的旧库，从而更好地调试和解决网络请求相关问题。本文将深入探讨XMLHttpRequest的作用、使用方法，以及在现代Web开发中的价值，并对比其与Fetch API的优劣势，助您在实际开发中做出更合适的选择。

XMLHttpRequest（XHR）在前端与服务器交互中依然有其价值，主要原因有三点：1. 浏览器兼容性极佳，适用于维护老旧项目；2. 提供底层控制能力，如请求进度监听，适合大文件上传等场景；3. 许多旧库基于XHR封装，理解其原理有助于调试和深入掌握网络请求机制。

谈到前端与服务器交互，XMLHttpRequest（XHR）无疑是一个绕不开的话题。简单来说，它就是浏览器提供的一套API，让JavaScript能够发送HTTP请求到服务器，并在不刷新整个页面的情况下接收响应。这正是我们常说的AJAX（Asynchronous JavaScript and XML）技术的核心，它让网页体验从“点击刷新”走向了“无缝加载”的时代。

解决方案

使用XMLHttpRequest进行网络请求，基本步骤是这样的：

1. 创建XHR对象：这是所有操作的起点。

   

   const xhr = new XMLHttpRequest();

2. 配置请求：使用open()方法指定请求方法（GET, POST等）、URL和是否异步。

   xhr.open('GET', '/api/data', true); // GET请求到/api/data，异步

3. 设置回调函数：监听请求状态的变化。最常用的是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 < 300) { console.log('响应数据 (onload):', xhr.responseText); } else { console.error('请求失败 (onload)，状态码:', xhr.status); } };

   xhr.onerror = function() { console.error('网络错误或请求被阻止。'); };

4. 发送请求：使用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);
    });

至于常见的错误，主要有几类：

1. 网络错误（Network Error）：这通常发生在请求无法发送或在传输过程中中断时，比如用户断网、服务器宕机、DNS解析失败等。onerror事件就是用来捕获这类错误的。
2. HTTP状态码错误：服务器成功接收并处理了请求，但返回了一个非2xx的状态码，比如404（未找到）、401（未授权）、500（服务器内部错误）等。这类错误需要你在onreadystatechange或onload中通过检查xhr.status来判断。
3. 跨域请求（CORS）问题：当你的前端页面尝试请求一个与当前页面不同源（协议、域名、端口任一不同）的资源时，浏览器会执行同源策略。如果服务器没有正确配置CORS响应头（如Access-Control-Allow-Origin），请求就会被浏览器拦截，导致onerror触发，或者虽然请求发出了但响应被浏览器屏蔽。这是前端开发中非常常见且让人头疼的问题，通常需要在后端进行配置。
4. 超时（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依然有其不可替代的价值，尤其是在处理特定需求（如进度条）和维护老旧代码时。理解两者，才能在实际开发中做出更合适的选择。

理论要掌握，实操不能落！以上关于《XMLHttpRequest作用与使用详解》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！