Informational 1xx

100 Continue【服务器给客户端的“绿灯”】

用途：客户端（比如浏览器）在发送较大数据（比如文件上传）前，先问服务器：“我要发数据了，你准备好了吗？”

服务器回应：

• 如果服务器说 100 Continue，表示：“可以发，我等着！”
• 如果服务器拒绝（比如文件太大），客户端就不用白费流量发送了。

节省资源：避免客户端直接发送大量数据后，才发现服务器不接收，浪费时间和带宽。

举个栗子：

• 你上传一个1GB的视频 → 浏览器先问服务器：“能传吗？”
• 服务器检查空间足够 → 回复 100 Continue → 浏览器开始上传。
• 如果服务器空间不足 → 回复错误（如 413 Payload Too Large）→ 上传直接取消。

101 Switching Protocols【服务器在说：“好的，我们换个新协议聊天吧！”】

用途：当客户端（比如浏览器）和服务器需要升级通信协议时使用。

• 常见场景：从 HTTP 协议 切换到 WebSocket（比如网页聊天室、实时游戏）。

交互过程：

• 客户端请求升级协议（比如：Upgrade: websocket）。
• 服务器同意 → 返回 101 Switching Protocols，之后双方就用新协议通信。

关键点：协议切换后，原来的HTTP连接会变成另一种协议（比如WebSocket），继续传输数据。

举个栗子：

• 网页聊天室：
• 浏览器用HTTP连到服务器，请求升级到WebSocket。
• 服务器返回 101 → 双方开始通过WebSocket实时收发消息。
• HTTP/2 升级：从旧的HTTP/1.1切换到更快的HTTP/2。

102 Processing【服务器的“进度条提醒”，意思是：“我没卡死，活还在干，请稍候！” 】

用途：服务器告诉客户端：“你的请求我收到了，但处理起来比较耗时，别急着超时，我还在努力！”

• 适用于长时间运行的操作（比如大文件处理、复杂计算）。

为什么需要它？

• 如果没有这个状态码，客户端可能以为“卡住了”，直接断开连接或重试，导致重复提交。

和 100 Continue 的区别：

• 100 是问：“能发数据吗？” → 服务器说：“可以发。”
• 102 是：“数据已收到，正在处理，请耐心等结果。”

举个栗子：

• 上传大文件并转码：
• 你传了一个视频到云盘，服务器返回 102，表示：“正在转码，别关页面！”
• 批量删除操作：
• 删除1万条数据时，服务器返回 102，避免客户端以为请求丢失。

103 Early Hints【服务器的“抢跑指令”，意思是：“正式内容还没好，但这些资源你可以先准备着！” 】

用途：服务器在正式响应（比如HTML页面）准备好之前，先提前告诉浏览器可以预先加载哪些资源（比如CSS、JS、图片）。

• 类似“剧透”关键信息，让浏览器聪明地提前准备。

为什么需要它？

• 传统流程：浏览器必须等完整HTML下载完，才发现需要加载CSS/JS，浪费时间。
• 用 103 后：服务器在生成HTML的同时，先发个“预告”：“待会儿要用这些文件，你先去下载吧！”

效果：网页加载更快，用户体验更流畅（尤其对慢速网络或复杂网站）。

举个栗子：

• 访问一个网站：
• 浏览器请求首页。
• 服务器先返回 103，提示：“你先去加载 styles.css 和 logo.png 吧！”
• 浏览器并行下载这些资源，同时等服务器生成完整的HTML。
• 电商网站：提前提示加载商品图片，减少用户等待时间。

Successful 2xx

200 OK【互联网的“绿灯”，意思是：“搞定！你要的东西在这儿！”】

用途：服务器告诉客户端（比如浏览器）：“你的请求我成功处理了，这是你要的东西！”

• 适用于几乎所有成功的请求（比如加载网页、下载文件、提交表单成功）。

常见场景：

• 打开网页 → 返回 200 + HTML内容。
• 下载图片 → 返回 200 + 图片数据。
• 提交登录表单 → 返回 200 + “欢迎页面”。

为什么它重要？

• 它是HTTP最“理想”的状态码，表示一切按预期运行。

  举个栗子：

• 浏览知乎首页：
• 浏览器请求 zhihu.com → 服务器返回 200 + 网页内容。
• 微信发送消息：
• 你发“你好”给朋友 → 服务器返回 200（表示消息发送成功）。

201 Created【服务器的“确认函”，意思是：“你要的东西我做好了，这是它的身份证（地址）！” 】

用途：服务器告诉客户端：“你让我创建的新资源（比如文件、用户账号、订单）已经成功搞定了！”

• 和 200 OK 的区别：200 是通用成功，而 201 专门用于新建资源成功。

常见场景：

• 注册新用户 → 返回 201 + 用户ID。
• 上传新文件到网盘 → 返回 201 + 文件链接。
• 提交订单 → 返回 201 + 订单编号。

通常会附带新资源的地址：

• 服务器会在响应头中加一个 Location 字段，告诉客户端：“这是你刚创建的东西的访问路径”。

举个栗子：

• 发微博：
• 你发了一条新微博 → 服务器返回 201 + 微博ID（比如 /posts/123）。
• GitHub新建仓库：
• 你创建了一个叫 my-project 的仓库 → 返回 201 + 仓库地址 github.com/yourname/my-project。

202 Accepted【服务器的"收件回执"，意思是："活我接了，但结果要等等，你可以先忙别的去" 】

用途：服务器告诉客户端："你的请求我收到了，也接受了，但还没处理完，结果要等等"

• 和 200/201 的关键区别：202 表示"已接收但未完成"

典型使用场景：

• 需要排队处理的任务（比如视频转码）
• 需要人工审核的内容（比如用户投稿）
• 需要调用外部系统的操作（比如支付结算）

后续跟进方式：

• 响应中通常会包含一个状态查询接口（比如 /task-status/123）
• 也可能通过回调通知（webhook）告知最终结果

举个栗子：

• 视频网站上传：
• 你传了个4K视频 → 服务器返回 202："视频已接收，正在转码，可通过/task/456查询进度"
• 银行转账：
• 你发起大额转账 → 银行返回 202："交易已受理，需要人工审核，2小时内短信通知结果"

203 Non-Authoritative Information【服务器的"免责声明"："这消息绝对保真，但不保证是最新版本哦！"】

用途：代理服务器告诉客户端："这个响应不是我生成的，是原始服务器的，但可能不是最新鲜的"

• 就像"二手信息"，虽然来自权威来源，但可能不是第一手

出现场景：

• 使用了缓存代理服务器（CDN）
• 响应头信息被代理修改过
• 原始服务器的完整验证不可用

与200 OK的区别：

