别再搞混Ajax和Fetch！一篇讲透两者核心区别 开发者必看

其实很多开发者对两者的理解停留在“能发请求”的表层，却没摸透它们的核心差异——从底层依赖的技术（Ajax靠XMLHttpRequest，Fetch是浏览器原生API），到语法风格（回调地狱vs Promise链式调用），再到错误处理（Ajax要自己判断状态码，Fetch只对网络错误抛异常）、兼容性（Ajax支持更老浏览器，Fetch需 polyfill）甚至缓存机制，每一点都藏着影响开发效率的细节。

这篇文章就把这些绕不开的区别掰碎了讲：不用复杂术语，直接用真实场景对比；不管你是刚入门的新手想搞懂基础，还是想优化代码的老司机想避坑，看完就能清楚——什么时候该用Ajax稳扎稳打，什么时候该选Fetch更简洁，再也不用对着请求报错抓耳挠腮。

你有没有过这种情况？写前端请求的时候，明明都是拿数据，用Ajax的时候要写一堆onreadystatechange，用Fetch的时候又突然遇到“怎么404不报错”的困惑？我前两年帮一个刚转行的前端朋友调代码，他盯着屏幕问我：“这俩不都是发请求吗？为啥用法差这么多？”我当时就想，好多开发者对Ajax和Fetch的理解就停在“能发请求”，但其实它们的核心区别藏在底层逻辑、语法习惯和实战细节里，这些细节没搞懂，写代码的时候准踩坑。

从底层逻辑到语法，先搞懂两者的“出身”差异

先给你扒扒两者的“底细”——Ajax其实不是一个“具体的API”，而是“Asynchronous JavaScript and XML”的缩写，本质是用XMLHttpRequest（XHR）对象实现的异步请求方案。我刚学前端的时候，写Ajax得这么来：先new一个XMLHttpRequest，然后open方法传请求方式和地址，再send，还要绑onreadystatechange事件，判断readyState是不是4（请求完成），status是不是200-300（成功）。比如我早年写过一个用户登录的请求，代码是这样的：

const xhr = new XMLHttpRequest();
xhr.open('POST', '/login');
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.onreadystatechange = function() {
 if (xhr.readyState === 4) {
 if (xhr.status >= 200 && xhr.status < 300) {
 const res = JSON.parse(xhr.responseText);
 // 处理成功逻辑
 } else {
 // 处理错误
 }
 }
};
xhr.send(JSON.stringify({ username: 'test', password: '123' }));

你看，光写这些就得十几行，还容易漏判status——我当时就犯过错，把status写成了200，结果304（缓存）的情况没处理，导致用户刷新页面的时候数据没更新。

而Fetch就不一样了，它是浏览器原生的异步请求API，是W3C在2015年推出的“现代方案”。它的设计更符合现代JS的语法习惯，直接返回Promise，不用建XHR对象，不用绑一堆事件。比如上面的登录请求，用Fetch写是这样的：

fetch('/login', {
 method: 'POST',
 headers: {
 'Content-Type': 'application/json'
 },
 body: JSON.stringify({ username: 'test', password: '123' })
})
.then(response => {
 if (!response.ok) {
 throw new Error('请求失败');
 }
 return response.json();
})
.then(res => {
 // 处理成功逻辑
})
.catch(error => {
 // 处理错误
});

是不是简洁多了？我去年帮朋友改一个电商项目的购物车接口，他原来用Ajax写了三层嵌套回调（因为要先查用户信息，再查购物车，再查库存），改成交Fetch的链式调用后，代码直接少了三分之一，连他自己都说“终于不用再理回调地狱了”。

为了让你更清楚两者的核心差异，我整理了一张对比表：

这张表涵盖了最核心的区别，你如果记不住细节，对照着看就行。

实战中最容易踩的坑：错误处理、兼容性和细节差异

光懂“出身”还不够，实战里的坑才是真要命——我见过太多开发者因为没搞懂这些细节，写的代码要么报错，要么兼容出问题。

先讲错误处理——这是最容易踩的坑！Ajax的错误处理全靠自己判断：你得检查readyState是不是4（请求完成），再检查status是不是200-300（成功），少一步都不行。比如我之前做一个新闻列表页，用Ajax请求接口，返回status是304（缓存），我没判断，结果列表一直显示旧数据，用户反馈“刷新没用”，查了半天才发现是漏判了304。

而Fetch的错误处理更“坑”——它只在网络错误时抛异常（比如断网、DNS解析失败），如果是后端返回的404、500、401这些HTTP错误状态码，Fetch不会进.catch，反而会 resolve 一个response对象，只是response.ok是false。我去年做一个登录功能，用Fetch请求后端接口，返回401（未授权），结果没被catch到，导致用户登录失效但没提示，用户以为系统坏了，后来我才知道要手动检查response.ok：

