17370845950

原生 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，省去这层判断。

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 已经验证过的路径。