• 200：这是新鲜出炉的数据！
• 203：这是从别处转发的数据，可能有点"回锅"

举个栗子：

• 新闻网站：
• 你访问的页面来自CDN缓存（203）
• 页脚显示"数据最后更新于10分钟前"
• API调用：
• 请求经过网关转发
• 响应头显示部分字段被网关修改过

204 No Content【服务器的"默契点头"："事情办妥了，不用我多说，你懂的~" 】

用途：服务器成功处理了请求，但不需要返回任何内容

• 就像点头确认，不需要多余的解释

典型使用场景：

• 表单提交只需成功反馈（如"保存成功"弹窗）
• 删除操作成功
• 自动化的后台操作

特殊优势：

• 节省网络流量（没有多余的响应体）
• 让前端可以自由处理成功逻辑

举个栗子：

点赞功能：

• 点击"喜欢"按钮 → 服务器返回 204
• 前端直接切换爱心图标即可，不需要服务器返回新数据

清空购物车：

• 点击"全部删除" → 204 表示成功
• 页面直接清空列表，不需要刷新

205 Reset Content【服务器的"黑板擦"："操作成功啦，现在把页面擦干净，可以重新开始了！"】

用途：服务器告诉客户端（通常是浏览器）："请求已成功处理，现在请清空当前表单/显示内容，方便用户重新输入"

• 和 204 的关键区别：204 只是"完成"，205 还要求"重置"

设计初衷：

• 专门为网页表单设计的状态码
• 避免用户重复提交相同内容

实际效果：

• 浏览器收到后会清空当前表单的所有输入框
• 但不会刷新页面（和页面刷新不同）

举个栗子：

• 问卷调查提交后：
• 提交成功 → 返回 205
• 网页自动清空所有选择题选项，方便下一位用户填写
• 在线测试系统：
• 交卷成功后 → 返回 205
• 自动清空答题卡，准备下一场考试

206 Partial Content【服务器的"分餐服务"："你要的第2-5分钟的视频片段在这，其他部分需要再问我拿！"】

用途：服务器成功返回了客户端请求的部分内容（就像视频"断点续传"）

• 必须配合 Range 请求头使用
• 响应会包含 Content-Range 说明这是哪一部分

为什么需要它：

• 大文件可以分块下载（比如暂停/继续）
• 网络不好时不用重头开始
• 支持快速跳转到视频的某个时间点

特殊优势：

• 节省带宽（不用下载完整文件）
• 提升大文件传输可靠性

举个栗子：

• 在线视频网站：
• 拖动进度条到中间 → 浏览器请求"从10MB开始的内容"
• 服务器返回 206 + 视频的10-20MB片段
• 下载管理器：
• 下载到50%暂停 → 下次从50%继续请求
• 服务器返回剩余部分

207 Multi-Status【服务器的清单，每个都有状态码】

用途：当客户端一次请求多个操作时，服务器返回每个操作的独立状态

• 就像一个包裹里装着多个子请求的结果报告
• 常见于 WebDAV 协议（网络文件管理）

数据格式：

• 响应体是一个 XML/JSON 列表
• 每个子项都有独立的状态码（比如 200/404/403 等）

典型场景：

• 批量删除云盘文件（有的成功有的失败）
• 同时获取多个资源的状态
• 日历系统处理多个会议邀请

举个栗子：

网盘批量操作：

• 同时删除10个文件 → 返回 207
• 响应体显示：

[
  { "file1.txt": 204 }, // 成功
  { "file2.jpg": 404 }, // 不存在
  { "file3.pdf": 403 }  // 无权限
]

智能家居控制：

• 同时开关5个设备 → 返回每个设备的执行状态

208 Already Reported【服务器的"去重标记"："这些内容上次给过了，这次跳过，只看新的！" 】

用途：在批量查询时，避免重复返回之前已经报告过的结果

• 通常配合 207 Multi-Status 使用
• 相当于数据去重标记
• 常用于 WebDAV

工作流程：

• 第一次请求：返回完整结果（含A/B/C项）
• 第二次请求：只返回新项D/E，对A/B/C项用208占位

核心价值：

• 节省网络传输量
• 避免客户端处理重复数据

举个栗子：

同步网盘文件列表：

• 首次获取：返回全部50个文件状态
• 增量同步：只返回新增/变化的5个文件，其余45个用208表示"这些没变过"

日历系统同步：

• 已经同步过的旧事件标记为208
• 只传输新增事件

226 IM Used【服务器的"智能省流模式"："你要的数据我用了优化版，不是原始完整版！"】

用途：服务器对实例操作（Instance Manipulation）的确认

• 表示返回的内容是经过特定处理的版本（如差分/压缩/缓存版本）
• 常见于 Delta Encoding（差分编码）场景
• 这个状态码就像HTTP协议里的"黑科技"，能极大提升传输效率，但需要客户端和服务器共同支持

核心特点：

• 响应头会包含 IM（Instance Manipulation）字段
• 客户端必须明确支持这种处理方式

优势：

• 大幅减少数据传输量
• 特别适合频繁更新的资源

举个栗子：

在线文档协作：

• 你编辑了文档的第5行
• 服务器返回 226 + 只含第5行变化的差分数据
• 而不是返回整个文档

APP增量更新：

• 更新时只下载变化的部分（226）
• 而不是整个安装包

Redirection 3xx

300 Multiple Choices 【服务器的"选项菜单"："亲，你要的东东有N个版本，选一个呗~" 】

用途：服务器提供多个可选资源版本，需要客户端/用户选择其中一个

• 常见于内容协商（Content Negotiation）场景
• 实际开发中这个状态码很少见，通常服务器会直接返回最优版本（用200）或重定向（用301/302）

典型情况：

• 同一个资源有不同语言版本（英文/中文/日文）
• 同一文件有不同格式（PDF/Word/TXT）
• 同一视频有不同分辨率（720p/1080p）

响应特点：

• 会返回 Location 或 Alternates 头列出选项
• 可能需要人工选择，或浏览器自动选最优版本

举个栗子：

国际网站访问：

• 访问 example.com → 返回 300
• 提供 example.com/en（英文）和 example.com/cn（中文）选项

文档下载：

• 请求报告文件 → 返回 300
• 可选 PDF/Excel/CSV 三种格式

301 Moved Permanently 【互联网的"搬家通知单"："老地址已废弃，请收藏新地址，以后都来这儿找我！" 】

用途：告诉浏览器或搜索引擎：这个网址已永久迁移到新地址

• 旧地址作废，所有流量应该转向新地址

核心特点：

• 自动跳转（浏览器会直接访问新地址）
• 搜索引擎会更新索引（把旧网址的权重转移到新网址）

响应必备：

• Location 字段标明新地址（比如 Location: https://新地址.com）

