别只盯着 200：JS 处理接口状态码的实战避坑指南

前端调试最让人头大的时刻，莫过于控制台显示请求状态码 200，界面却一片灰暗，或者弹出一个莫名其妙的错误提示。很多新手容易陷入一个误区：只要 HTTP 状态码是 200，就代表业务成功了。但在实际开发中，这往往是“坑”的开始。

理解这一点至关重要：HTTP 协议的状态码只代表传输是否成功，并不代表你的业务逻辑是否通过。 后端可能返回了 200 OK，但数据体里的 code 却是 50001（库存不足）或 9999（系统维护）。这时候，如果你只根据 response.status 做判断，用户体验会大打折扣。

分清两层“状态码”

在实际对接时，建议把状态码分成两个层级来看待。

第一层是网络传输层。这是浏览器和服务器之间的对话，比如 200（成功）、404（资源未找到）、500（服务器内部错误）、502（网关错误）。这一层的错误通常意味着程序出问题了，比如服务挂了、网络断了或者接口地址配错了。

第二层是业务逻辑层。这是后端定义在响应报文内部的自定义编码。常见做法是在 JSON 数据里放一个 code 字段。虽然 HTTP 是 200，但这个 code 可能是 -1（参数错误）、1002（用户未登录）。

处理这两层关系的最佳实践，是建立统一的响应拦截机制。以 Axios 为例，不要每个页面都写一遍 if (res.data.code !== 200)，而是把这部分逻辑封装起来。

// 核心思路：在响应拦截器中统一处理业务状态码
service.interceptors.response.use(
  response => {
    const res = response.data
    // 假设后端约定 code 为 200 代表业务成功
    if (res.code !== 200) {
      // 抛出错误，让组件层直接捕获
      return Promise.reject(new Error(res.message || 'Error'))
    } else {
      return res
    }
  },
  error => {
    // 这里是处理 HTTP 状态码的关键区域
    console.error('Request failed:', error)
    return Promise.reject(error)
  }
)

那些容易被忽视的边缘状态

除了常规的 200，有几个特定的状态码值得单独拎出来聊聊，因为它们的处理方式直接关系到用户的操作流畅度。

遇到 401 Unauthorized 时，通常意味着 Token 过期了。这时候直接弹框让用户输密码往往体验不好，更优雅的做法是尝试静默刷新 Token。如果刷新失败，再引导跳转至登录页。这样用户无需重新输入账号密码，只需点击确认即可继续当前操作，这种无感修复能极大降低流失率。

至于 403 Forbidden，说明身份合法但权限不足。这种情况不需要刷新登录态，直接给个明确的提示“该功能暂无权限”，并隐藏相关按钮就好，避免用户在界面上反复点击碰壁。

还有一个隐蔽的问题：网络断开或超时。当没有网络连接时，axios 抛出的 error 对象里 response 可能是 undefined。这种情况下不能按 500 服务器错误处理，而应该告诉用户“当前网络不可用，请检查连接”。在代码里增加一个判断：

if (!error.response) {
  // 网络错误或超时处理
}

别让错误信息吓到用户

最后想多说一句关于“报错文案”的事。很多时候我们直接把后端传回来的 message 渲染到了 UI 上。但如果后端是个甩手掌柜，传回来的是一串技术堆栈或者数据库 SQL 语句，用户看到只会觉得产品很不专业。

建议在后端配合的前提下，在前端对未知错误进行二次封装。 比如将“系统繁忙，请稍后再试”作为兜底文案。对于 500 系列错误，不要试图在前端强行恢复，而是给出一个友好的反馈，甚至提供一个“重试”按钮，比单纯的红字警告要友好得多。

写好状态码的处理逻辑，本质上不是为了省几个 if-else，而是为了让用户在不同情况下都能得到确定的反馈。无论是登录失效、权限不足还是网络波动，清晰的指引能让应用看起来更有生命力，这才是技术落地的真正价值。