是时候该换掉你的 axios 了

[ScottHU]

axios 是一个基于 Promise 的 HTTP 客户端，每周的 npm 下载量 4000W+，如果回到在 10 年前，promise 式的请求工具是一个很大的创新，它解决了请求繁琐的问题，在那个性能要求不那么高的年代可谓是一骑绝尘。但随着时间的推移，Axios 在开发效率和性能方面开始有所落后，现在都已经是 2023 年了，面对日益复杂的需求，我们需要的是一款更具创新性和领先性的请求工具，而 promise 式的请求工具只能被称为传统了，如果你想保持在快速发展的前沿，那么请继续阅读。

首先我想声明的是，我确实不是标题党，接下来我将通过暴露随着时间的推移，axios 在一些方面表现的力不从心，并推荐一个新的，相比 axios 更具现代化和创新性的请求工具给你，它就是 轻量级的请求策略库 alova

接下来我们看看 Promise 式请求工具的弱点（ axios ）

1. 与 React 、Vue 等框架割裂

现在，React 、Vue 等前端 UI 框架对于前端来说几乎是不可缺少的，axios 无法和这些框架的状态深度绑定，需要开发者自行维护它们，导致开发效率较低。

2. 在性能方面毫无作为

2023 年了，相比 10 年前的应用已经复杂了不知几个数量级，在请求方面要求也越来越高，来保证页面性能的要求，axios 在这方面毫无作为，例如在频繁地重复请求、同时发起多个相同请求等场景。

3. 臃肿的体积

根据 bundlephobia 显示，axios 的体积在压缩状态下有 11+kb ，不信的话，你可以点此去查看

4. 响应数据的 Ts 类型定义混乱

在使用 axios 时，你可能经常会这样写：

// 创建一个 axios 实例
const inst = axios.create({
  baseURL: 'https://example.com/'
})

// 在响应拦截器中返回 data
inst.interceptors.response.use(response => {
  if (response.status === 200) {
    return response.data
  }
  throw new Error(response.status)
})

interface Resp {
  id: number
}
inst.get<Resp>('/xxx').then(result => {
  // result 的类型总是为 axios.AxiosResponse<Resp>
  data.data
})

不知道是 axios 故意为之还是忽略了，以上的发起的 GET 请求中，响应数据result的类型总是axios.AxiosResponse<Resp>的，但其实我们在响应拦截器中已经将response.data返回了，这导致响应数据类型混乱而被困扰。

在 alova 中是如何解决的呢？

alova 作为一个更加现代化，更加适应复杂应用的请求方案，也给出了它更加优雅的解决方案。同时为了降低给的学习成本，也保持了和 axios 相似的 api 设计，看起来就很熟悉有木有。

alova 读作“阿洛娃”，虽然和 axios 一样都是以 a 开头，以下两个名称需要注意区分哦！

与 UI 框架深度融合，自动管理请求相关数据

假设我们需要发起一个基本的数据获取请求，以 vue 为例，直接上对比代码。

axios

<template>
  <div v-if="loading">Loading...</div>
  <div v-else-if="error" class="error">
    {{ error.message }}
  </div>
  <div v-else>{{ data }}</div>
</template>

<script setup>
import axios from 'axios';
import { ref, onMounted } from 'vue';

const loading = ref(false);
const error = ref(null);
const data = ref(null);

const requestData = () => {
  loading.value = true;
  axios.get('http://xxx/index').then(result => {
    data.value = result;
  }).catch(e => {
    error.value = e;
  }).finally(() => {
    loading.value = false;
  });
}
onMounted(requestData);
</script>

alova

<template>
  <div v-if="loading">Loading...</div>
  <div v-else-if="error" class="error">
    {{ error.message }}
  </div>
  <div v-else>{{ data }}</div>
</template>

<script setup>
import { createAlova } from 'alova';

const pageData = createAlova({ baseURL: 'http://xxx' }).Get('/index');
const { loading, data, error } = useRequest(pageData);
</script>

在 axios 中需要自己创建对应的请求状态并自行维护，而 alova 却帮你接管了这项工作

开箱即用的高性能功能

