fetch 轻量原生但需手动补全功能,axios功能完整开箱即用;小项目优先 fetch,中大型项目推荐 axios;高阶需求应结合react Query 等数据层库。

javaScript 与 后端 API 交互,核心是发起 http 请求并处理响应。目前最常用的是 fetch(原生)和 axios(第三方库),二者没有绝对的“更好”,关键看项目需求和团队习惯。
fetch 更轻量、更现代,但需要手动补全功能
fetch 是 浏览器 原生支持的 API,无需安装依赖,语法简洁,基于 promise,天然支持 async/await。但它默认不带 cookie、不自动处理 jsON 错误状态(比如 404、500 仍算“成功”)、不支持请求 / 响应拦截、取消请求需靠 AbortController。
常见补足方式:
- 手动添加
credentials: 'include'才能携带 Cookie - 检查
response.ok或response.status判断业务是否失败 - 用
response.json()显式解析 JSON,且需用try/catch捕获解析错误 - 超时控制需自己 封装 Promise.race 或用 AbortController
axios 功能更完整,开箱即用,适合中大型项目
axios 是一个成熟的 HTTP 客户端,内置了大量实用特性:自动转换 JSON、默认携带 Cookie(可配)、响应拦截器、请求拦截器、内置超时、取消请求(CancelToken 或 AbortController)、更友好的错误 对象(Error.response、error.request 等)。
立即学习“Java 免费学习笔记(深入)”;
典型优势场景:
- 需要统一添加 token 到请求头 → 用请求拦截器
- 所有 接口 返回结构统一(如
{code: 0, data: ……, msg: ''})→ 用响应拦截器做预处理 - 上传文件要监听进度 → axios 支持
onUploadProgress - 多个请求需批量取消(如搜索 联想 中途切换关键词)→ 轻松调用
cancel()
小项目或学习阶段,优先用 fetch;业务复杂或团队协作,axios 更省心
如果只是写个静态页面调用公开 API,或者想减少依赖、练手原生能力,fetch 完全够用,也更利于理解底层机制。但一旦涉及登录态管理、错误统一处理、多环境配置、接口监控等,axios 的工程化能力会明显提升开发效率和可维护性。
注意:两者不互斥,可以共存。比如主业务用 axios,某些特殊请求(如流式响应、WebDAV)用 fetch 更灵活。
替代方案也在演进:React Query / SWR 更关注数据层抽象
单纯比 fetch 和 axios,容易忽略更高层的需求——比如缓存、轮询、乐观更新、离线同步。现在主流趋势是配合数据获取库(如 React Query、SWR、vue Query)使用,它们底层可自由切换 fetch 或 axios,重点解决“如何管理服务端状态”,而非“怎么发请求”。
所以选型逻辑可以是:
→ 先确定是否需要数据缓存和同步能力?需要就上 React Query/SWR;
→ 再看它底层用什么发请求?默认 fetch 就够,需要拦截 / 适配旧逻辑再换 axios。