面试导航 - 程序员面试题库大全 | 前端后端面试真题 | 面试

在 Web 开发过程中，HTTP 状态码是用于标识客户端请求的返回结果、服务器端的处理状态以及可能出现的错误的重要机制。本文将详细介绍 HTTP 状态码的工作原理以及常见的状态码类别和用途。

HTTP 状态码概述

HTTP 状态码是服务器对客户端 HTTP 请求的响应中包含的三位数字代码。这些状态码被分为五个类别，每个类别用第一个数字表示：

• 1xx：信息性响应 - 请求已接收，继续处理
• 2xx：成功响应 - 请求已成功接收、理解和处理
• 3xx：重定向 - 需要进一步操作才能完成请求
• 4xx：客户端错误 - 请求包含语法错误或无法完成
• 5xx：服务器错误 - 服务器在处理请求时发生错误

常见状态码详解

1xx - 信息性响应

• 100 Continue：服务器已收到请求的初始部分，客户端应继续发送剩余部分
• 101 Switching Protocols：服务器同意切换协议，如从 HTTP 升级到 WebSocket
• 103 Early Hints：与 Link 头一起使用，允许用户代理在服务器准备响应时开始预加载资源

2xx - 成功响应

• 200 OK：请求成功，返回的响应取决于请求方法
• 201 Created：请求成功且服务器创建了新资源
• 202 Accepted：请求已接受但尚未处理完成，适用于异步处理
• 204 No Content：请求成功处理，但不需要返回任何实体内容
• 206 Partial Content：服务器成功处理了部分 GET 请求，用于断点续传

3xx - 重定向

• 300 Multiple Choices：请求有多个可能的响应
• 301 Moved Permanently：请求的资源已永久移动到新位置
• 302 Found：临时重定向到其他位置
• 303 See Other：用于 POST/PUT/DELETE 请求完成后重定向到另一个资源
• 304 Not Modified：资源未修改，可使用缓存版本
• 307 Temporary Redirect：临时重定向，但保留原请求方法
• 308 Permanent Redirect：永久重定向，但保留原请求方法

4xx - 客户端错误

• 400 Bad Request：服务器无法理解请求语法
• 401 Unauthorized：需要身份验证
• 403 Forbidden：服务器理解请求但拒绝执行
• 404 Not Found：服务器找不到请求的资源
• 405 Method Not Allowed：请求方法不被允许
• 406 Not Acceptable：服务器无法提供符合客户端要求的内容
• 409 Conflict：请求与服务器当前状态冲突
• 413 Payload Too Large：请求体超过服务器处理限制
• 415 Unsupported Media Type：服务器不支持请求的媒体格式
• 429 Too Many Requests：用户在给定时间内发送了太多请求（限流）

5xx - 服务器错误

• 500 Internal Server Error：服务器遇到意外情况
• 501 Not Implemented：服务器不支持请求的功能
• 502 Bad Gateway：作为网关的服务器从上游服务器收到无效响应
• 503 Service Unavailable：服务器暂时无法处理请求
• 504 Gateway Timeout：网关服务器未能及时从上游服务器获得响应

特殊状态码

• 418 I’m a teapot：1998 年的愚人节玩笑，表示服务器拒绝冲泡咖啡，因为它是茶壶
• 451 Unavailable For Legal Reasons：因法律原因无法提供内容，参考小说《华氏 451 度》
• 499 Client Closed Request：Nginx 特有，客户端在服务器处理请求之前关闭了连接

状态码的历史演变

HTTP 状态码随着 HTTP 协议的发展而不断扩展。最初的 HTTP/0.9 协议非常简单，没有状态码的概念。HTTP/1.0 引入了状态码系统，HTTP/1.1 进一步扩展了状态码集合，而 HTTP/2 和 HTTP/3 则保持了与 HTTP/1.1 相同的状态码体系。

状态码的标准化

HTTP 状态码由 IETF（互联网工程任务组）在 RFC 文档中标准化。主要的状态码定义在以下 RFC 中：

• RFC 7231：HTTP/1.1 语义和内容
• RFC 7232：HTTP/1.1 条件请求
• RFC 7233：HTTP/1.1 范围请求
• RFC 7235：HTTP/1.1 认证
• RFC 6585：HTTP 附加状态码