传统 Promise 式的请求工具主要定位于通过 Promise 的方式简化请求，而提高性能可能是它们最不会考虑的一点，但作为请求策略库的 alova 中却着重突出这一点，在 alova 中默认开启了内存缓存和请求共享，这两项可以极大地提高请求性能，提升用户体验的同时还能降低服务端压力，让我们来一一了解下它们吧。

内存缓存

内存模式就是在请求响应后将响应数据保存在本地内存中，当下次再发起相同请求时就会使用缓存数据，而不会再次发送请求，试想一下，当你在实现一个列表页，点击列表项可以进入详情页查看数据，你会想到用户可能会频繁在列表中点击查看详情，当详情数据没有变化时，如果每一次进入详情页都要请求一次未免也太浪费了，而且每次还需要用户等待加载。在 alova 中你可以默认享受到这样的待遇，以下展示下效果

请求共享

你可能遇到过这种情况，当一个请求发出但还未响应时，又发起了相同请求，就造成了请求浪费，或者重复提交问题，例如以下三种场景：

1. 一个组件在创建时会获取初始化数据，当一个页面同时渲染多个此组件时，将会同时发出多次相同请求；
2. 提交按钮未被禁用，用户点击了多次提交按钮；
3. 当预加载还未完成时进入了预加载页面，将会发起多次相同请求；

共享请求就是用来解决这些问题的，它是通过复用请求的方式来实现的，由于这种案例无法直观展示，就不展示了，有兴趣的小伙伴可以自行体验体验。

除此以外，自称是请求策略库的 alova 还提供了特定场景下的请求策略，我们将在下文中介绍，有兴趣的小伙伴请继续往下看。

轻量级的体积

压缩状态下的 alova 只有 4kb+，只有 axios 的 30%+，不信的话，你可以点此去查看

更加直观的响应数据 TS 类型

在 axios 中，你想要定义响应数据的类型真是会让人感到困惑，如果你是个 Typescript 的重度用户，alova 可以给你提供完整的类型体验，当你在请求处定义响应数据时的类型后，你可以在多处享受到它，会让你感觉很清晰，我们来看看。

interface Resp {
  id: number
}
const pageData = createAlova({ baseURL: 'http://xxx' }).Get<Resp>('/index');
const {
  data,  // data 的类型为 Resp
  loading, error, onSuccess, send
} = useRequest(pageData);
onSuccess(event => {
  // 在成功回调中获取响应数据时，event.data 的值类型也是 Resp
  console.log(event.data);
});

const handleClick = async () => {
  // send 函数可以手动再次发送请求，它将可以接收到响应数据，它的值类型还是 Resp
  const data = await send();
}

至此，相比传统的 Promise 式请求库，你可能已经初步了解了 alova 的厉害。

但... 它的特性还远不止于此！

alova 的其他特性

多 UI 框架同时支持

alova 同时支持 react 、vue 、svelte ，无论你使用哪种 UI 框架，它都能满足你。

与 axios 相似的 api 设计，用起来更简单熟悉

alova 的请求信息构造几乎和 axios 相同，我们来对比一下它们的 GET 和 POST 请求。

GET 请求

// axios
axios.get('/index', {
  // 设置请求头
  headers: {
    'Content-Type': 'application/json;charset=UTF-8'
  },
  // params 参数
  params: {
    userId: 1
  }
});

// alova
const todoListGetter = alovaInstance.Get('/index', {
  // 设置请求头
  headers: {
    'Content-Type': 'application/json;charset=UTF-8'
  },
  // params 参数
  params: {
    userId: 1
  }
});

POST 请求

// axios
axios.post('/login', {
  username: 'xxx',
  password: 'ppp'
}, {
  // 设置请求头
  headers: {
    'Content-Type': 'application/json;charset=UTF-8'
  },
  // params 参数
  params: {
    userId: 1
  }
});

// alova
const loginPoster = alovaInstance.Post('/login', {
  username: 'xxx',
  password: 'ppp'
}, {
  // 设置请求头
  headers: {
    'Content-Type': 'application/json;charset=UTF-8'
  },
  // params 参数
  params: {
    userId: 1
  }
});

（请求策略）高性能分页请求策略

自动维护分页相关数据和状态，并提供了常用的分页数据操作能力，据官方介绍，可以让列表页流畅性提高 300%，编码难度降低 50%，以下是官方提供的示例，有兴趣的同学可以去看看。

