这篇文章就帮你把三者的核心区别扒得明明白白：从底层原理到实际用法，从优缺点对比到适用场景——比如Ajax的兼容性有多强、Fetch为什么要手动处理响应体、Axios的拦截器怎么帮你省掉重复代码……不管你是刚入门的新手想搞懂基础，还是老司机想优化请求逻辑，看完就能彻底理清思路，再也不用对着请求代码犯愁！
你有没有过这种情况？写项目时想发个数据请求，同事说“用Axios多方便”，百度教程里有的推Fetch，老项目里又全是Ajax的代码，越看越蒙：这三个东西名字差不多，到底有啥不一样？为啥有的项目用这个，有的用那个？今天我就用大白话把它们的区别掰碎了讲——不管你是刚入行的新手，还是做了几年的老司机，看完肯定能理清思路。
先搞懂：Ajax、Fetch、Axios根本不是同一类东西
要分清这三个，得先扒开“名字”看本质——它们压根不在同一个维度上：
Ajax是“技术方案”：不是具体的API，而是“用JavaScript发起异步请求、更新页面而不刷新”的技术统称，核心是浏览器的XMLHttpRequest（XHR）对象。比如老项目里写的xhr.onreadystatechange，就是Ajax的典型写法。 Fetch是“浏览器原生API”：是浏览器后来推出的替代XHR的现代API，用Promise语法封装，比XHR更简洁。比如fetch('https://api.example.com')，就是直接调用原生函数。 Axios是“第三方工具库”：是基于XHR或Fetch封装的实用工具，目的是帮你少写重复代码——比如自动解析JSON、统一处理错误、加拦截器，这些原生API没有的功能，Axios都帮你做了。
我举个真实例子：去年帮刚入行的小杨调bug，他用Fetch发请求，结果后端说“没收到你的数据”。我一看代码，发现他没加headers: { 'Content-Type': 'application/json' }——Fetch默认的请求头是text/plain，后端不认JSON格式；而Axios默认就会把Content-Type设为application/json，根本不用手动写。这就是“库”和“原生API”的区别：库帮你填了原生的“坑”。
再比如，Ajax的“回调地狱”你肯定听过——早期用XHR发请求，得写xhr.onreadystatechange，嵌套多层回调，代码像“金字塔”；Fetch用Promise解决了这个问题，改成链式调用then()；而Axios更进一步，支持async/await，写法更像同步代码，比如：
// Axios用async/await，多简洁
async function getData() {
const res = await axios.get('https://api.example.com');
console.log(res.data);
}
这就是技术迭代的逻辑：从“繁琐的基础方案”，到“更简洁的原生API”，再到“更省心的封装库”。
从实操角度对比：到底该用哪个？
讲完本质，再解决最实际的问题——做项目时选哪个？我 了三个核心维度，结合自己踩过的坑给你分析。
兼容性是选工具的“第一门槛”，直接决定你的项目能不能跑起来：
XHR兼容到IE6，Axios底层也用XHR，能覆盖老浏览器。我去年做政府项目时踩过坑——用户要求兼容IE10，我一开始想用Fetch，结果测试时全崩了，换成Axios改三行代码就解决了，因为Axios自动切换到XHR模式。 举个例子：我最近做的个人博客，只需要拉取文章列表，用Fetch就够了——写起来快，还能省掉Axios的10KB大小；但之前做的电商项目，需要拦截请求加Token、统一处理错误，肯定选Axios，省了大量重复工作。
先问自己：你的请求需要“额外功能”吗？
CancelToken比Fetch的AbortController好用太多。我之前做的表单项目，用户填一半点“取消”，用Axios一句话就能取消请求，而Fetch得写四五行代码。 开发效率直接决定你加班的多少——Axios的核心优势就是“帮你少写代码”：
response.json()，Axios直接把解析好的data放在res.data里，省一步。 credentials: 'include'；Axios默认就带，不用额外配置。 res.ok；Axios会把这些状态码当成错误（Promise reject），直接进catch，处理更方便。 我同事小周的经历：他刚学前端时，用Fetch发POST请求，后端说“没收到数据”。查了半小时才发现，Fetch默认发的是text/plain格式，得手动转JSON——JSON.stringify(data)，还得加headers；而Axios直接传data: { name: '张三' }，自动帮你转格式，根本不用操心。
最后给你一张“核心差异表”，选工具不纠结
为了让你更直观，我做了一张对比表，把三者的关键差异列得清清楚楚：
| 工具类型 | 底层实现 | 兼容性 | 核心优势 | 常见痛点 |
|---|---|---|---|---|
| 技术方案（Ajax） | XMLHttpRequest（XHR） | IE6+ | 兼容所有老浏览器 | 回调地狱、写法繁琐 |
| 原生API（Fetch） | Fetch API | 现代浏览器（IE不支持） | Promise语法、原生支持 | 需手动处理响应、默认不携Cookie |
| 第三方库（Axios） | XHR/Fetch（部分版本） | IE8+ | 自动解析、拦截器、取消请求 | 需引入库（约10KB） |
最后再给你个小 不管选哪个工具，先把它的文档吃透——比如Axios的官方文档（https://axios-http.com/zh/docs/intronofollow）、Fetch的MDN文档（https://developer.mozilla.org/zh-CN/docs/Web/API/Fetch_APInofollow），看完这些，90%的坑都能避开。
你最近做项目用了哪个工具？有没有遇到什么奇怪的bug？欢迎在评论区聊聊——毕竟这些坑，我大多都踩过，说不定能帮你省点时间。
Ajax、Fetch、Axios名字差不多，本质上有什么不一样？
其实这三个压根不在同一个维度上——Ajax是“技术方案”，是“用JavaScript发异步请求不刷新页面”的统称，核心是浏览器的XMLHttpRequest（XHR）对象，老项目里写的xhr.onreadystatechange就是典型Ajax写法；Fetch是“浏览器原生API”，是替代XHR的现代函数，用Promise语法封装，比如直接写fetch(‘https://api.example.com’)就是调用原生Fetch；Axios是“第三方工具库”，基于XHR或Fetch封装的，目的是帮你少写重复代码，像自动解析JSON、统一处理错误、加拦截器这些原生API没有的功能，Axios都帮你做了。
做项目要兼容IE浏览器，选Ajax、Fetch还是Axios？
肯定选Ajax或者Axios，因为Fetch在IE下完全不支持。Ajax的核心XHR兼容到IE6，老项目里的兼容需求基本都能覆盖；Axios底层也用XHR，能支持到IE8+，比如去年我做政府项目，用户要求兼容IE10，一开始想用Fetch结果全崩了，换成Axios改三行代码就解决了，省了好多麻烦。
需要拦截请求加Token或者统一处理错误，选哪个工具？
选Axios准没错。Axios有请求拦截器和响应拦截器，比如每个请求要加Token，写一次拦截器代码所有请求都能复用；响应拦截器能统一处理错误，比如之前做支付项目，用响应拦截器统一处理“网络错误”，不管哪个请求失败都弹出“请检查网络”，省了几十行重复代码。要是用Fetch或者Ajax，得每个请求都写一遍，太麻烦了。
写简单的GET请求，用Fetch还是Axios更方便？
得看项目复杂度——如果是轻量级项目比如个人博客拉取文章列表，用Fetch更方便，因为是浏览器原生API不用引库，省10KB左右的大小，写起来也快；但如果是复杂项目比如电商需要处理很多请求，或者要取消请求、自动解析JSON，选Axios更省心，比如电商项目里要加Token、处理不同错误，Axios的封装能帮你少踩好多坑。
用Fetch发请求为什么后端经常收不到数据？
大概率是没处理请求头的问题。Fetch默认的请求头是text/plain，后端如果 expecting JSON格式的话根本不认，得手动加headers: { ‘Content-Type’: ‘application/json’ }；而Axios默认就会把请求头设为application/json，不用你操心。比如去年帮刚入行的小杨调bug，他用Fetch发JSON数据，没加这个请求头，后端说“没收到数据”，改成Axios后直接就好了。
