原生 fetch 轻量但需手动补全超时、重试、错误处理等能力；axios 开箱即用，内置拦截器、自动错误处理、超时控制和请求取消，适合中大型项目。
原生 fetch 足够用，但默认不带请求超时、自动重试、取消重复请求这些能力；axios 开箱即用，适合中大型项目——选哪个不取决于“好不好”，而取决于你愿不愿意自己补足缺失功能。
fetch 默认不处理 4xx/5xx 状态码，必须手动检查 response.ok
fetch 只在真正网络失败（如断网、DNS 解析失败）时 reject，HTTP 状态码为 404、500 甚至 401 都会进入 then 分支。这是最常踩的坑。
正确写法是：
fetch('/api/user')
.then(response => {
if (!response.ok) {
throw new Error(`HTTP error! status = ${response.status}`);
}
return response.json();
})
.catch(err => console.error(err));
而 axios 默认把 4xx/5xx 当作错误，直接进 catch，省去这层判断。
立即学习“Java免费学习笔记（深入）”；
fetch 没有内置超时控制，得靠 AbortController + Promise.race
原生 fetch 不支持 timeout 选项。要实现 8 秒超时，必须手动组合：
const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), 8000);
fetch('/api/data', { signal: controller.signal })
.then(res => res.json())
.catch(err => {
if (err.name === 'AbortError') {
console.error('请求超时');
}
})
.finally(() => clearTimeout(timeoutId));
axios 直接支持：axios.get('/api/data', { timeout: 8000 })，简洁且语义明确。
注意：AbortController 在旧版 Safari 和 IE 中不可用，需 polyfill。
axios 的默认配置和拦截器对业务逻辑更友好
比如统一加 token、自动序列化请求体、统一错误日志、响应数据预处理等，axios 用 interceptors 写起来很自然：
axios.interceptors.request.use(config => {
config.headers.Authorization = `Bearer ${getToken()}`;
return config;
});
axios.interceptors.response.use(
res => res.data, // 直接返回 data 字段
err => {
if (err.response?.status === 401) logout();
return Promise.reject(err);
}
);
fetch 没有拦截机制，类似逻辑只能封装函数或用 Proxy 包一层，维护成本高，也不易复用。
但要注意：axios 默认发送 JSON 请求时会加 Content-Type: application/json;charset=utf-8，而 fetch 不会自动设，容易导致后端收不到 req.body。
小项目或纯前端 demo，fetch 更轻量；需要稳定交付，axios 更省心
如果只是临时调一个接口、做原型验证，或构建产物体积敏感（比如嵌入式页面），用 fetch 加几行封装就够了。
但真实业务中，以下情况会让 fetch 快速变得复杂：
- 需要取消上一个未完成的搜索请求（防抖+abort）
- 上传文件时要监听进度（
axios支持onUploadProgress，fetch需靠ReadableStream手动读） - 多个环境切换 base URL，且部分接口走代理、部分直连
- 后端返回结构不一致，需要统一 normalize 响应格式
这些不是不能用 fetch 实现，而是每加一项，就多一份胶水代码——而它们正是 axios 已经验证过的路径。