深入理解关键状态码

身份验证相关状态码

401 Unauthorized 与 403 Forbidden 的区别：

• 401 表示”未认证”，客户端需要提供有效的身份验证凭据
• 403 表示”已认证但未授权”，服务器理解请求但拒绝执行

身份验证流程通常如下：

1. 客户端请求受保护资源
2. 服务器返回 401 状态码，并在 WWW-Authenticate 头中指定认证方式
3. 客户端提供凭据重新请求
4. 如果凭据有效但权限不足，服务器可能返回 403

缓存控制状态码

304 Not Modified 的工作机制：

1. 客户端发送带有条件头的请求（如 If-Modified-Since 或 If-None-Match）
2. 服务器检查资源是否已修改
3. 如未修改，返回 304 状态码（无响应体）
4. 客户端使用本地缓存的版本

这种机制显著减少了网络传输量，提高了 Web 应用性能。

重定向状态码的正确使用

重定向状态码（3xx）之间的细微差别：

状态码在不同 Web 技术中的应用

状态码与浏览器行为

浏览器对不同状态码有特定的处理方式：

• 对于 301/302/303/307/308，浏览器自动跟随重定向
• 对于 401，浏览器可能显示认证对话框
• 对于 404/500 等错误，浏览器通常显示默认错误页面

状态码在前端框架中的处理

现代前端框架（如 React、Vue、Angular）通常通过拦截器或中间件处理 HTTP 状态码：

// Axios 拦截器示例
axios.interceptors.response.use(
  (response) => response,
  (error) => {
    if (error.response) {
      switch (error.response.status) {
        case 401:
          // 重定向到登录页
          break;
        case 403:
          // 显示权限不足提示
          break;
        case 404:
          // 显示资源不存在页面
          break;
        case 500:
          // 显示服务器错误提示
          break;
      }
    }
    return Promise.reject(error);
  },
);

状态码在后端框架中的使用

不同后端框架提供了便捷的状态码处理方式：

Node.js/Express:

app.get('/resource', (req, res) => {
  if (!req.isAuthenticated()) {
    return res.status(401).json({ error: 'Authentication required' });
  }
  // 处理请求...
});

Python/Django:

from django.http import JsonResponse
from django.shortcuts import get_object_or_404
 
def get_resource(request, resource_id):
    if not request.user.is_authenticated:
        return JsonResponse({'error': 'Authentication required'}, status=401)
 
    resource = get_object_or_404(Resource, id=resource_id)
    // 处理请求...

状态码与 HTTP 头的关系

某些状态码通常与特定的 HTTP 头一起使用：

状态码监控与分析

状态码在日志分析中的价值

监控 HTTP 状态码分布可以揭示系统健康状况：

• 大量 500 错误可能表明服务器问题
• 突然增加的 404 错误可能表明链接失效或爬虫行为
• 401/403 错误峰值可能表明认证系统问题或安全攻击

状态码与性能监控

常见的监控指标包括：

• 错误率：(4xx + 5xx) / 总请求数
• 服务可用性：(总请求数 - 5xx) / 总请求数
• 重定向比例：3xx / 总请求数

常见问题与最佳实践

状态码常见误用

• 使用 200 OK 返回错误信息（应使用适当的 4xx/5xx 状态码）
• 对所有错误统一返回 500（应使用更具体的状态码）
• 混淆 401 和 403 的使用场景
• 返回 302 而非 303 用于 POST 请求后的重定向

自定义状态码的考量

虽然可以定义自定义状态码（如 Nginx 的 499），但这可能导致兼容性问题。更好的做法是：

• 坚持使用标准状态码
• 在响应体中提供详细的错误代码和描述
• 使用标准扩展机制（如 RFC 6648）

总结

HTTP 状态码是 Web 通信中的重要组成部分，它们提供了关于请求处理结果的简洁信息。理解和正确使用这些状态码可以帮助开发者构建更健壮、更易于调试的 Web 应用和 API。在实际开发中，应根据具体场景选择最合适的状态码，并确保客户端能够正确处理各种可能的响应状态。

通过深入理解 HTTP 状态码的工作原理、使用场景和最佳实践，开发者可以设计出更符合 HTTP 语义的 API，提供更好的用户体验，并简化系统的调试和维护工作。