javascript如何发起网络请求_Fetch和Axios怎么选择？

狼影 2026-01-07 00:00:00 次阅读

日常开发优先用 Axios，纯前端小项目或需原生控制时再考虑 fetch；Axios 默认处理 cookie、重定向、JSON 解析和错误状态，fetch 需手动配置 credentials、redirect 并检查状态。

直接说结论：日常开发优先用 Axios，纯前端小项目或需要原生控制时再考虑 fetch。两者不是非此即彼，但选错会多踩一堆坑。

为什么 `fetch` 默认不带 cookie 和重定向失败很常见

fetch 的默认行为和浏览器实际请求习惯有明显偏差。比如发起登录请求后，后续接口拿不到 session，大概率是没配 credentials；又或者 302 重定向后状态码变成 200 但响应体为空，是因为 fetch 默认不自动跟随重定向（redirect: 'follow' 才行）。

credentials: 'include' 必须显式设置，否则跨域请求不带 cookie
redirect: 'follow' 要手动加，否则 301/302 不会跳转，且 response.ok 为 false
fetch 对 4xx/5xx 响应不会抛异常，必须手动检查 response.ok 或 response.status

`Axios` 自动处理了哪些 `fetch` 里要手写的逻辑

Axios 把服务端开发中高频的“隐性约定”封装成了默认行为，省掉大量样板代码。

默认发送 credentials: 'include'（可配置关闭）
自动解析 JSON：响应头含 application/json 时，response.data 直接是 JS 对象
HTTP 错误状态（4xx/5xx）默认触发 catch，不用手动判断 status
支持请求/响应拦截器，比如统一加 token、错误 toast、loading 状态管理

axios.get('/api/user')
  .then(res => console.log(res.data.name)) // 不用手动 .json()
  .catch(err => {
    if (err.response?.status === 401) {
      location.href = '/login';
    }
  });

什么情况下该坚持用 `fetch`

不是 Axios 不好，而是某些场景它反而成了累赘：

需要流式读取大文件（ReadableStream + response.body.getReader()），Axios 不支持
要精细控制 abort 信号（比如 AbortController 与 React 组件生命周期绑定），fetch 原生更轻量
构建超轻量脚本（如 Greasemonkey 用户脚本），不想引入额外包
调试网络栈时需观察原始请求头/响应头，fetch 更接近底层行为

`Axios` 的兼容性和体积问题不能忽视

如果你的项目还要支持 IE11，Axios 需要搭配 Promise 和 Object.assign 的 polyfill；而 fetch 在 IE 完全不可用，必须用 whatwg-fetch。另外，Axios 包体积约 14KB（gzip 后），对首屏性能敏感的页面值得权衡。