和302（临时跳转）的区别：

• 301（永久）搜索引擎会更新记录
• 302（临时）搜索引擎保留旧地址

举个栗子：

网站更换域名：

• 访问 old.com → 返回 301 + Location: new.com
• 浏览器自动跳转到 new.com

HTTP升级HTTPS：

• 访问 http://example.com → 301 跳转到 https://example.com

302 Found 【服务器的"临时指路牌"："亲，今天走这边，明天记得走原路哦~"】

用途：服务器告诉浏览器："你要找的东西临时放在另一个地址，先去那里拿"

• 关键在"临时"二字，原网址后续还会继续使用
• 保留原地址，不传递SEO权重
• 现代开发更推荐用 303（See Other） 或 307（Temporary Redirect） 替代

核心特点：

• 浏览器会自动跳转到新地址（用户可能察觉不到）
• 搜索引擎不会更新收录链接（知道这是临时安排）

响应必备：

• Location 字段标明临时地址（如 Location: /temp-page）

举个栗子：

网站维护：

• 访问首页 → 302 跳转到维护公告页

登录跳转：

• 访问 /admin → 临时跳转到 /login（登录后仍返回/admin）

A/B测试：

• 临时将部分用户跳转到新版本页面

303 See Other 【服务器的"安全跳转指令"："表单已提交，现在请用GET方法去新页面查看结果，这样刷新也不怕！】

用途：服务器明确要求客户端用GET方法去另一个地址查看结果

• 专门用于POST提交后的重定向
• 避免用户重复提交表单（刷新页面不会重复POST请求）
• 强制转为GET方法，专为POST提交设计

核心特点：

• 强制把后续请求转为GET方法（无论原请求是什么方法）
• 响应必须包含 Location 字段（指向新地址）

设计初衷：

• 解决浏览器刷新重复提交表单的问题
• 实现PRG模式（Post-Redirect-Get）

举个栗子：

表单提交成功：

• 提交订单 → 服务器处理 → 303 跳转到 /order-success
• 即使用户刷新页面，也只是刷新成功页，不会重复下单

支付完成跳转：

• 支付请求完成后 → 303 跳转到账单详情页

304 Not Modified 【服务器的"省流量神器"："你要的东西还是老样子，用你手机里存的版本就行啦！" 】

用途：服务器告诉浏览器："你要的资源没变化，直接用本地缓存吧！"

• 专为缓存优化设计的状态码
• 不返回实际数据，省流量

触发条件：

• 浏览器携带 If-Modified-Since（上次修改时间）或 If-None-Match（文件指纹）
• 服务器比对后发现资源未更新

核心优势：

• 减少不必要的数据传输
• 提升网页加载速度

注意：

• 虽然状态码是3xx开头，但不是重定向
• 响应体必须为空（因为没传数据）

举个栗子：

刷新新闻网站：

• 浏览器问："首页内容有变吗？这是昨天的版本指纹 xyz123"
• 服务器："没变（304），继续用你缓存的版本吧"

加载网页图片：

• 已缓存的LOGO图片第二次加载时直接返回 304

305 Use Proxy 【服务器的"硬性通道要求"："想访问我？必须从指定代理走，否则免谈！"】

用途：服务器明确要求客户端必须通过指定的代理服务器访问资源

• 像一道"强制关卡"，所有请求必须经过代理
• 响应中会包含代理服务器的地址（Location 字段）
• 主流浏览器已不再支持305状态码，因为强制代理可能被恶意利用

设计初衷：

• 企业内网安全管控
• 内容过滤或审计

核心特点：

• 代理地址通常以 http:// 或 https:// 开头
• 浏览器需要重新发送完整请求到代理

现状：

• 这个状态码已被废弃（因安全风险）
• 现代网络改用以下方案替代：
• 自动代理配置（PAC文件）
• 透明代理（用户无感知）
• HTTP 407（代理要求认证）

举个栗子：

公司网络限制：

• 访问外网 → 返回 305 + 代理地址 proxy.company.com:8080
• 所有流量必须经过这个代理

学校上网认证：

• 连校园网后首次访问任何网站 → 跳转到认证代理

306 Switch Proxy （已废弃）

原始用途：

• 要求客户端切换到另一个代理服务器
• 类似305的升级版，用于代理服务器之间的切换

现状：

• 该状态码在HTTP/1.1规范中被正式删除
• 现代HTTP协议中完全不再使用

为什么被废弃：

• 存在安全隐患（可能被恶意代理利用）
• 被更安全的方案替代（如自动代理配置PAC）

307 Temporary Redirect 【服务器的"无损临时搬迁"："临时换地方办事，但你的所有材料都要原封不动带过去！" 】

用途：服务器告诉浏览器："资源临时搬到新地址，但必须用原来的方式访问"

• 关键特点：保持原始请求方法（POST仍用POST跳转，GET仍用GET）
• 和302的核心区别：不会把POST偷偷改成GET

典型场景：

• 网站临时维护（但表单提交不能丢失）
• A/B测试需要保持请求方法
• 负载均衡临时转移请求

响应必备：

• Location 字段标明临时地址

举个栗子：

支付系统维护：

• 提交支付请求 → 307 跳转到备用服务器
• 保证支付数据不会因为跳转而丢失

API临时迁移：

• POST /v1/orders → 307 临时指向 /temp/v1/orders

308 Permanent Redirect 【服务器的"完美搬家通知"】

用途：服务器声明："资源已永久搬家，且要求所有访问必须保持原始请求方式"

• 是 301 + 307 的结合体：既永久，又保持请求方法
• 响应必须包含 Location 指向新地址

核心特点：

• 永久性：搜索引擎会更新索引（和301相同）
• 严格性：POST请求跳转后仍是POST（解决301的方法丢失问题）

适用场景：

• API接口永久迁移
• 网站改版时重要表单提交路径变更
• HTTP→HTTPS的强制升级

举个栗子：

银行系统升级：

• 旧转账接口 POST /transfer → 308 永久跳转到 POST /api/v2/transfer
• 保证所有转账请求完整传递到新接口

全站HTTPS化：

• 访问 http://example.com/login → 308 跳转到 https://example.com/login

Client Error 4xx

400 Bad Request 【服务器的"纠错提示"】

用途：服务器表示："我看不懂你的请求，就像读到了一封错别字连篇的信"

• 客户端（浏览器/APP）的请求存在语法错误或缺失关键信息
• 服务器无法理解，因此无法处理

常见触发原因：

• 请求头格式错误（比如漏了Content-Type）
• JSON/XML数据格式错误（缺引号、少括号）
• 上传文件超过大小限制
• 必填参数未提交

举个栗子：

API调用错误：

