在前端开发领域，网络请求一直是非常关键的一环，早期我们主要依赖 XMLHttpRequest（XHR）来实现客户端与服务器之间的异步数据交换。它允许浏览器向服务器发送 HTTP 请求，获取数据并更新部分网页内容，无需刷新整个页面，在 Web 开发中广泛用于动态内容加载、表单提交、数据交互等功能，像实现 AJAX 请求就常借助它，也正因如此，它为用户带来了更加流畅的使用体验。不过，XHR 也存在一些不足，其使用起来相对复杂，需要手动创建、配置和发送请求，还要监听事件来处理响应，例如通过设置 onreadystatechange 事件监听器或使用 addEventListener 方法来处理异步请求的状态变化。并且，由于 XHR 可以跨域请求数据，可能会涉及到安全性问题，所以在使用时得谨慎处理跨域请求以及防止 XSS 攻击等情况。随着技术的发展，Fetch 请求应运而生，它是较新的浏览器提供的 API，旨在简化和优化前端开发中的网络请求过程。与传统的 XMLHttpRequest 相比，Fetch 使用起来更加简洁和易用，它返回一个 Promise 对象，能使用链式调用来处理请求和响应，像我们可以使用 then 和 catch 方法轻松处理请求的成功和失败情况，避免了像 XHR 那样陷入较为复杂的回调设置中。举个简单的例子，如果我们想要请求一个 URL 地址，获取响应数据并将数据转换成 JSON 格式，使用 XMLHttpRequest 来实现需要设置两个监听函数，分别处理成功和失败的情况，同时还得依次调用 open () 和 send () 方法才能完成请求；而使用 Fetch 实现的话，像这样：fetch('./api/some.json').then(function(res) {if (res.status!==200) {console.log('Looks like there was a problem. Status Code: ' + res.status);return;}// 处理响应中的文本信息 res.json().then(function(data) {console.log(data);});}).catch(function(err) {console.log('Fetch Error : %S', err);})，代码逻辑清晰简洁不少。而且，Fetch 还具有更好的灵活性，支持流处理、跨域请求等高级功能，在处理大数据和文件上传时会更加方便，也可以通过 Request 和 Response 对象进行扩展和自定义，让开发者拥有更高的可控性。虽然 Fetch 是标准中的新 API，在一些旧版本的浏览器中可能不被完全支持，但为了兼容旧版本浏览器，我们可以使用 fetch 的 polyfill 或者选择其他库（如 Axios）来进行网络请求。总之，在当下的前端开发中，Fetch 请求凭借其自身优势，已然成为了前端通信的新利器，为开发者处理网络请求提供了更优的选择。

二、Fetch 基本使用全解析

（一）语法结构与参数说明

Fetch 的基本语法为 fetch(url, options)。其中，url 是要获取资源的地址，可以是绝对路径或相对路径。例如，'https://example.com/api/data' 或者 './data.json'。options 是一个可选参数，于配置请求的各种细节，它是一个对象，包含以下常用属性：：表示请求方法，如 GET、POST、PUT、ｄｅｌｅｔｅ 等。默认是 GET。headers：用于设置请求头信息，是一个对象。例如 { 'Content-Type': 'application/json' } 用于指定请求体数据为 JSON 格式。body：通常在 POST 或 PUT 请求中使用，用于传递请求体数据。它可以是字符串、FormData 对象、Blob 对象等。例如，JSON.stringify({ key: 'value' }) 可将一个 JavaScript 对象转换为 JSON 字符串作为请求体数据。

（二）GET 请求示例

在这个示例中，首先使用 fetch 发送一个 GET 请求到指定的 URL。然后，通过 then 方法处理响应。先检查 response.ok 属性，如果请求不成功（状态码不是 200 - 299 之间），则抛出一个错误。接着，使用 response.json() 方法将响应体数据解析为 JSON 格式，并在后续的 then 方法中处理解析后的数据，将其打印到控制台。如果请求过程中出现错误，catch 方法会捕获并打印错误信息。

（三）POST 请求示例

在这个例子中，先创建了一个包含数据的对象 postData。然后，在 fetch 请求中，将 method 设置为 POST，并通过 headers 设置请求头为 'Content-Type': 'application/json'，表示请求体数据为 JSON 格式。接着，使用 JSON.stringify 方法将 postData 对象转换为 JSON 字符串，并赋值给 body 属性。最后，像 GET 请求示例一样，处理响应数据，将服务器返回的数据解析为 JSON 格式并打印到控制台，如果有错误则捕获并打印错

三、深入理解 Fetch 的特性与坑

（一）响应处理的细节

在 Fetch 请求中，response.ok 属性是一个非常重要的指示符，它用于判断 HTTP 状态码是否处于 200 - 299 这个成功的区间范围内。当我们发起一个 Fetch 请求后，服务器会返回一个响应，这个响应包含了各种信息，其中 HTTP 状态码就反映了请求的处理结果。如果 response.ok 的值为 true，则表示请求成功，例如常见的 200 状态码表示请求已成功处理并返回了预期的数据。然而，如果 response.ok 为 false，这就意味着请求出现了问题，可能是 404 表示资源未找到，或者 500 表示服务器内部错误等情况。与传统的一些请求方式不同，Fetch 对于非网络错误的 HTTP 状态码（如 404、500）不会自动 reject Promise。这是因为 Fetch 的设计理念是将网络请求的成功与具体业务逻辑的成功分开处理。在很多情况下，即使服务器返回了一个表示错误的状态码，如 403 表示权限不足，前端应用可能仍然需要根据这个信息进行相应的处理，而不是简单地将其视为一个失败的请求而中断后续流程。所以，Fetch 会在 then 方法中处理这些非网络错误的情况，让开发者能够更灵活地根据不同的状态码进行自定义的处理逻辑。例如，当收到 401 状态码时，我们可以在 then 中提示用户进行登录操作，以获取正确的权限。但是，为了能够统一处理错误情况，我们通常需要手动抛出错误。这样做的好处是可以将错误处理逻辑集中在 catch 方法中，使代码结构更加清晰，易于维护。比如在一个数据获取的请求中，如果服务器返回了 404 状态码，我们可以在 then 方法中检查 response.ok 属性，如果为 false，则抛出一个带有详细错误信息的自定义错误对象，像这样：通过这种方式，无论是网络错误还是业务逻辑错误，都能够在 catch 方法中被统一捕获和处理，方便我们进行错误日志记录、用户提示等操作，提升应用的稳定性和用户体验。

（二）跨域请求与 CORS

Fetch 请求遵循 CORS（跨域资源共享）策略。同源策略是浏览器的一种安全机制，它规定只有当两个 URL 的协议、域名和端口完全相同时，才被认为是同源的。例如，https://www.example.com 和 https://www.example.com:8080 由于端口不同，就属于非同源；http://www.example.com 和 https://www.example.com 因为协议不同，也不是同源的。在同源策略的限制下，浏览器默认会阻止跨域请求，以防止恶意网站窃取用户数据或进行其他不安全的操作。而 CORS 机制则是为了在保证安全的前提下，允许跨域请求资源而设立的。当我们使用 Fetch 进行跨域请求时，浏览器会自动在请求头中添加 Origin 字段，这个字段标明了请求的源信息，即当前页面的协议、域名和端口。服务器在接收到请求后，会根据这个 Origin 字段以及自身的配置来决定是否允许该跨域请求。如果服务器允许，它会在响应头中添加相应的 Access-Control-Allow-Origin 字段，告诉浏览器该请求被允许。例如，服务器端可以这样设置响应头：这就表示允许来自 http://example.com 的跨域请求。在实际开发中，不同场景下可能会遇到各种跨域问题。在开发环境中，如果我们使用本地开发服务器（如 http://localhost:3000）进行开发，并且需要向另一个本地的后端服务（如 http://localhost:8080）发起跨域请求，就需要在后端服务中正确配置 CORS。一些常见的后端框架（如 Node.js 的 Express 框架）提供了简单的方式来配置 CORS，例如：不过，在生产环境中，我们通常不能使用通配符 * 来允许所有源的跨域请求，而是需要明确指定允许的源，以提高安全性。例如：此外，如果跨域请求涉及到发送 cookies 等凭证信息，还需要在服务器端和客户端都进行相应的设置。在服务器端，除了设置 Access-Control-Allow-Origin 外，还需要设置 Access-Control-Allow-Credentials 为 true，并且 Access-Control-Allow-Origin 不能为通配符 *，必须指定具体的源。在客户端，使用 Fetch 发起请求时，需要设置 credentials 选项为 'include'，如下所示：

（三）Cookie 传递问题

Fetch 默认情况下不会自动发送或接收 cookies。这是因为在某些场景下，不发送 cookies 可以减少不必要的网络流量和潜在的安全风险。例如，对于一些公开的资源获取请求，不需要携带用户的身份认证信息（cookies）。然而，在很多实际应用中，特别是涉及到用户认证、会话保持等功能时，正确处理 cookies 是至关重要的。如果站点依赖于用户 session，而 Fetch 又不发送 cookies，就会导致请求无法通过用户认证，从而返回未经认证的结果。为了改变这种情况，我们可以通过设置 credentials 选项来控制 cookies 的行为。当 credentials 选项设置为 'include' 时，Fetch 会在请求中包含 cookies，并且在响应中也会接收并保存服务器设置的 cookies。例如，在一个用户登录后进行数据获取的场景中：这样，浏览器就会将与该域名相关的 cookies 发送到服务器，服务器根据这些 cookies 中的信息（如用户 session ID）来识别用户身份，并返回相应的用户信息。如果不设置 credentials 选项或者设置为其他值（如 'omit' 表示忽略 cookies），则可能导致服务器无法识别用户，返回错误的结果或者要求用户重新登录。

四、Fetch 高级应用与优化技巧

（一）请求的封装与复用

在实际的前端项目开发中，我们经常会在多个地方发起相同类型的 Fetch 请求，例如获取用户信息、查询数据列表等。如果每次请求都直接编写 Fetch 代码，不仅会导致代码冗余，还会增加维护成本。因此，将 Fetch 请求封装成一个函数是非常有必要的。下面是一个简单的 Fetch 请求封装函数示例：在上述代码中，fetchData 函数接受 url、method、data 和 headers 等参数，根据这些参数构建 fetch 请求的配置对象 options，并发起请求。如果请求成功且响应状态码在 200 - 299 之间，函数将解析响应数据并返回；如果请求失败或响应状态码异常，函数将抛出错误。通过这样的封装，我们可以在项目中方便地复用 fetch 请求代码。例如，在获取用户信息的组件中：在查询数据列表的组件中：这样，我们只需要维护 fetchData 函数的代码，就可以在整个项目中进行统一的 fetch 请求处理，提高了代码的可维护性和复用性。同时，我们还可以在封装函数中添加更多的功能，如统一处理加载状态、错误提示等。例如，我们可以在函数内部添加一个 isLoading 变量来表示请求的加载状态，在请求发起前将其设置为 true，在请求完成后设置为 false，并通过回调函数或事件通知的方式将加载状态传递给调用者，以便在界面上显示相应的加载提示。

（二）结合 Async/Await 使用

Async/Await 是 JavaScript 中处理异步操作的语法糖，它使得编写和理解异步代码更加简洁和直观。在使用 Fetch 请求时，结合 Async/Await 可以让代码看起来更像同步代码，避免了传统的 then 链嵌套带来的回调地狱问题。在上述示例中，fetchUserData 函数被定义为一个异步函数，使用 await 关键字等待 fetch 请求的完成。当 fetch 请求返回响应后，继续使用 await 等待 response.json() 方法将响应数据解析为 JSON 格式。这样的代码结构清晰，易于理解和调试，与同步代码的执行逻辑相似。与使用 then 链的方式相比，Async/Await 的优势在于减少了代码的嵌套层级，使代码更加扁平化。例如，使用 then 链实现相同功能的代码如下：可以看到，then 链的方式会导致代码嵌套，当处理多个 then 回调时，代码的可读性会逐渐降低。而 Async/Await 则能够以更线性的方式编写异步代码，提高了代码的可维护性。此外，Async/Await 还能更好地与其他异步操作（如 Promise.all）结合使用，方便地实现并发请求等复杂逻辑在上述示例中，使用 Promise.all 并发发送两个 Fetch 请求，然后使用 await 等待所有请求完成。接着，分别处理每个请求的响应数据。这种方式使得并发请求的代码更加简洁明了，易于理解和维护。

五、项目实战：Fetch 在真实场景中的应用

（一）案例介绍：从开放 API 获取数据并展示

在这个实战项目中，我们将构建一个简单的网页应用，从一个开放的 API 获取数据并展示在页面上。这里以获取 GitHub 上某个特定用户的公开仓库信息为例。

（二）搭建项目环境

首先，创建一个 HTML 文件，作为项目的入口页面。在 HTML 文件中，引入一个 JavaScript 文件，用于编写我们的 Fetch 代码。

（三）编写 Fetch 代码

在 ｓｃｒｉｐｔ.js 文件中，使用 Fetch 来获取 GitHub API 的数在上述代码中，首先定义了要请求的 API 地址，即 https://api.github.com/users/octocat/repos，这将获取 octocat 用户的公开仓库信息。然后使用 fetch 发起请求，获取响应后，先检查响应状态码，如果不是 200 - 299 之间，则抛出错误。接着将响应数据解析为 JSON 格式，并在后续的 then 方法中遍历数据，为每个仓库创建一个列表项，并将其添加到页面上的 repo-list 元素中。如果请求过程中出现错误，catch 方法会捕获并打印错误信息。

（四）可能遇到的问题及解决方案

1. 跨域问题

如果在本地开发环境中直接运行上述代码，可能会遇到跨域问题，因为浏览器的同源策略限制了跨域请求。解决这个问题，可以在后端服务器上设置 CORS 头信息，允许来自本地开发环境的跨域请求。如果是使用一些本地开发服务器，如 Node.js 的 Express 框架，可以添加如下代码来允许跨域请求：或者，如果是使用 GitHub API，可以利用其支持 JSONP 的特性，通过 fetch-jsonp 库来进行跨域请求。首先安装 fetch-jsonp：

2. 数据处理问题

获取到的数据可能需要进行进一步的处理和转换，才能满足页面展示的需求。例如，上述代码中只是简单地展示了仓库的名称，如果想要展示更多信息，如仓库的描述、创建时间等，就需要对数据进行相应的处理和 HTML 模板的构建。在这个修改后的代码中，为每个仓库创建了一个更详细的列表项，包括仓库名称、描述（如果有）和创建时间，并使用 innerHTML 来插入 HTML 模板字符串，以更好地展示仓库信息。

六、总结与展望

通过对 Fetch 请求的详细探讨，我们可以看到它在前端开发中具有诸多优势。其简洁的语法、基于 Promise 的异步处理机制、对现代网络功能的支持以及丰富的 API ，都使得它成为了处理网络请求的有力工具。在实际项目中，我们深入了解了它的基本使用方法、特性与坑以及高级应用与优化技巧，并通过从开放 API 获取数据并展示的项目实战，进一步掌握了其在真实场景中的应用。然而，Fetch 请求也并非十全十美，如兼容性问题、Cookie 处理、超时控制和请求进度监测等方面仍存在一些不足。但随着技术的不断发展，我们可以期待 Fetch 在未来会有更好的表现。例如，浏览器厂商可能会进一步优化其兼容性，使其能够在更多的浏览器环境中稳定运行；社区也可能会开发出更多的工具和库来弥补其功能上的短板，如更完善的 polyfill 来增强旧浏览器的支持，或者提供更方便的超时控制和请求进度监测的解决方案。在未来的前端开发中，Fetch 请求有望继续发挥重要作用，并与其他技术（如 Service Workers、WebSockets 等）更好地结合，为用户带来更加高效、流畅和功能丰富的 web 应用体验。希望读者们能够在实际项目中积极运用 Fetch 请求，不断探索和实践，提升自己的开发效率与应用的用户体验。