还在死磕 Ajax？那可就 out 了！

江山代有人才出，各领风骚数百年。

前言

想当年面试时，AJAX 基本是必考题，像什么“异步调用、高性能”等是必答的。那时的 AJAX 是真的火，前端就没有不用 AJAX 的。

然而，古语云“人无百日好，花无百日红”，又云“江山代有人才出，各领风骚数百年”，对于 AJAX，当然也不例外。

这不，在最近这两年，我们明显可以发现很多新生框架中都有了 Fetch 的影子，而它的易用性和稳定性也是得到了反复验证的。

Fetch 的概念

Fetch 提供了对 Request 和 Response （以及其他与网络请求有关的）对象的通用定义。使之今后可以被使用到更多的应用场景中：无论是 service worker、Cache API、又或者是其他处理请求和响应的方式，甚至是任何一种需要你自己在程序中生成响应的方式。

它同时还为有关联性的概念，例如CORS和HTTP原生头信息，提供一种新的定义，取代它们原来那种分离的定义。

发送请求或者获取资源，需要使用 WindowOrWorkerGlobalScope.fetch() 方法。它在很多接口中都被实现了，更具体地说，是在 Window 和 WorkerGlobalScope 接口上。因此在几乎所有环境中都可以用这个方法获取到资源。

兼容性

要看一个新的 API 会不会火起来，最简单的办法就是看它的兼容性，毕竟，如果兼容性不好，那再好用的 API 也很难火起来。

可以看到，Fetch  方法对除 IE 之外的浏览器来说，兼容性简直不要太好，这可以说是已经拥有了大火的前提条件。

和 AJAX 的区别

既然是用来替代 AJAX 的，那必然是有一些 AJAX 所不具备的特性优势了，否则，凭啥取代啊。

总结一下，区别如下：

• Fetch 使用 Promise，不使用回调函数，因此大大简化了写法，写起来更简洁。

• Fetch 采用模块化设计，API 分散在多个对象上（Response 对象、Request 对象、Headers 对象），更合理一些；相比之下，XMLHttpRequest 的 API 设计并不是很好，输入、输出、状态都在同一个接口管理，容易写出非常混乱的代码。

• Fetch 通过数据流（Stream 对象）处理数据，可以分块读取，有利于提高网站性能表现，减少内存占用，对于请求大文件或者网速慢的场景相当有用。XMLHTTPRequest 对象不支持数据流，所有的数据必须放在缓存里，不支持分块读取，必须等待全部拿到后，再一次性吐出来。

Fetch 是相当符合潮流的，至少，我们可以少写很多回调函数了，代码的逼格也可以有所提升了。

Fetch 的用法

fetch() 方法必须接受一个参数——资源的路径。无论请求成功与否，它都返回一个 Promise 对象，resolve 对应请求的 Response。基本语法如下：

fetch(url)  .then(...)  .catch(...)

举个例子：

fetch('https://bianchengsanmei.com/getInfo')  .then(response => response.json())  .then(json => console.log(json))  .catch(err => console.log('Request Failed', err));

上面例子中，fetch() 接收到的 response 是一个 Stream 对象，response.json() 是一个异步操作，取出所有内容，并将其转为 JSON 对象。

Promise 可以使用 await 语法改写，使得语义更清晰：

async function getJSON() {  let url = 'https://bianchengsanmei.com/getInfo';  try {    let response = await fetch(url);    return await response.json();  } catch (error) {    console.log('Request Failed', error);  }}

上面示例中，await 语句必须放在 try...catch 里面，这样才能捕捉异步操作中可能发生的错误。

总结

所谓时势造英雄，因 JavaScript 标准的飞速发展，AJAX 起来了，却即将落下，Fetch 又能走多远，让我们拭目以待。

以上就是关于 Fetch 的一些总结，主要是学习借鉴前辈大佬们的文章教程，希望多少能带给你一点收获！

~

~本文完，感谢阅读！

参考文档：

Fetch API

Fetch API 教程