分页列表示例

下拉加载示例

（请求策略）无感数据交互

这个在我看来，这个无感数据交互请求策略可谓是一大创举，我把它理解为更加可靠的乐观更新，官网是这样解释的：

无感数据交互是指用户在与应用进行交互时，无需等待即可立即展示相关内容，或者提交信息时也无需等待即可展示操作结果，就像和本地数据交互一样，从而大幅提升应用的流畅性，它让用户感知不到数据传输带来的卡顿。可以更高限度地降低网络波动带来的问题，你的应用在高延迟网络甚至是断网状态下依然可用。

在我的体验过程中，即使在弱网状态下，也可以让我感受到一种毫无延迟带来的顺畅感，你也来感受下吧。

据我了解，它使用以下技术：

1. 持久化的请求队列来保证请求的安全性和串联性；
2. 请求重试策略机制，来保证请求的顺利完成；
3. 虚拟响应数据（一个创新的概念），来作为未响应时的数据占位，以便在响应后定位它并替换为实际数据。

关于无感数据交互更具体的可以在官网了解哦

数据预拉取

通过拉取数据的方式预先加载好数据并缓存在本地，当真正用到这部分数据时就可以命中缓存并直接显示数据，这种方式也极大地提升了用户体验。

写在最后

总之，alova 作为一个新生代的请求工具，具有很大的潜力，你也想试用的话，可以点击以下链接去了解。

alova 官网

alova 的 Github 地址

写作不易，看都看到这了，不如帮我点个免费的爱心吧！！！感谢你的喜欢

[vitovan]

请问为什么不直接用 fetch 呢？

[TabGre]

先把名字优化一下，跟吐槽的如此之像

[IvanLi127]

我怎么感觉这文章好水。。。ai 参与的？

[Zyhusesit]

next.js 13 API route 也不错

[HaroldFinchNYC]

axios 最好的一点真的是前后端都可以用

node-fetch 都不如 axios 好使

[xubeiyan]

@vitovan axios 可以拦截 request 加上 token 之类的，也可以拦截 response 预先处理统一错误，和调整返回的内容，最主要是支持 fetch 鸽了很多年的 request progress （例如实时显示上传进度）

[xubeiyan]

不管是 axios 还是你这个，怎么设计都没有避开请求之后 ui 渲染的问题，要说完美契合了现代前端框架的 query 库是 tanstack 的 react-query ，在这个设计思路上走才是正确的

[fpure]

真佩服你们，一个简单的 Ajax 也能整这么多活

[belin520]

这，如果说 axios 有那些缺点，为什么不自己封装 fetch 呢

[mdn]

fetch 和 xhr 一样都是简单的请求方法，想要方便使用，还需要进一步封装

ky 是基于 fetch 的封装，功能和 axios 类似，可以试试

[foolishcrab]

这个只是大而全而已，文章里列举的 axios 的痛点本来就不是 axios 想要解决的问题。

标题这样去拉踩一个光受欢迎的库但是理由站不住脚我觉得比较反感

其次我个人觉得中文 js 项目做大而全收益不高

[vitovan]

@xubeiyan #6 谢谢，明白了。

[walpurgis]

虽然东西是好东西，但是你拿它跟 axios 比，不能说是上级替代，可以说是毫不相干

这是你自己官网写的
https://alova.js.org/zh-CN/get-started/overview/#%E6%9B%BF%E4%BB%A3%E8%AF%B7%E6%B1%82%E5%BA%93

你做的东西更多的是应用层的请求优化，目前类似功能的轮子非常多，但其实很多简单场景用 VueUse 就搞定了，你这个工具的代码侵入性不小，就意味着存在学习成本，除非框架官方背书，比如 nextjs 的 swr

[yaodong0126]

已阅，不换

[NessajCN]

「内存缓存

内存模式就是在请求响应后将响应数据保存在本地内存中，当下次再发起相同请求时就会使用缓存数据，而不会再次发送请求，试想一下，当你在实现一个列表页，点击列表项可以进入详情页查看数据，你会想到用户可能会频繁在列表中点击查看详情，>>当详情数据没有变化时<<，如果每一次进入详情页都要请求一次未免也太浪费了，而且每次还需要用户等待加载。在 alova 中你可以默认享受到这样的待遇，以下展示下效果」

