Axios请求失败如何判断状态？

本文揭示了一种更优雅、健壮的 Axios 错误处理范式——摒弃传统 try-catch 和“先操作后回滚”的脆弱模式，转而通过自定义封装函数（如 safeRequest）配合响应拦截器，让所有请求无论成功或失败都稳定 resolve，并统一返回包含 data、error、status 等字段的结构化结果；这种方式不仅彻底规避了竞态与 UI 不一致风险，还显著提升状态更新的安全性（如删除后直接过滤数组无需回滚）、TypeScript 可类型化程度及代码可组合性，真正实现“响应即事实、状态即驱动”的现代前端异步管理实践。

本文介绍一种不依赖 try-catch 的 Axios 请求错误处理策略，通过响应拦截器与 Promise 封装，统一捕获 HTTP 错误并返回结构化结果，从而安全地执行后续逻辑（如数组更新），避免“先提交后回滚”的冗余操作。

本文介绍一种不依赖 try-catch 的 Axios 请求错误处理策略，通过响应拦截器与 Promise 封装，统一捕获 HTTP 错误并返回结构化结果，从而安全地执行后续逻辑（如数组更新），避免“先提交后回滚”的冗余操作。

在前端开发中，尤其是使用 Axios 进行 RESTful 操作（如 DELETE /account）时，一个常见痛点是：HTTP 成功响应（如 204 No Content）不返回数据体，而网络或服务端错误又会直接抛出异常——这导致无法用简单的 if (response) 判断请求是否成功，更难以在不引入副作用的前提下同步更新本地状态（如从列表中移除对应项）。

虽然 try...catch 是最直观的错误捕获方式，但正如问题中指出的：若采用“先添加/先删除 → 再捕获错误并回滚”的模式，不仅逻辑耦合、可读性差，还可能引发竞态问题（例如 UI 已渲染临时状态，回滚时产生闪烁或不一致）。

✅ 更优雅的解法是：让 Axios 请求始终 resolve，将错误信息也作为“成功响应”的一部分返回。这可通过自定义封装函数 + 响应拦截器实现：

// utils/api.js
import axios from 'axios'

// 统一封装：所有请求均返回 { data, error, status, statusText }
export async function safeRequest(promise) {
  try {
    const response = await promise
    return {
      data: response.data,
      error: null,
      status: response.status,
      statusText: response.statusText,
      config: response.config
    }
  } catch (err) {
    // 注意：Axios Error 对象包含 response（服务端响应）、request（XMLHttpRequest 实例）、message 等
    const response = err.response || {}
    return {
      data: null,
      error: {
        message: err.message,
        code: err.code, // 如 'ECONNABORTED'
        status: response.status || null,
        statusText: response.statusText || 'Network Error',
        data: response.data || null
      },
      status: response.status || 0,
      statusText: response.statusText || 'Network Error',
      config: err.config
    }
  }
}

使用示例（Nuxt 3 或通用 Vue/React 场景）：

// 删除账户并更新本地列表
const handleDeleteAccount = async (accountId) => {
  const result = await safeRequest(
    $nuxt.$axios.delete(`/account/${accountId}`)
  )

  if (result.error) {
    console.error('删除失败:', result.error)
    // 可触发 Toast 提示、记录日志等
    return
  }

  // ✅ 此处可确信请求成功（HTTP 2xx/204）
  // 直接从 items 数组中移除，无需回滚逻辑
  items.value = items.value.filter(item => item.id !== accountId)
  console.log('删除成功，状态码:', result.status) // 如 204
}

? 关键优势：

• 状态驱动，非副作用驱动：不再需要“预操作 + 回滚”，所有状态变更严格基于真实响应；
• 类型友好：返回值结构固定，便于 TypeScript 类型定义（如 type SafeResponse = { data: T | null; error: ErrorInfo | null; ... }）；
• 可组合性强：safeRequest() 可用于任何 Axios 调用（GET/POST/DELETE），也可嵌套在 Pinia/Vuex action 中；
• 兼容性无损：不修改原始 Axios 行为，仅提供增强封装。

⚠️ 注意事项：

• 204 No Content 响应的 response.data 为 undefined 或空字符串，这是符合规范的，safeRequest 会如实透传，业务层需按需处理（如忽略 data，仅校验 status === 204）；
• 若需全局启用该行为（而非手动调用 safeRequest），可配置 Axios 实例的 transformResponse 或使用 interceptors.response.use(onFulfilled, onRejected) 返回标准化对象 —— 但需注意 onRejected 中仍需 return Promise.resolve(...) 阻止异常冒泡；
• 不要混淆「网络错误」（如超时、断网）与「业务错误」（如 401/403/404），二者在 result.error 中均有明确区分字段（error.status 存在即为 HTTP 错误，否则为网络层异常）。

总结：放弃“用 if(response) 判断成功”的旧范式，拥抱“统一 resolve + 结构化错误”的现代 API 封装思路，能让异步状态管理更健壮、可测、可维护。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Axios请求失败如何判断状态？》文章吧，也可关注golang学习网公众号了解相关技术文章。