日常开发优先用 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 不好，而是某些场景它反而成了累赘：
立即学习“Java免费学习笔记（深入）”；
- 需要流式读取大文件（
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 后），对首屏性能敏感的页面值得权衡。
- 现代项目（ES2017+、Chrome/Firefox/Safari 主流版本）：选
Axios省心 - 微前端子应用或嵌入式设备环境：优先测
fetch兼容性再决定 - 用 Vite / Webpack 构建时，
Axios可通过sideEffects: false摇树优化，但实际能砍掉的不多
真正容易被忽略的是错误边界——Axios 的拦截器里如果 throw 新错误，可能吞掉原始响应细节；而 fetch 虽然啰嗦，但每一步都暴露在你眼皮底下。