请问它咋知道「详情数据没有变化」的？

[fd9xr]

。。。我还以为又来了个新的 axios 搞了半天还是个半程替代品 你的优势也不是他的缺点啊 还以为是时候把 axios 丢了换 native fetch 结果。

[dudubaba]

deno 当初还说替换 node ，现在还有热度吗？

[zbinlin]

看到标题还以为是换成标准的 fetch ，点进来看，原来是换成另一个 axios 。

[wusheng0]

你是库作者？作者都说你这标题过了。是故意招黑还是干啥？

[bhbhxy]

早就集成到脚手架里了，换一套框架又要重新撸一遍代码？真没那功夫

[wusheng0]

@wusheng0
>
https://juejin.cn/post/7213923957824979000

JOU_alova2
没想到我写的库居然冲上了热榜，但我好像来迟了点，非常感谢古韵对我的支持，他也是我去年邀请的第一批体验用户之一。
评论我都自习看了下，在这里为大家稍微解答下，首先，文章标题确实有点过了，alova 和 axios 是一种互相协作的关系而没有替代一说，在 RSM 模型中，请求发送照样需要使用 axiosfetch 等，而且如果 alova+axios 的话，还是可以享受到 axios 的全部功能的，这点可以在 axios 适配器文档中看到。

然后第二个大家关心的问题是和 reactquery 和 swr 区别不大，在这里我想说的是，它们所解决的问题是一样的。但解决方案不一样，alova 和 reactquery/swr 最大区别是，alova 中抽象出了 Method 的概念，Method 表示以怎样的方式外理请求，以如请求相关参数，请求超时时间，是否使用缓存还是发出请求，是否使用上传下载进度等等，都是和请求相关的信息，然后达到优化了请求信息的管理方式的效果，也达到了在不同请求环培下统一的请求方式，你可以不关心到底是 axiosfetch 还是 taro.reauest 在发送请求，上层使用都一样，还有一个好外是 Method 实例是贯穿请求和响应的，对干管理缓存也好，响应的状态也好，你都不需要自己去设詈 kev ，因为 Method 就是最好的 kev ，useReauestuseWatcheruseFetcher 代表请求时机，即表示在何时发出请求不知道有没有解答大家的疑问，在这里也感谢大家对 alova 展开的热议 @稀土掘金技术社区

[agdhole]

重新发明 swr ？

[siweipancc]

害怕，你们就是这么迭代“工具”的？把前人变得一文不值

[veike]

一直用的 fetch ，自己封装了一下，好多项目都用的自己写的 fetch.js

[huangqihong]

在掘金看过这篇文章，标题也是这个，我就想不通，在掘金多说了标题过了，为什么还会在 v2 也用这个标题呢
老老实实推荐个工具不行吗？
是时候该换掉你的 标题 了

[diagnostics]

前端圈真会“玩”

[adminisqq]

前端娱乐圈

[gps949]

看到标题进来前还以为要说 fetch 呢……

[likunyan]

重新发明 swr ？

[wtf12138]

很早之前在掘金上看过了，标题都不带改的
不愧是前端娱乐圈

[Mark85]

https://www.attojs.com/api/#data

https://ahooks.js.org/hooks/use-request/index

除了体积外，你说的其他缺点不就引个 hooks 就解决的事么？

[weijancc]

跟 starrocks 一样, 宣传自己的东西就先踩一下别人, 只能说真下头, 狗都不用.

[supertan]

@NessajCN #15 这是一个业务关联的，如果你的数据不是一直在变化（或者实时要求不是立即更新），比如历史表、班级成员之类的，那么相同上送项查回来的数据就是一样的，这种完全就可以缓存（ 10 秒、60 秒）减少服务端压力+优化体验。 这有啥好杠的？

[v135ex]

这个对比感觉就像是公司里，用了很多资源造了一个东西，然后领导非得问你“到底进步了多少？”。然后你经过仔细研究数据对比，认为 11kb 的 axios 太臃肿了，我的提升了 50%达到了竟然的 4kb

[GzhiYi]

Weekly Downloads: 747
Github stars: 1.2k

[ShundL]