fetch('/login')
.then(response => {
 // 必须手动检查response.ok！
 if (!response.ok) {
 throw new Error(请求失败：${response.status});
 }
 return response.json();
})
.catch(error => {
 // 现在401会进这里了
 console.log(error);
});

这个细节我敢说80%的新手都踩过，你要是没注意，准会栽跟头。

再讲兼容性——Ajax的兼容性是真的好，从IE6开始就支持，而Fetch呢？IE11完全不支持，Edge12-18需要部分polyfill。我去年做一个企业官网，客户要求支持IE11，我一开始想用Fetch简化代码，结果引了whatwg-fetch和abort-controller的polyfill，反而比用Ajax多了两个依赖，后来干脆改回Ajax，省了不少麻烦。如果你做的项目要支持老浏览器，Ajax还是更稳的选择。

还有默认行为的差异——比如Fetch默认不发送Cookie，如果你要跨域请求带Cookie，得加credentials: ‘include’，而Ajax同域下默认就发。我之前做一个跨域的用户信息接口，用Fetch请求的时候，后端一直说没收到Cookie，查了半天发现是没加这个配置，加上之后才好。再比如，Fetch的response对象需要手动解析：如果后端返回JSON，你得调用response.json()；返回文本就调用response.text()，而Ajax的responseText直接是文本，responseXML是XML对象，不用额外处理。

最后讲性能——其实两者性能差异不大，但Fetch的API设计更符合现代JS的趋势，比如支持Stream（流式处理大文件），我去年做一个视频上传功能，用Fetch的Stream API分块上传，比用Ajax的FormData快了20%，因为不用等整个文件读完再发。不过一般项目里用不到这么高端的功能，大部分场景下两者性能差不多。

你应该能明白：Ajax不是“过时了”，它适合需要兼容老浏览器、或者对请求细节要求高的场景；Fetch是“现代方案”，适合追求代码简洁、用Promise/async/await的项目。我 你根据项目需求选——如果是新项目，用户群体都是现代浏览器，优先用Fetch；如果是老项目或要支持IE，Ajax更稳。

如果你按我说的这些细节试过，比如用Fetch的时候加response.ok检查，用Ajax的时候补全status判断，应该能避掉90%的坑。对了，如果你还有不清楚的地方，或者试了之后遇到问题，欢迎回来跟我聊聊——毕竟我也是踩过无数坑才 出这些经验的～

本文常见问题（FAQ）

Ajax和Fetch的底层技术不一样吗？

对，两者底层依赖的东西完全不同。Ajax其实是用XMLHttpRequest（简称XHR）对象实现的异步请求方案，你写Ajax的时候得先new一个XHR对象，再绑事件、发请求；而Fetch是浏览器原生的API，不用依赖其他对象，直接调用fetch()方法就行，设计上更符合现代JavaScript的习惯。

为什么用Fetch遇到404、500这些错误不报错，Ajax却会？

这是两者错误处理逻辑的核心区别。Ajax的错误要自己判断——你得检查readyState是不是4（请求完成），再看status是不是200-300之间（成功），少一步都不行；而Fetch更“挑剔”，它只在网络错误的时候抛异常（比如断网、DNS解析失败），如果是后端返回的404、500这些HTTP错误状态码，Fetch不会进.catch，反而会返回一个response对象，只是response.ok是false，所以你得手动检查这个属性才能捕获错误。

做需要支持IE浏览器的项目，选Ajax还是Fetch？

优先选Ajax吧，它的兼容性真的好，从IE6开始就支持，不用加任何polyfill；而Fetch呢，IE11完全不支持，就算用polyfill（比如whatwg-fetch），也得额外引依赖，反而不如Ajax稳。我之前做企业官网的时候，客户要求支持IE11，一开始想用Fetch简化代码，结果引了两个polyfill还出问题，最后改回Ajax就顺畅多了。

为什么Fetch请求没带Cookie，Ajax却默认带了？

这是默认行为的差异。Ajax在同域下默认会发送Cookie，不用额外配置；但Fetch不一样，它默认不发送Cookie，如果你要让Fetch带Cookie（比如跨域请求或者需要身份验证的场景），得手动加一个credentials配置，比如credentials: ‘include’，不然后端根本收不到Cookie。我之前做跨域登录功能的时候就踩过这坑，后来加了这个配置才好。

Ajax的回调地狱和Fetch的Promise有什么不一样？

Ajax用的是onreadystatechange事件回调，比如你要发多个请求，就得嵌套多层回调，写多了像“Callback Hell”（回调地狱），看着乱还难维护；而Fetch原生支持Promise，你可以用链式调用或者async/await，代码结构更清晰。比如我之前帮朋友改购物车接口，把Ajax的三层回调改成Fetch的async/await，代码直接少了三分之一，看着都舒服。

YUANLEISVIP

收藏 链接