请解释-HTTP-中的状态码,常见的状态码有哪些

JAY.LIN 收录于前端开发 Node Javascript

2025-03-05 约 1374 字预计阅读 3 分钟

https://bing.ee123.net/img/rand?artid=146054933

请解释 HTTP 中的状态码，常见的状态码有哪些？

一、HTTP状态码基础概念

HTTP状态码是服务器对客户端请求的三位数字响应标识，由RFC 7231等规范定义。

其核心作用是快速传递请求处理结果，帮助开发者定位问题。状态码按首字母分为五类：

1xx ：信息性响应（如100 Continue）
2xx ：成功响应（如200 OK）
3xx ：重定向（如301/302）
4xx ：客户端错误（如404 Not Found）
5xx ：服务器错误（如500 Internal Server Error）

二、高频状态码解析与代码示例

1. 2xx系列（成功）

200 OK

// 典型GET请求成功处理
fetch('/api/data')
  .then(response => {
    if (response.ok) { // 隐式检查200-299状态码
      return response.json()
    }
    throw new Error(`HTTP error! status: ${response.status}`)
  })

建议：前端需明确区分数据为空（返回200+空数组）与错误场景，避免将业务逻辑错误混用HTTP状态码。

201 Created

// 资源创建成功（如提交表单）
fetch('/api/users', {
  method: 'POST',
  body: JSON.stringify({ name: 'John' })
}).then(response => {
  if (response.status === 201) {
    const newUserUrl = response.headers.get('Location') // 获取新资源地址
  }
})

注意点 ：需配合 Location 头实现资源定位，适用于RESTful API设计。

2. 3xx系列（重定向）

301 Moved Permanently

<!-- 老版本浏览器兼容方案 -->
<meta http-equiv="refresh" content="0; url=https://new-domain.com">

陷阱：SPA应用慎用服务端301，可能导致路由系统失效，应在前端路由层处理永久跳转。

304 Not Modified

// 缓存验证请求
fetch('/api/data', {
  headers: {
    'If-Modified-Since': 'Wed, 05 Mar 2025 00:00:00 GMT' 
  }
}).then(response => {
  if (response.status === 304) {
    // 使用本地缓存数据
  }
})

优化：配合 ETag 或 Last-Modified 实现精准缓存控制，减少带宽消耗。

3. 4xx系列（客户端错误）

400 Bad Request

// 表单验证失败处理
try {
  await submitForm()
} catch (error) {
  if (error.response?.status === 400) {
    const { details } = error.response.data // 展示具体错误字段
    highlightInvalidFields(details) 
  }
}

建议：后端需返回结构化错误详情（如JSON Schema验证结果），前端避免仅展示通用错误提示。

401 Unauthorized

// Token过期自动刷新方案
const request = async (url) => {
  let res = await fetch(url)
  if (res.status === 401) {
    await refreshToken()
    res = await fetch(url) // 重试请求
  }
  return res
}

安全实践 ：避免将 WWW-Authenticate 头暴露给前端，防止XSS攻击获取敏感信息。

4. 5xx系列（服务器错误）

503 Service Unavailable

// 服务降级策略
try {
  return await fetchApi()
} catch (error) {
  if (error.response?.status === 503) {
    showFallbackUI() // 显示备用内容
    logToSentry(error) // 错误监控
  }
}

容灾设计 ：前端需实现自动重试机制（如指数退避算法），配合全局Loading状态避免用户重复提交。

三、开发陷阱与最佳实践

状态码混用反模式

// 错误示例：用200包装业务错误
// 后端返回
HTTP/1.1 200 OK
{"code": 500, "message": "Internal Error"}

// 正确做法：直接返回5xx状态码
HTTP/1.1 500 Internal Server Error

理由：破坏HTTP语义，导致监控系统失效，增加前端错误处理复杂度。

重定向的正确姿势

// POST请求后应使用303而非302
// 服务端设置
res.status(303).set('Location', '/success')

// 前端处理
if (response.status === 303) {
  window.location = '/success' // 强制GET跳转
}

原理：302默认保持原请求方法，可能导致POST重复提交。

API限流通知

// 429状态码处理
const retryAfter = response.headers.get('Retry-After') || 60
setTimeout(() => retryRequest(), retryAfter * 1000)

扩展：可配合 X-RateLimit-* 头实现更精细的限流提示。

四、调试与监控

Network面板过滤
Chrome开发者工具中可通过 status-code:200 等过滤器快速定位特定请求。
错误埋点设计

window.addEventListener('unhandledrejection', event => {
  if (event.reason?.status) {
    trackError(`HTTP_${event.reason.status}`) 
  }
})

HAR文件分析
导出请求瀑布流文件，结合自动化工具统计状态码分布，识别异常模式。

总结

理解HTTP状态码的语义边界是区分初级与高级开发者的关键能力。建议：

严格遵循RFC规范定义的状态语义
建立前后端状态码对照表，统一错误处理范式
在网关层拦截非法状态码，避免污染监控数据
设计可降级的错误处理中间件（如axios拦截器）

更多状态码细节可参考MDN文档或RFC 7231规范