你们前端又出新玩意儿啦？

[Uyloal]

我一般 fetch 一把梭😆

[GzhiYi]

@NessajCN 我也觉得这个功能比较扯，尽管可能该库有对错误或者数据差异做一些异常抛出（我没细心看），但这样可能存在致命问题（缓存数据与数据库数据不一致引起后续判断 /操作错误）的功能也会出现，谁敢用在生产环境。所以我觉得为了安全起见，至少移除这样的功能。

[summerLast]

可以看看 vue use

https://vueuse.org/integrations/useAxios/

[myon]

掘金没被骂够换个地方继续找骂是吧

[tkHello]

嗯 好 结贴，下一个

[lateautumn02]

我记得这篇文章我在一个月以前就在掘金看过了，只不过没有这么全

[iugo]

> deno 当初还说替换 node ，现在还有热度吗？

@dudubaba 如果你这是一个问句, 那回答是: 有.

https://github.com/denoland/deno/graphs/contributors

https://star-history.com/#denoland/deno&nodejs/node&Date

[fan88]

@fpure 就是，搞什么鸡巴前端工程化，老子 JQ 一把梭干废

[twinsdestiny]

直接 fetch

[rozbo]

很好，我选择 ofetch

[linvaux]

已阅，我是后端，雨我无瓜

[yhxx]

掘金被喷完过了几个月又来这里找存在感？

[usedTo404]

看了下跟 RTK query 一样的东西，不懂为什么老喜欢重复造轮子

[godoway]

很好，但是我的渣渣 ng 有自带的 httpclient

[94qihang]

我就说这个看着好眼熟，好像在掘金看过，没想到还真是= = 我选择 axios

[RIckV2]

掘金见过，被喷的一塌糊涂，作者真执着，又来这里了。

[ljsh093]

@supertan #33 「默认开启」

[zmaplex]

人生苦短 我用 requests 啊不对是 fetch

[kylebing]

好像在哪见过

[zzzzzzZ]

加深了我对这些🤡前端的刻板印象

[weaponc]

你们别用 axios 了！用我写的 bxios ！

[chnwillliu]

还是 ng 的 http client 好用。

[zhaol]

你这个所谓的内存缓存如果默认开启的话，绝对会被测试提 bug ，而且需要的话，我完全可以自己做。还有这个无感数据交互，先响应 UI ，但是万一接口 curd 失败，你这个时候需要恢复数据吗？那你页面的数据反复横跳，用户能接受吗？和框架整合这个也是个伪需求，开发也可以基于 axios 封装的，不论是 react 还是 vue ，

[liberty1900]

最近才把项目里的 Axios 升级到最新版本捏

[pengtikui]

换掉 axios 我同意，换成 alova 我不同意

[leega0]

叉出去，下一个

[lemon6]

你说的是不是 react-query?swr ？

[deplivesb]

前端真有意思，都 3202 年了还在搞基建

[AubreyWang]

....叉出去，下一个

[shadeofgod]

如果你只需要一个非常轻量的，功能又比 native fetch 多一点点的，可以试试 https://github.com/elbywan/wretch 或者 https://github.com/developit/redaxios ，

如果你需要 hook ，用 react-query 或者 swr 之类的就好了

[linl1n]

真有意思 今天换掉 axios 然后推个 bxios ，明天换掉 Next.js 推个 Prev.js 是吧

[toesbieya]

最讨厌这种什么都要和 UI 框架结合的，和 nuxt 一样一坨狗屎

[xuelu520]

一个请求 http 的库，真的需要这么多轮子吗？

[jenhe]

推广就发到推广，别散播焦虑，忽略使用场景，为了用而用

[liut2016]

圈外人有几点疑问：

1. http 协议本身就有缓存机制，为什么不用它非要再造个缓存？
2. 请求共享功能，这个有点危险吧，如果真的有业务就需要同时 post 两条一样的数据？

[wangxiaoaer]

@NessajCN #13 每次请求最新数据没毛病啊，所谓的内存缓存反而导致了要用户主动刷新才能获取最新数据，真是脱裤子放屁。 感觉有些人魔怔了，请求一次服务器好像就会搞垮服务器，就会影响性能，11K 的包大小竟然被称作臃肿，哎。