• 请求体传了 {"name": "张三"（缺少闭合括号）→ 返回 400

网页表单提交：

• 注册时没填密码字段 → 返回 400 + "密码不能为空"

文件上传失败：

• 上传100MB文件但服务器限制50MB → 400 + "文件过大"

401 Unauthorized 【服务器的"身份检查站"】

用途：服务器表示："你需要先登录/提供有效凭证才能访问这个资源"

• 不是程序错误，而是权限控制的第一道关卡
• 通常会弹出登录框（浏览器）或要求API密钥
• 千万别在401响应中泄露敏感信息！比如别说"用户名存在但密码错误"

核心特点：

• 响应头会包含 WWW-Authenticate 字段，说明认证方式
• （例如：Basic 基础认证 / Bearer Token认证）
• 与403的区别：
• 401："你还没证明你是谁"
• 403："我知道你是谁，但你不配访问"

常见认证方式：

• 用户名密码（Basic Auth）
• JWT Token
• OAuth 2.0

举个栗子：

网页未登录访问：

• 直接访问 /admin → 401 + 弹出浏览器登录框

API调用缺失Token：

• 请求 GET /api/user 未带Authorization头 → 401

Token过期：

• 使用过期的JWT访问API → 401 + "Token expired"

402 Payment Required 【互联网世界的"投币口"】

设计初衷：

• 为「在线支付」场景专门保留的状态码
• 理论上应该出现在需要付费才能访问的资源前

实际使用：

• 绝大多数网站和API并不使用它，而是用403或自定义逻辑
• 目前主要出现在两类场景：
• 某些付费API服务（如云计算平台）
• 实验性协议（如WebMoney支付系统）

响应特点：

• 通常会附带支付链接或二维码
• 可能包含 Payment Required 或 Upgrade Required 提示

举个栗子：

付费API调用：

• 请求「高级天气数据接口」→ 返回 402 + "请订阅高级套餐"

下载付费内容：

• 点击下载电子书 → 402 跳转到支付页面

403 Forbidden 【服务器的"权限防火墙"】

用途：服务器明确拒绝请求，即使客户端提供了身份认证

• 和401的区别：
• 401："你是谁？先证明身份"（未认证）
• 403："我知道你是谁，但你不配访问"（已认证但无权限）
• 和404的区别：
• 404："你要的东西不存在"
• 403："东西存在，但就不给你看"

常见触发原因：

• 用户权限等级不够（如普通用户访问管理员接口）
• IP地址被拉黑
• 访问系统敏感目录（如 /etc/）
• 文件权限设置错误（chmod没配好）

特殊变体：

• 403.1：执行访问被禁止（如禁止运行脚本）
• 403.2：读取访问被禁止
• 403.14：目录列表被禁止（常见于关闭了目录浏览的网站）

举个栗子：

网站后台封锁：

• 普通用户访问 /admin → 403 + "您无权查看此页面"

API权限控制：

• 免费用户调用VIP接口 → 403 + "请升级会员"

云服务器配置：

• 直接访问 .env 配置文件 → 403（防止泄露数据库密码）

404 Not Found 【互联网的"寻人启事"】

用途：服务器明确告知："你要的东西在我这里不存在"

• 不是权限问题（不是403）
• 不是服务器错误（不是500）
• 纯粹是资源路径错误或内容已删除

常见触发原因：

• 网址拼写错误（如 prduct.html 少了个字母）
• 内容已被删除但链接还在
• 服务器没有配置默认首页（比如访问 /blog/ 但目录里没有 index.html）

特殊性质：

• 唯一拥有全球通用文化符号的状态码（"404页面"）
• 常被创意设计成趣味页面（如游戏公司做的小游戏404页）

举个栗子：

日常上网：

• 访问 example.com/old-page → 显示 404（页面已迁移）

API调用：

• 请求 GET /api/users/999 → 404（用户ID不存在）

资源失效：

• 点击过期的文件下载链接 → 404

405 Method Not Allowed 【服务器的"操作说明书"】

用途：服务器表示："我认识这个地址，但不接受你用的动作类型"

• 常见于：用GET请求提交数据，或用DELETE请求访问只读接口
• 必须返回 Allow 头，列出支持的请求方法（如 Allow: GET, POST）

常见冲突场景：

• 对只读接口发 POST/PUT/DELETE 请求
• 用 GET 请求提交表单数据（应该用POST）
• 访问需要特定方法的API（如必须用PATCH更新部分数据）

与其他错误的区别：

• 404：地址完全不存在
• 403：地址存在但没权限
• 405：地址存在，但动作不被支持

举个栗子：

错误调用API：

• 用 DELETE /api/articles 想删除所有文章 → 405 + Allow: GET, POST
• （批量删除应该用 POST /api/articles/batch-delete）

网页表单提交：

• 用 GET /submit-form 提交密码 → 405（应该用POST）

只读资源：

• 尝试 PUT /about.html 修改公司介绍页 → 405（静态页面禁止修改）

406 Not Acceptable 【服务器的"定制需求拒绝函"】

用途：服务器表示："你要的数据格式/语言/版本我提供不了"

• 客户端通过 Accept 头提出了过于挑剔的要求
• 服务器无法满足，又不愿默认返回低质量内容

常见触发条件：

• Accept：要求返回XML但服务器只支持JSON
• Accept-Language：要求法语内容但只有英文版
• Accept-Encoding：指定了不支持的压缩格式

必须返回的信息：

• 响应头会列出服务器实际支持的内容（如 Content-Type: application/json）
• 可能附带说明文档链接

举个栗子：

API格式冲突：

• 请求头：Accept: application/xml
• 但API只支持JSON → 406 + 返回支持的类型

多语言网站：

• 请求头：Accept-Language: fr-CA（加拿大法语）
• 网站只有英语 → 406

版本控制：

• 请求：Accept: application/vnd.api+json; version=2
• 服务器只支持v1 → 406

407 Proxy Authentication Required【代理服务器的"关卡检查"】

用途：代理服务器要求客户端先认证身份才能转发请求

• 和401类似，但认证对象是代理服务器（不是目标服务器）
• 常见于企业网络/学校网络

必备响应头：

• Proxy-Authenticate：说明认证方式（如 Basic/Bearer）
• Proxy-Authorization：客户端后续请求需携带此头

典型场景：

• 公司VPN需要二次认证
• 学校网络登录认证
• 爬虫遇到需要密码的代理

举个栗子：

企业网络上网：

• 访问百度 → 弹出公司代理认证窗口
• 输入域账号密码后才能上网

API调用经过网关：

GET /api/data HTTP/1.1
Host: example.com

408 Request Timeout 【服务器的"耐心耗尽警告"】

触发条件：

• 客户端（浏览器/APP）开始发送请求但未完整发送
• 服务器在等待超时后主动断开连接（如Nginx默认60秒）

常见原因：

• 网络延迟导致TCP包传输中断
• 客户端上传大文件时卡死
• 恶意软件发送不完整请求攻击服务器

与其他超时的区别：

• 504：服务器处理超时（后端程序太慢）
• 408：客户端发送请求太慢（请求头发送不全/请求体传一半断了）

举个栗子：

上传文件失败：

• 传500MB视频到网盘，传到90%时断网 → 服务器等太久返回 408

弱网环境访问：

• 手机信号差，请求头发送不完整 → 408

服务器防御机制：

• 黑客故意慢速发送请求 → 服务器用 408 打断攻击

409 Conflict 【服务器的"交通警察"】

用途：服务器检测到请求与当前资源状态冲突，拒绝执行

• 不是语法错误（不是400）
• 不是权限问题（不是403）
• 是业务逻辑层面的冲突

常见冲突类型：

• 文件版本冲突（如Git合并冲突）
• 数据库乐观锁冲突（版本号不匹配）
• 资源依赖关系冲突（如删除有子分类的父分类）

必须返回的信息：

• 响应体应解释冲突细节（如 {"error": "File version 123 is stale"}）
• 可能包含解决建议的URL

举个栗子：

购物车冲突：

• 你下单时商品库存突然变为0 → 409 + "库存不足"

协同编辑：

• 两人同时保存文档 → 409 + 显示差异对比

银行转账：

• 账户余额被其他操作变更 → 409 + "请刷新重试"

410 Gone 【服务器的"死亡证明书"】

用途：服务器明确声明某个资源曾经存在，但现已永久删除

• 和404的区别：
• 404："从未见过这个资源"（可能输错URL）
• 410："这资源以前有，现在故意删除了"
• 和301的区别：
• 301：资源永久搬家
• 410：资源永久消失
• 410是HTTP协议中少数自带"情感色彩"的状态码，传达一种决绝的态度

设计意图：

• 告诉客户端别再来找这个资源了（搜索引擎会移除索引）
• 避免客户端反复重试请求

典型场景：

• 下架的新闻/商品
• 注销的用户主页
• 被GDPR要求删除的数据

举个栗子：

社交媒体：

• 访问已注销用户的个人主页 → 410 + "该账号已注销"

电商平台：

• 请求已下架三年的商品页面 → 410（而404可能意味着商品ID错误）

API版本：

• 废弃的API接口返回 410 + 替代方案链接

411 Length Required 【服务器的"电子秤"】

用途：服务器要求客户端必须提供请求体的明确长度

• 通过 Content-Length 请求头声明（如 Content-Length: 1024）
• 常见于需要严格校验数据的场景

触发条件：

• 客户端发送POST/PUT请求但缺失 Content-Length 头
• 服务器明确配置需要长度验证（如文件上传接口）

安全意义：

• 防止"慢速攻击"（黑客故意不传完整数据拖垮服务器）
• 确保大数据传输的完整性

举个栗子：

文件上传API：

POST /upload HTTP/1.1
Host: example.com
（缺失 Content-Length 头）

严格的后端服务：

• 任何非GET请求都必须带长度声明 → 否则 411

412 Precondition Failed 【服务器的"条件检测器"】

用途：服务器检测到客户端设置的条件不满足，拒绝执行请求

• 不是语法错误（不是400）
• 不是权限问题（不是403）
• 是"if-else"条件判断失败

常见前置条件：

• If-Match：要求资源版本号匹配（如ETag）
• If-Unmodified-Since：要求资源在指定时间后未修改
• If-None-Match：要求资源版本不同（用于缓存刷新）

设计初衷：

• 防止"丢失更新"问题（多人同时修改资源）
• 实现乐观锁机制

举个栗子：

在线文档协作：

• 你编辑文档前声明："只有版本号=123时才能保存"
• 但同事已先保存（版本变成124）→ 返回 412

支付系统：

• 转账请求要求："账户余额必须≥100元"
• 实际余额90元 → 412

413 Payload Too Large 【服务器的"体重秤"】

用途：服务器拒绝处理超过大小限制的请求数据

• 常见于文件上传、表单提交等场景
• 是服务器主动设置的安全防护

典型限制维度：

• 请求体总大小（如Nginx默认 client_max_body_size 1m）
• 单文件尺寸（如"头像不得超过2MB"）
• 数组元素数量（如"最多批量上传100个文件"）

与其他错误的区别：

• 400：数据格式错误
• 403：权限不足
• 413：数据体积超标

举个栗子：

网盘上传：

• 传500MB视频 → 服务器限制100MB → 413

表单提交：

• 提交含100张图片的表单 → 限制10张 → 413

API调用：

• 请求体JSON超过1MB → 413

414 URI Too Long 【服务器的"URL尺子"】

触发条件：

• 浏览器/APP发送的网址（URI）超过服务器限制
• 常见限制：
• Nginx默认 large_client_header_buffers 4 8k（单个URI头最多8KB）
• Apache默认约8000字符

典型问题场景：

• 过度冗长的GET参数（如?id=1&name=张三&age=20&...拼接100个字段）
• 前端错误生成的无限递归参数
• 恶意攻击者故意构造超长URL

安全意义：

• 防止缓冲区溢出攻击
• 避免服务器资源被超长URL耗尽

举个栗子：

错误的分页查询：

GET /api/data?page=1&size=10&sort=name&filter=type=news&search=2023年最新...（2000字符后截断）

返回 414

前端bug：

• 错误循环拼接参数生成如 ?param=1&param=1&param=1... 的无限长URL

爬虫攻击：

• 黑客发送10万字符的URL试探服务器漏洞

415 Unsupported Media Type 【服务器的"格式审查员"】

用途：服务器拒绝处理不支持的请求格式

• 客户端通过 Content-Type 头声明了服务器无法处理的格式
• 是严格的格式校验错误

常见冲突场景：

• 用 application/xml 调用只支持JSON的API
• 上传 .exe 文件到仅允许图片的接口
• 忘记设置 Content-Type 头（可能被默认当作错误类型）

必须返回的信息：

• 响应头应包含 Accept 字段，列出支持的格式（如 Accept: application/json）

举个栗子：

API调用错误：

返回 415 + Accept: application/json

图片上传限制：

• 上传 .mp4 到头像接口 → 415 + "仅支持JPEG/PNG"

416 Range Not Satisfiable 【服务器的"范围校正器"】

用途：服务器告知客户端请求的文件范围超出实际大小

• 发生在断点续传或分片下载时
• 客户端通过 Range 头指定了非法范围（如 bytes=500-1000，但文件只有300字节）

必备响应头：

• Content-Range：显示文件实际大小（如 Content-Range: bytes */300）

常见触发原因：

• 文件被截断或缩小，但客户端不知道
• 客户端错误计算了范围
• 恶意攻击者故意发送非法范围请求

举个栗子：

视频加载失败：

• 请求："给我这个视频500MB-1GB的部分"
• 但视频总共只有400MB → 416

下载管理器错误：

• 网络中断后，错误计算了剩余下载范围

417 Expectation Failed 【服务器的"需求驳回函"】

用途：服务器无法满足客户端在 Expect 请求头中提出的特定要求

• 客户端预先声明："必须满足XX条件我才继续请求"
• 服务器检查后表示："做不到，请停止后续操作"

经典场景：

• Expect: 100-continue（客户端问："能接收大文件吗？"）
• → 服务器返回 417 表示："别传了，我拒绝"
• 自定义扩展要求（如特殊加密算法支持）

与其他状态码的区别：

• 400：通用请求错误
• 412：前置条件不满足（针对资源状态）
• 417：明确拒绝客户端的Expect要求

举个栗子：

大文件上传被拒：

特殊需求不被支持：

418 I'm a teapot 【互联网的"幽默拒签条"】

起源：1998年愚人节的恶搞RFC文档（RFC 2324）

• 源自"超文本咖啡壶控制协议"（HTCPCP）的玩笑
• 官方用途：拒绝用茶壶煮咖啡的荒谬请求

实际意义：

• 专门用来优雅地拒绝明显不合理的请求
• 相当于程序的幽默版："你这请求太离谱了"

意外走红：

• 被Python、Node.js等框架实际实现
• 成为程序员群体中的文化符号

举个栗子：

API的彩蛋响应：

• 返回 418 + { "message": "我是茶壶，不能自毁" }

机器人防护：

• 对明显恶意的爬虫请求返回418（比403更幽默）

程序员节日彩蛋：

• 在愚人节把部分404页面替换成418

420 Enhance your calm【互联网的"电子佛珠"】

出身：

• 非官方状态码，源自Twitter早期API的限流响应
• 灵感来自电影《蠢蛋进化论》的经典台词

实际作用：

• 优雅版429（Too Many Requests）
• 用幽默方式提醒用户/开发者操作过于频繁

文化意义：

• 程序员对"暴力请求"的温柔反击
• 比冷冰冰的"请求被拒"更有人情味

举个栗子：

API限流：

HTTP/1.1 420 Enhance Your Calm
Retry-After: 30
{
  "message": "放松呼吸30秒再试",
  "tip": "试试冥想APP Headspace"
}

游戏防沉迷：

• 连续玩2小时后触发420 + 熊猫打坐动画

程序员彩蛋：

• 在代码注释里藏420梗（比如 // 这里本应该429，但我们更禅意）

421 Misdirected Request 【服务器的"导航纠错"】

用途：服务器告知客户端请求发错了地方

• 常见于HTTP/2和HTTP/3的多路复用场景
• 服务器无法用当前连接响应请求，必须重建连接

核心原因：

• 客户端在同一个TCP连接中发送了不属于该服务器的请求
• 服务器配置变更（如证书域名不匹配）
• 负载均衡器将请求导向了错误的服务器实例

必备响应头：

• Connection: close（强制关闭当前错误连接）

举个栗子：

网站迁移后：

• 浏览器复用旧连接访问新域名 → 421 + "请用新连接访问"

微服务架构：

• 请求误发到未部署该API的容器 → 421

CDN边缘节点错误：

• 请求被路由到没有对应内容的CDN节点

422 Unprocessable Entity 【服务器的"逻辑审查员"】

用途：服务器表示："请求格式正确，但内容逻辑有问题"

• 介于400（语法错误）和409（业务冲突）之间
• 常见于WebDAV和REST API的校验错误

典型问题：

• 日期格式合法但超出范围（如"生日：3023年"）
• 数值越界（如"年龄：-10岁"）
• 依赖关系错误（如"所属部门ID不存在"）

必须返回的信息：

• 响应体应详细说明每个字段的错误（RFC 4918标准）

{
  "error": "验证失败",
  "details": {
    "birthday": "不能是未来日期",
    "department_id": "该部门不存在"
  }
}

举个栗子：

注册表单：

• 密码填"123" → 422 + "密码至少6位"

电商下单：

• 商品ID存在但库存不足 → 422（而404是ID不存在）

日历系统：

• 创建结束时间早于开始时间的会议 → 422

423 Locked 【服务器的"资源门禁"】

用途：服务器声明资源已被显式锁定，禁止并发修改

• 常见于WebDAV协议（网络文件管理）
• 防止多人同时修改导致数据冲突

锁定类型：

• 独占锁：只允许锁定者操作（如文档编辑）
• 共享锁：允许多个读取，禁止写入（如数据库读锁）

必备响应头：

• Lock-Token：标识当前锁的ID
• 可能包含解锁时间（如 Timeout: Infinite）

举个栗子：

云文档协作：

• 用户A编辑PPT时 → 文件被锁定
• 用户B尝试保存 → 423 + "该文件正在被A编辑"

版本控制系统：

• Git提交冲突时可能返回423

数据库运维：

• 执行备份时锁定表 → 其他写入请求返回423

424 Failed Dependency 【服务器的"多米诺骨牌警报"】

用途：服务器表示当前操作依赖的其他操作失败了

• 专为WebDAV协议设计（多步骤操作场景）
• 不是语法错误（不是400），而是流程中断

典型场景：

• 批量删除文件时，某个文件被锁定导致整体失败
• 事务处理中某一步骤失败（如付款成功但库存不足）
• 跨服务调用时依赖的API不可用

必须返回的信息：

• 响应体应说明具体失败的依赖项

<!-- WebDAV示例 -->
<error>
  <failed-dependency>/files/important.doc</failed-dependency>
  <reason>File is locked</reason>
</error>

举个栗子：

云盘批量操作：

• 删除10个文件 → 其中1个被锁定 → 424 + 列表显示失败项

电商下单流程：

• 扣款成功 → 库存系统故障 → 424 回滚整个订单

CI/CD流水线：

• 编译成功 → 测试阶段失败 → 中止部署并返回424

425 Too Early 【服务器的"安全守门员"】

用途：服务器拒绝处理可能引发重放攻击的过早请求

• 专为防御 "0-RTT"（零往返时间） 攻击设计
• 常见于HTTP/3和TLS 1.3的早期数据场景

核心机制：

• 客户端尝试用缓存密钥发送加密请求（节省时间）
• 服务器发现风险："上次会话的密钥可能已泄露" → 返回425
• 强制客户端走完整握手流程

安全意义：

• 防止黑客截获早期数据包伪造请求
• 保护敏感操作（如支付、登录）

举个栗子：

网购支付：

• 你快速点击支付按钮（尝试复用上次会话）
• 银行服务器返回 425："请重新输入短信验证码"

游戏登录：

• 客户端自动重连时发送早期数据 → 服务器要求完整握手

426 Upgrade Required【服务器的"技术淘汰通知"】

用途：服务器强制要求客户端升级协议版本

• 不是建议，而是必须升级才能继续访问
• 常见于淘汰旧协议的安全场景

核心机制：

• 通过 Upgrade 响应头指明所需协议（如 Upgrade: TLS/1.3）
• 客户端必须支持新协议才能重试请求

典型场景：

• 网站从HTTP强制升级到HTTPS
• API废弃HTTP/1.1，要求使用HTTP/2
• 禁用老旧加密算法（如RC4）

举个栗子：

浏览器访问：

GET / HTTP/1.1
Host: example.com

APP接口调用：

• 使用已淘汰的API版本 → 426 + "请升级到v2.0"

428 Precondition Required 【服务器的"安全关卡"】

用途：服务器要求客户端必须携带校验条件才能处理请求

• 不是权限问题（不是401/403）
• 是强制性的流程控制机制

常见前置条件：

• If-Match：要求资源版本匹配（防覆盖）
• If-None-Match：要求资源已变更（防重复）
• 自定义条件（如必须携带交易令牌）

安全价值：

• 防止丢失更新（Lost Update）问题
• 确保幂等性操作安全

举个栗子：

在线文档保存：

• 直接提交修改 → 428 + "请携带文档当前ETag"

支付系统：

• 请求扣款 → 428 + "需提供短信验证码"

API设计：

• 要求所有写请求必须带 X-Idempotency-Key 头

429 Too Many Requests 【服务器的"流量警察"】

用途：服务器温柔地警告客户端请求频率超标了

• 不是错误，而是限流保护
• 防止恶意刷接口或意外流量风暴

核心机制：

• 通过 Retry-After 头告知冷却时间（如 Retry-After: 30）
• 可能配合令牌桶/漏桶等算法

常见触发场景：

• 爬虫抓取太快
• 用户反复刷新页面
• API被暴力破解尝试

举个栗子：

登录失败限流：

• 连续输错5次密码 → 429 + "请1分钟后再试"

抢购活动：

• 每秒发起10次下单请求 → 429 + "当前排队人数过多"

免费API限制：

• 超过每分钟100次调用 → 429

430 Would Block 【网络的"智能交通系统"】

非官方实验性状态码

• 由HTTP扩展提案提出，尚未成为正式标准
• 目前主要用于QUIC协议（HTTP/3的底层协议）

核心作用：

• 预先警告客户端继续当前操作会导致阻塞
• 比429（限流）更前瞻性的流量控制

举个栗子：

视频流预判缓冲：

• 客户端带宽下降时，服务器预警："继续高清传输会卡顿" → 自动降为标清

游戏同步：

• 服务器预测玩家操作过快 → 返回430让客户端节流

物联网控制：

• 设备指令队列积压时，提前拒绝新请求

431 Request Header Fields Too Large 【服务器的"头信息体重秤】

触发条件：

• 请求头（Headers）总大小超过服务器限制
• 常见限制：
• Nginx默认 large_client_header_buffers 4 8k（单个头最大8KB）
• Apache默认约8000字节

典型问题：

• Cookie太大（如存了MB级数据）
• 自定义头过多（如X-User-Info携带完整用户数据）
• 恶意攻击者故意构造超大请求头

安全意义：

• 防止缓冲区溢出攻击
• 避免服务器内存被垃圾头信息耗尽

举个栗子：

Cookie爆炸：

• 返回 431

过度追踪：

• 前端添加几十个X-Tracking-*头 → 触发限制

代理服务器错误：

• 多层代理不断添加Via头 → 最终超限

451 Unavailable For Legal Reasons 【互联网的"封条"】

用途：服务器依法拒绝提供某些内容

• 不是技术限制（不是404/403）
• 是明确的法定内容封锁

必须包含的信息：

• 响应头/页面上应注明法律依据（如 X-Censorship-Reason: DMCA）
• 可能附带申诉渠道（如版权投诉邮箱）

名字彩蛋：

• 致敬反乌托邦小说《华氏451》（书中焚烧禁书）
• 2015年正式成为RFC标准

举个栗子：

版权投诉：

• 访问盗版电影链接 → 451 + "应版权方要求移除"

地区封锁：

• 在欧盟访问某网站 → 451 + "因GDPR限制不可用"

政府审查：

• 某些国家访问维基百科 → 451 + "根据XX法规屏蔽"

Server Error 5xx

500 Internal Server Error 【服务器的"故障烟雾弹"】

用途：服务器承认"我炸了，但不知道具体哪炸了"

• 不是客户端的问题（不是4xx）
• 是服务器未处理的意外错误

经典翻车现场：

• 代码有bug（比如除以零）
• 数据库连接突然断开
• 配置文件写错了
• 内存泄漏把服务器撑爆

尴尬特点：

• 最让开发者头疼的状态码（因为缺乏具体信息）
• 用户看到的是"500"，但日志里可能藏着100种不同错误

举个栗子：

网站崩溃：

• 访问首页 → 突然白屏显示"500 Internal Server Error"

API抽风：

• 调用 /api/users → 返回 500（后端代码抛异常没捕获）

运维事故：

• 服务器磁盘满了 → 所有请求开始500

501 Not Implemented 【服务器的"诚实三连"】

用途：服务器坦白承认"这个功能我压根没做"

• 不是临时故障（不是503）
• 不是权限问题（不是403）
• 是永久性功能缺失

典型场景：

• 调用了未开发的API端点
• 使用了服务器不支持的HTTP方法（如对普通接口发PATCH请求）
• 请求了配置文件中禁用的功能模块

与500的区别：

• 500："我尝试做了但失败了"
• 501："这需求我根本不会做

举个栗子：

API版本过新：

• 请求 GET /api/v3/users → 501（服务器只实现到v2）

特殊操作：

• 发送 PURGE /cache 请求 → 501（未启用缓存清理功能）

超前功能：

• 调用"AI生成菜谱"接口 → 501（该功能尚在PPT阶段）

502 Bad Gateway 【互联网的"传话事故"】

角色定位：

• 由网关/代理服务器（如Nginx、Cloudflare）返回
• 表示："我（网关）是好的，但我后面的小弟（应用服务器）挂了"

经典故障链：

• 用户 → CDN → 负载均衡 → 应用服务器（崩在这里）
• 负载均衡器发现应用服务器无响应 → 向用户返回502

常见凶手：

• 应用进程崩溃（如PHP-FPM、Node.js服务停止）
• 数据库连不上导致服务不可用
• 防火墙错误拦截了内部通信

举个栗子：

网站访问：

• 浏览器 → Cloudflare（502）← 你的服务器（崩溃中）

微服务调用：

• API网关 → 用户服务（超时无响应）→ 返回502

运维事故：

• 误删了Docker容器 → Nginx返回502

故障排查指南：

1. 检查应用服务器进程是否存活（ps aux | grep node）
2. 查看应用日志（如 tail -f /var/log/nginx/error.log）
3. 测试内部网络（curl -v http://localhost:3000）
4. 检查数据库连接（mysql -u root -p）
5. 监控系统资源（htop看CPU/内存）

503 Service Unavailable 【服务器的"休假公告"】

核心特征：服务器主动声明"我现在不能服务，但还会回来"

• 不是崩溃（不是500）
• 不是网关问题（不是502）
• 是计划内的不可用状态

常见触发场景：

• 系统维护升级
• 流量暴增触发限流
• 依赖的第三方服务故障

友好设计：

• 通常伴随 Retry-After 头（如 Retry-After: 3600）
• 可能展示精心设计的维护页面

举个栗子：

网站维护：

• 访问淘宝 → 显示"系统升级中，预计23:00恢复"

API限流：

• 免费用户频繁调用 → 503 + "请1小时后重试"

云服务故障：

• AWS某个区域宕机 → 所有托管服务返回503

504 Gateway Timeout 【互联网的"耐心终结者"】

角色定位：

• 由网关/代理服务器（如Nginx、API网关）返回
• 表示："我（网关）还在，但后面服务太久没理我"

典型超时场景：

• 应用服务器卡死（死循环/死锁）
• 数据库查询太久（没加索引的百万级表扫描）
• 微服务之间调用链超时（A等B，B等C...）

关键数字：

• Nginx默认代理超时：60秒
• AWS ALB默认：120秒

举个栗子：

网站访问：

• 浏览器 → CDN（504）← 你的服务器（SQL查询跑了3分钟）

支付接口：

• 调用银行网关超时 → 返回504

运维事故：

• 服务器CPU爆满 → 所有请求超时

505 HTTP Version Not Supported 【服务器的"协议门神"】

核心问题：服务器明确拒绝客户端使用的HTTP协议版本

• 不是兼容性降级（不会自动切到低版本）
• 是硬性阻断（"要么升级要么滚"）

常见冲突组合：

• 客户端用HTTP/2 → 古董服务器只支持HTTP/1.0
• 激进客户端用HTTP/3 → 中间代理不支持QUIC

安全考量：

• 防止老旧协议的安全漏洞被利用
• 强制淘汰不安全的加密方式

举个栗子：

企业内网设备：

• 新浏览器用HTTP/2访问老OA系统 → 505

API网关配置：

• 强制要求HTTP/2 → 旧版APP发HTTP/1.1请求被拒

黑客试探：

• 故意发送HTTP/9.9请求 → 服务器返回505

506 Variant Also Negotiates 【服务器的"选择困难症发作"】

用途：服务器发现内容协商陷入死循环

• 当资源的不同版本（变体）自己还需要进一步协商时触发
• 属于WebDAV协议的特殊错误

典型故障链：

• 客户端请求资源 → 服务器提供多个变体（如英文/中文版）
• 但某个变体（如中文版）自己又有子版本（简/繁体）
• 服务器懵逼："我该给你简体还是繁体？" → 返回506

本质问题：

• 多层嵌套的内容协商（像俄罗斯套娃）
• 服务器配置错误导致无限递归

举个栗子：

国际化网站故障：

• 请求 /doc → 可选英文/中文 → 选择中文 → 中文版又需要选简/繁体 → 506

版本控制API：

• /api/v2 需要进一步选择 v2.1 或 v2.2 → 协商失败

507 Insufficient Storage 【服务器的"硬盘求救信号"】

用途：服务器明确表示"我的硬盘/内存不够存你的东西了"

• 专为WebDAV协议设计（网络文件管理）
• 不是临时故障（不是503），是物理容量极限

常见场景：

• 云盘上传文件时空间爆满
• 数据库磁盘写满导致写入失败
• 服务器日志占满存储空间

必备响应头：

• X-Disk-Space-Available: 1024（剩余字节数）
• 可能包含清理建议（如删除路径 /old_backups/）

举个栗子：

网盘上传失败：

• 传50GB视频 → 507 + "剩余空间仅30GB"

邮件系统崩溃：

• 收件箱超过配额 → 新邮件被拒

运维事故：

• 监控日志未轮转 → 塞满硬盘 → 所有写操作507

508 Loop Detected 【服务器的"循环终结者"】

用途：服务器检测到请求处理陷入死循环

• 专为WebDAV协议设计（网络文件管理）
• 不是代码bug（不是500），是逻辑依赖成环

典型循环场景：

• 文件A的元数据指向文件B → 文件B又指回文件A
• 符号链接（快捷方式）循环引用
• 无限递归的API调用链

安全机制：

• 防止恶意构造的循环请求耗尽服务器资源
• 比超时错误（504）更主动的防御

举个栗子：

网站目录结构错误：

• /photos/2023 链接到 /archive → /archive 又链接回 /photos → 508

微服务调用死循环：

• 服务A → 调用服务B → 服务B又回调服务A

运维配置事故：

• DNS记录把 a.example.com CNAME到 b.example.com → 结果 b 又指向 a

510 Not Extended 【服务器的"功能解锁提示"】

用途：服务器要求客户端必须支持扩展功能才能继续

• 源自1999年RFC 2774的实验性协议
• 表示："基础功能不够用，得开高级权限"

核心条件：

• 请求需包含 MUST 扩展声明
• 服务器在响应中通过 Extension 头说明要求

现代应用：

• 企业级API的许可证控制
• 硬件设备的功能解锁

举个栗子：

企业软件API：

GET /api/advanced-analytics
→ 返回510 + "需购买高级许可证"

智能家居控制：

• 普通APP调烤箱高级模式 → 510
• 需安装厂商插件才能继续

511 Network Authentication Required 【网络的"门禁系统"】

用途：强制用户在使用网络前先认证

• 不是网站权限问题（不是401）
• 是网络接入层的拦截

必备要素：

• 必须重定向到认证页（如 Location: http://auth.wifi.com）
• 响应头包含 Network: WiFi 等网络类型标识

常见触发点：

• 酒店/机场的付费Wi-Fi
• 企业内网准入控制
• 学校宿舍的按时断网

举个栗子：

星巴克Wi-Fi：

• 连接后所有网页跳转登录页 → 底层返回 511

公司VPN：

• 未安装安全证书的设备访问内网 → 强制跳转安装页

家长控制：

• 儿童设备上网前需家长授权