请求共享，求求你们不要造词了。

[dengshen]

又来推广了 🐶 axios 大家都在用 想吃下这个市场除非能够无痛替换。否则我用的好好的为啥要换？

[LancerComet]

Composition API 很容易封装，如果追求简约直接使用 Fetch + 函数简单包一下就实现了完全一样的效果

[yunye]

给我多少钱 多的话马上换

[keymao]

天天不是做轮子就是脚手架，让老板发现了该给你加工作量了。

[liuguang]

axios 与 vue 一起用很简单，并不复杂。
压缩后 4K 和 10K+有区别吗？体积绝对不是 axios 的劣势。真说起体积，如果我用原生 js ，岂不是比你这个更省体积，而且没有封装，性能也更好。
请求重试，这是很简单的逻辑，一个异步库就没必要把这些也加进去了。
数据预拉取？这也不是异步库应该包含的东西。
你喜欢用什么都行，但是别踩一个捧一个，axios 绝对没有那么失败。

[lianxiben]

就挺。。多此一举的。。

[bjfane]

很早之前就发过一篇了吧，或者在别的地方看到的。

[molvqingtai]

哈哈，人手一个 https://github.com/molvqingtai/resreq

[ruoxie]

axios 无法和这些框架的状态深度绑定，需要开发者自行维护它们，导致开发效率较低。真敢说啊，一个请求库还要跟框架深度绑定，如果用 websocket ，再来个深度绑定，然后一坨屎山的雏形就有了。闲的慌的话多看看软件架构的书吧

[9ki]

掘金看过的烂文，记得当时评论下就有很多人喷，没想到敢来技术氛围更浓郁的 V2EX 来推广，一时间竟有些佩服作者的勇气

[kkbblzq]

虽然我是个后端，但是看完我的感觉就是：忽悠领导可以，别过来忽悠网友了；大多所谓的特性优化点都不是无痛的，只适应于部分场景，去除这些鸡肋特性，基本没有什么足够到别人去替换组件的亮点。。😂

[muzuiget]

用 fetch 就完了，连 NodeJS 都支持很久了。再说一个 HTTP 客户端还要拉上 UI 的东西，多余了。

[baobao1270]

Why not fetch() API?

[zhengjian]

楼主的「内存缓存」这个功能可以参考 SWR 是怎么做的：

「“SWR” 这个名字来自于 stale-while-revalidate：一种由 HTTP RFC 5861(opens in a new tab) 推广的 HTTP 缓存失效策略。这种策略首先从缓存中返回数据（过期的），同时发送 fetch 请求（重新验证），最后得到最新数据。」

[ysw]

乍一看还以为又有哪个 linux 系统出来了

[cwWqjBJJRPak]

啊 low 哇！你这名字太那啥了吧？？？

[NessajCN]

@zhengjian
>「当详情数据没有变化时，如果每一次进入详情页都要请求一次未免也太浪费了」

[Anivial]

所谓的“无感数据交互”真的不会在出现问题时给用户带来困扰吗？本来是所见即所得，加上了无感数据交互，那么数据是不是可能就是虚幻的？实际的操作并未生效我就关了浏览器那怎么办？

[Geo200]

跟框架集成的东西不敢用，框架是注定是被时代潮流淘汰的玩意

[Marven]

推广就发到推广，别散播焦虑，忽略使用场景，为了用而用

[fakeshadow]

安定的 backfire

[zed1018]

说的好，我选 window.fetch

[wuzhanggui]

请求就是请求，还是喜欢没和一些其他库加上关联的，互不相干

[wuzhanggui]

@wuzhanggui 开发效率高是好但是我更喜欢人人都能看随时都能改的，所以我重复代码不少，没有必要的我是不封装的，别人一拿到代码随时都能改还不会出错多好

[jalena]

标题没有 axios 我或许都不会点进来。。

[supertan]

@ljsh093 #53 好吧，框架缺省是默认开启有点脱离实际应用了，隐患很大，容易在不知不觉间造成生产事故。缓存能力应该是针对单一请求的自定义配置，用作特定高频交易场景的性能优化选项。

[mrzou007]

sb ，题主非要到处招黑？闲的发慌？换 nm

[Joeith]

笑死了，前端果然是娱乐圈。。。