先说一个我自己的经历。早些年排查一个下载服务故障，用户反馈大文件下载到一半总损坏，抓包一看，服务器对Range: bytes=1024-这段请求直接回了200 OK，而且把整个文件当响应体发了出来。下载工具倒是没报错，但文件拼接出来就是坏的。类似这种问题，根子不在代码逻辑，而在对 2xx 成功类状态码的语义理解不够细。HTTP 状态码是客户端与服务器之间的通信语言，2xx 这个家族远不是"成功"两个字能概括的。这篇是 HTTP 状态码系列的第二篇，专门把 2xx 家族拎出来挨个拆开，适合后端开发、客户端开发、测试和运维同学参考，看完你至少能避开大部分我在线上踩过的同款坑。

1. 2xx 家族整体认知：为什么"成功"还要分这么多种

1.1 状态码第一位数字在传递什么

HTTP 状态码的第一位数字决定了响应的类别。2xx 表示客户端发起的请求已经被服务器接收、理解并处理，但这只是最基本的定义。真正关键的是，"处理成功"在 HTTP 语义里有多重形态：服务器成功执了操作，和服务器成功接收了操作，是两个完全不同的概念。

我习惯用一个餐厅场景来类比。你去点菜，服务员的"成功"应答可能有几种：菜已经做好端上桌了，这是 200；后厨接单了但还没开始炒，这是 202；你是自助餐，根本不需要服务员端菜，他只需要确认你可以去取餐了，这是 204；你点了一个需要现烤的大份披萨，服务员先给你确认了订单但还没付款完成，这也是一种状态。状态码就是这类"应答语义"的标准化表达。

之所以要区分这么细，是因为状态码本质上是写给客户端程序看的指令，不是给人看的文本。客户端收到一个状态码后，会据此决定下一步动作：是解析响应体里的数据，还是去轮询任务状态，还是直接保持当前界面不动，甚至再发起一个带 Range 头的分段请求。如果响应语义不精确，客户端的后续动作就会出错——就像那个下载损坏的例子，工具收到 200 就以为拿到了完整资源。

1.2 客户端视角与服务器视角的语义偏差

同一个请求，服务器认为"已经处理"，和客户端认为"任务完成"，经常不是一回事。202 Accepted 是最典型的例子：服务器接受了请求，但任务还挂在队列里。这时候如果客户端不做轮询或回调处理，直接按"请求完成"对待，就会把未完成的结果当最终结果用。

反过来，客户端也可能误判服务器的意图。一个很常见的场景是：后端处理完一个删除操作，返回了 200 并带着一个 JSON 对象，前端以为要展示这段数据，其实后端只是习惯性把所有响应都包成 200+data，并没有呼应删除这个语义。服务器想表达的是"删完了，列表页可以刷新了"，客户端却把 data 当成新页面内容渲染，结果界面出现一个空对象。

所以，理解 2xx 家族的切入点，应该是"这个状态码能指导客户端做出哪一步具体动作"。后面每一节我都会沿着这个思路展开：这个状态码的完整语义是什么、什么时候该用、用错了会出现什么现象。

2. 200/201/204：日常开发中最常用的三个 2xx

2.1 200 OK：默认成功，但含义比你想象的窄

200 OK 是 HTTP 协议里最通用的成功响应。它表示请求成功，并且响应体中携带了客户端要求的数据。对于 GET 请求，200 的语义是"返回了目标资源的表示"；对于 POST、PUT 这类操作请求，200 通常表示"操作执行成功，并返回了操作结果的表示"。

但 200 实际上不区分"资源存在"和"操作完成"这两个维度。一个 GET 查询返回空数组，状态码照样是 200——状态码只负责响应语义，不负责业务层面的"有没有数据"。很多刚接触 HTTP 的同学会把 200 和"有数据"绑定，导致前端代码里写data.length === 0时才发现空数据本来就是合法情况，那时已经因为状态码判断写得过于简单，把整个响应塞进了一个"非空"分支。

从协议细节上看，200 有几点值得注意：

• 在 HEAD 请求中，服务器返回的响应头与 GET 一致，但没有响应体。前端用 Content-Length 判断资源大小时，拿到的是 HEAD 的状态码 200 和头信息，不能误以为有 body。
• 在持久连接（keep-alive）场景下，200 响应如果没有正确设置 Content-Length 或 Transfer-Encoding，客户端会一直等不到响应结束，表现就是接口超时。
• 当多个请求复用同一个连接时，HTTP/1.1 的管线化和队头阻塞问题也会在这里暴露——这也是为什么 http 连接复用 的话题经常和状态码一起被讨论。

一个比较简单直观的报文长这样：

HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Content-Length: 59 Cache-Control: no-cache {"user_id":1001,"name":"Ada","role":"admin","status":"active"}

有一点需要提醒：现在很多团队在 HTTP 层习惯统一返回 200，把真正的业务状态放在响应体的 code 字段里。这种模式有它的适应场景，我会在第五部分单独讲，但至少你心里要清楚，200 是一个宽口径的成功信号，客户端不能对它背后的业务结果做太多假设。

2.2 201 Created：明确告诉客户端"新资源已创建"

201 Created 的语义比 200 精确得多：不只是"请求处理成功"，而是"服务器已经创建了一个新资源"。它最常出现在 POST 创建接口、PUT 完整替换创建资源等场景。

和 201 强绑定的是 Location 响应头。RFC 规定，服务器应当在响应中通过 Location 头指向新创建资源的 URI。这个头对客户端来说是后续操作的关键：前端只有拿到 Location，才能继续刷新详情页或列表页。

我见过很多团队在实际开发里不设置 Location，而是把新资源的 id 放进响应体：

HTTP/1.1 201 Created Content-Type: application/json; charset=utf-8 {"id":128,"name":"Ada","created_at":"2025-01-01T10:00:00Z"}

这种写法不能说错，但协议的完整表达应该是：

HTTP/1.1 201 Created Location: /api/users/128 Content-Type: application/json; charset=utf-8 {"id":128,"name":"Ada","created_at":"2025-01-01T10:00:00Z"}

实践里的坑主要集中在这两点：

1. 创建接口返回 201，但 Location 与后续 GET 查到的资源 URI 不一致，导致客户端跳转详情页时 404。
2. POST 创建成功后返回 200 而不是 201。虽然不致命，但客户端无法通过状态码区分"这次 POST 是新建"还是"更新了一个已有对象"，如果前端正好有一个"表单既可用于新增也可用于编辑"的页面，逻辑会绕很多。

另外一个容易被忽略的场景是异步创建。如果资源不是在请求处理过程内完成创建的，而是先进入了一个任务队列，比如"提交视频后先转码再上架"，那不应该使用 201。201 表示创建动作已经真实发生，异步场景应该回 202 Accepted，下面一节会展开。

2.3 204 No Content：成功，但什么都不用返回

204 No Content 是 2xx 家族里容易被忽视但实际价值很高的一个。它的语义是：服务器成功处理了请求，但响应体为空，客户端应当保持当前页面的展示不变。

这几种场景我会优先选择 204：

• DELETE 删除资源成功，前端只需要把列表里的那一项移除，不需要任何返回体。
• PUT/PATCH 保存成功，但页面视图没有变化，不需要重新渲染。
• Webhook 回调确认、消息确认通知，接收方只需要知道"收到并处理了"。

204 的关键约束是不能包含任何响应体。如果服务器设置了 Content-Length，它必须是 0；如果错误地在 204 里塞了 body，一些 HTTP 库会直接在解析阶段报连接错误，这个现象在抓包时看起来像"服务端异常 close 了连接"，相当迷惑。

我曾经遇到过一个问题：后端在 DELETE 接口里返回了 204，但为了"省一次查询"又在响应体里塞了一段提示文本。结果客户端用的是某主流 HTTP 库，它在收到 Content-Length 大于 0 的 204 时会拒绝返回 body，前端 PC 浏览器直接白屏。排查到最后发现，后端只删除了一行 return，前端却把所有状态码为 2xx 且非 204 的分支都检查了一遍。

204 和 200 的选择，我的经验是：需要展示返回数据，用 200；不需要任何数据，用 204；保险起见，还需要给"状态码和业务结果"不一致的场景留出回退逻辑。

2.4 201、200、204 的选择口诀

做后端久了你会发现，接口设计阶段最省事的做法就是把所有成功都写成 200。但一旦接口数量膨胀到几十上百个，客户端就需要在好几个 "if (code === 200)" 里做各种特判。与其这样，不如在设计时按语义顺手选好：

• 需要新资源 URI 给客户端做下一步动作，选 201 + Location。
• 需要完整的数据体参与页面渲染或业务判断，选 200。
• 操作成功，但客户端不需要任何返回体，选 204。

这个口诀看起来简单，但坚持执行能省掉大量联调成本。尤其是你在维护一套长期演进的 API 时，状态码本身就是文档。

3. 202/203/205/206：从"延迟处理"到"部分内容"

3.1 202 Accepted：请求被接受，但活还没干完

202 Accepted 表示服务器已经接受了请求，理解了语义，但处理尚未完成。最终执行结果可能成功也可能失败，服务器会在后续某个时间点真正完成任务。

这是异步任务场景的标准状态码：AI 生成、报表导出、批量邮件、视频转码、文件压缩、消息队列的生产端，都适合在接单后立即返回 202。

它的标准用法是：在响应里提供一个任务标识和查询地址。常见两种实现：

HTTP/1.1 202 Accepted Location: /api/tasks/128 {"task_id":128,"status":"queued","created_at":"2025-01-01T10:00:00Z"}

或者：

HTTP/1.1 202 Accepted Content-Type: application/json; charset=utf-8 {"task_id":128,"query_url":"/api/tasks/128","status":"queued"}

客户端拿到 202 后，应当通过 GET 查询任务状态，直到返回 200（成功）或 4xx/5xx（失败）。我见过一个相对典型的错误：异步任务接口直接返回 200，并把"任务详情"放到响应体里，客户端据此认为"任务已经完成"，直接读取结果字段，结果拿到的是status: pending。这种接口设计让调用方非常被动，因为无法通过状态码判断是否需要继续轮询。

202 的应用要克制。它只代表"接收了请求"，不等于"已经在处理中"。如果服务器明明可以同步完成，却为了接口格式统一强行返回 202，只会逼着客户端多写一套轮询逻辑，纯属自找麻烦。

3.2 203 Non-Authoritative Information：代理的"加工"声明

203 Non-Authoritative Information 的定义是：返回的信息不是来自源服务器，而是由本地或第三方代理对源响应做了修改或转换。

这个状态码在浏览器里几乎看不到，因为代理更习惯把改写后的响应继续标成 200。但 203 对响应链路中间的自我保护是有意义的：当一个代理缓存或转换了资源表示，明确返回 203，能避免下游把"加工后的结果"误当成源服务器的权威版本。

举个例子：你在源服务器配置了 gzip 压缩，Nginx 作为反向代理时可能会把上游响应解压后再压缩成另一种编码，或者在 HTML 里插入统计脚本。如果代理只是默默改完数据还返回 200，源服务器和客户端都会以为这个响应是源站原样生成的。如果代理返回 203，客户端和缓存节点至少知道，这份内容不是权威的源版本，决策时会更谨慎。

对普通开发者的实操价值在于排查问题：如果你在调试环境里看到的响应全是 200，但表现异常，不妨看看响应头里的 via、X-Cache 这类字段。如果确实有中间层参与，可以把产物和源站直接对比，很多"数据被莫名改动"的问题，根因就在代理层。

3.3 205 Reset Content：让文档视图回到初始状态

205 Reset Content 和 204 非常接近，差别只有一点：它要求客户端在收到响应后，清空当前文档视图的表单输入，重置回初始状态。

这个语义在 HTML 表单场景中最直观：一个连续录入的页面，提交成功后返回 205，浏览器会自动把表单字段清空，方便录入下一条。在线答题、库存盘点、工单登记这类"一行一条、连续提交"的工具型页面，用 205 能省掉前端手动 reset 的代码。

不过实操中要小心两点：一是很多浏览器对 205 的实现并不一致，有的会重置表单，有的会重新加载整个文档；二是如果你的前端是 SPA，表单状态可能完全由 JavaScript 管理，浏览器根本不会干涉。所以我个人的习惯是：业务上确实需要"重置视图"这个动作时，不要赌浏览器的 205 支持，直接在前端代码里显式 reset。205 更好保留为协议层面的一种语义声明，而不是业务依赖。

3.4 206 Partial Content：分片传输的基石

206 Partial Content 是 Range 请求的响应，客户端只请求资源的一部分，服务器只返回这一部分。它是流媒体播放、断点续传、分片下载、PDF 分页预览的基础。

完整交互流程是这样的：

1. 客户端发起带 Range 的请求：Range: bytes=0-1023
2. 服务器返回 206，并携带：
   • Content-Range: bytes 0-1023/5000，说明当前分片范围和资源总大小
   • Content-Length: 1024，说明本次返回的实际字节数
   • Accept-Ranges: bytes，声明服务器支持范围请求
3. 客户端可以根据需求继续发起下一个分段请求，也可以使用多段 Range（如bytes=0-99,200-299），此时服务器需要用multipart/byteranges格式返回。

一个基础的单段响应报文：

HTTP/1.1 206 Partial Content Content-Range: bytes 1024-2047/10240 Content-Length: 1024 Accept-Ranges: bytes Content-Type: video/mp4

这里最常踩的坑就是 Content-Length 写错。很多新手在处理分片时，把整个资源的大小当成了本次响应的 Content-Length，结果客户端按分片长度拼文件时，文件总是比预期多出一截或者提前截断，表现出来就是"下载的文件大小正确，但播放到某个位置就花屏、卡死"。

另一个坑是单段范围和多段范围的处理。如果服务端没有实现 multipart/byteranges，遇到多段 Range 时不该硬撑，直接返回 200 全量也是一种合规的降级策略。绝大多数的下载工具和浏览器都能兼容这种降级。

26 里还有一个细节：当客户端请求的是最后的字节Range: bytes=1024-，服务器要知道这是"从第 1024 字节到最后"的意思；如果请求的结束位置超出资源大小，服务器可以只返回实际存在的部分，并把 Content-Range 写成bytes 1024-4999/5000这种样子。这些边界处理如果没做对，断点续传就会在"续传后半段"时反复失败。

我在维护对象存储网关时，早期没实现 Range，只要下载工具一发起分段请求，服务端就返回 200 全量，小文件没问题，大文件在弱网场景下经常中断重来。后来按照 206 和 Content-Range 的规范补齐逻辑，这类问题基本绝迹。

4. 207/208/226：相对小众但协议意义完整的扩展状态码

4.1 207 Multi-Status：一个请求里带多个子状态

207 Multi-Status 来自 WebDAV 扩展，定义在 RFC 4918。它用于当一个请求作用于多个资源时，在响应体里用 XML 描述每个资源各自的状态码。

典型的场景是 PROPFIND 批量查询文件属性、LOCK/UNLOCK 涉及多个锁目标。响应体里每个子资源可以有自己的 HTTP 状态码，不只是 2xx，也会出现 404、403 等。

一个示意报文：

HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" <?xml version="1.0" encoding="utf-8" ?> <d:multistatus xmlns:d="DAV:"> <d:response> <d:href>/files/a.txt</d:href> <d:status>HTTP/1.1 200 OK</d:status> </d:response> <d:response> <d:href>/files/missing.txt</d:href> <d:status>HTTP/1.1 404 Not Found</d:status> </d:response> </d:multistatus>

客户端在解析 207 时必须走到 XML 文本里逐个读取子状态码，只看最外层 207 是不够的。如果前端做批量文件管理，接收到 207 后要逐个把 href 和 status 对应起来，再针对每个文件的状态做不同提示。

4.2 208 Already Reported：避免同一个资源被重复报告

208 Already Reported 同样来自 RFC 4918，是 207 的补充。当同一个资源通过多个绑定映射到不同 URI 时，如果前面已经报告过这个资源，后续再遇到就可以用 208 表示"我已经报过了，不用再处理了"。

这个状态码在普通 Web API 里几乎用不到，但对实现文件系统类 WebDAV 服务有价值：当一个目录下有多个硬链接或符号链接指向同一个文件，遍历时如果不做去重，客户端会看到同一资源报告多次，UI 上出现重复条目。

对我们普通开发者的启发是：如果你在设计批量查询接口，也可以吸收这个思路——已经返回过的资源对象，在列表后续位置用"引用指向"的方式表示，避免客户端去重逻辑在数据量大时崩溃。

4.3 226 IM Used：增量编码响应

226 IM Used 定义在 RFC 3229，用于 Delta Encoding（增量编码）场景。服务器响应的不是完整资源，而是对某个实例操作后的结果；客户端已经持有资源的历史版本，服务器只需要返回差异部分。

类比来说，就是"客户端说：我手上已有 v1 版本的 JSON，服务器说：好的，我从 v1 到 v2 的改动就是这些字段，你打一个补丁就行"。这样可以大幅减少带宽传输。

这个状态码在实际生产环境里极少被显式使用。CDN 边缘节点偶尔会用类似的增量算法，但一般不会把 226 暴露给客户端。但我们仍然要知道它的存在：万一哪天你在抓包里看到了 226，第一反应应该是"响应体不是完整资源，而是增量补丁"，不能直接拿来覆盖本地缓存，否则会把数据搞坏。

5. 选型与排错：怎么选合适的 2xx，以及多年踩坑经验总结

5.1 2xx 选型决策参考

实际设计接口时，不需要每次都从零翻 RFC，我一般按这个经验决策表来选：

这个表不是教条，但大部分常规业务场景照着选不会出错。尤其在多人协作的团队里，状态码选得统一，后续维护成本会低很多。

5.2 200 与业务状态码的关系：一个值得掰扯的话题

"业务错误也返回 200，只在 body 里放一个 error_code"——这个模式在工程界争论很久了。我的观点是：HTTP 层状态码遵循 HTTP 语义，业务层的成功/失败放在载体里，两者可以并存，但不能互相替代。

如果你做了一个"用户未登录"的接口调用，返回 200 +{code: 40101, message: "未登录"}，这个响应从 HTTP 语义上说是成功的。会导致什么后果？CDN 和网关无法依据状态码做统一的缓存和限流，监控系统无法通过状态码统计错误率，客户端的拦截器也很难统一做登录态跳转。这显然不理想。

反过来，有些 BFF（Backend For Frontend）层接口为了让前端能拿到业务错误明细，确实会采用 200 + code 的折中方案。如果团队已经确定了这个模式，也至少要保证 4xx 类语义错误（未认证、无权限、资源不存在）用真实的 HTTP 状态码，别把"未认证"塞进 200 里。这个边界把握好了，接口在语义层面才干净。

另外要提一个反模式：网关健康检查为什么一定要避开"伪 200"。我见过有的服务端把所有异常都包装进 200，结果健康检查接口永远返回 200，哪怕数据库连接池已经耗尽，负载均衡器依然认为节点健康，流量照常打过来，最终整个服务雪崩。健康检查接口必须严格区分 200 和 5xx，这是运维层面最基础的红线。

5.3 实际排查 2xx 问题的完整链路

再回到开头那个下载损坏的问题。当时我排查的链路是这样的：

1. 用户报障：下载 1GB 以上的文件，下载完成后校验 SHA 不一致。
2. 第一次怀疑是网络传输丢包，让小范围用户重新下载，问题依旧。
3. 抓包对比正常请求和异常请求，发现异常请求的响应状态码是 200，而不是 206。
4. 进一步检查服务端日志，确认服务端在处理Range: bytes=1024-时抛了一个参数解析异常，框架兜底返回了 200 全量。
5. 下载工具收到 200 后，认为"服务器不支持断点续传"，直接把全量数据当作"从第 1024 字节开始的片段"拼到已有文件后面，最终文件头部出现大段重复字节，校验失败。

修复其实很简单：正确处理 Range 头的尾部开放区间语法，并在真正无法支持 Range 时，通过 200 全量响应让客户端走全量下载逻辑，而不是让下载工具在半信半疑中拼接文件。这个案例里最迷惑的点就在于状态码全是 2xx，没有 4xx/5xx 报警，如果不是抓包对比，你很难想到问题出在 200 和 206 的语义差异上。

类似的问题还有：

• 前端要求拿到 204 却收到 200+空 body，逻辑进到了渲染分支，白屏。
• 代理把 201 的 Location 改成了另一个域名，客户端跳转鉴权失败。
• 服务器分页接口返回 206，本来应该是 200，结果前端把所有响应都按 JSON 解析，二进制乱码被塞进了渲染层。

遇到 2xx 相关诡异问题，我建议排查顺序是：先看状态码对不对，再看响应头（Location、Content-Range、Content-Length、Cache-Control），最后才看响应体内容。很多问题的根因根本不在 body，而在头和状态码的匹配上。

5.4 给前端和客户端开发者的 2xx 处理建议

如果你在写前端或客户端，下面的经验可以直接用：

• 不要在业务代码里只判断status === 200。一个合格的状态码处理函数，至少要区分 200/201/204/206/202。
• 用 axios 或 fetch 时，注意响应类型对 206 的影响。fetch 的response.json()会把 206 返回的字节流按 JSON 解析，如果这个接口设计成音频分片下载，要用response.arrayBuffer()或response.blob()，否则会出现"206 解析失败"这种难排查的问题。
• 如果接口会返回 201，一定要优先读Location头定位新资源，而不是只依赖响应体里的 id。
• 如果接口返回 204，不要再去读 body，也不要让代码走进"成功但有数据"的分支。
• 如果接口是异步任务，收到 202 后要主动开始轮询，并设置超时和失败上限，防止死循环打爆服务端。

我写过一个统一的 http 响应处理函数，大致思路就是：2xx 统一进成功分支，但再根据状态码决定是否解析 JSON、是否读 Location、是否要启动轮询。这套逻辑维护了两年多，基本没因为状态码语义问题返工过。

最后分享两个实操体会

做网关和接口设计这些年后，我最大的感受是，2xx 家族从来不是"随便挑一个成功码"的问题，而是"客户端看到这个码之后，能不能无歧义地执行下一个动作"的问题。以前我接手一个老项目，第一件事就是把所有接口的状态码做了统计，发现大量"伪 200"：创建对象不返回 Location 的 201、异步任务不带 task_id 的 200、删除成功还带着 body 的 200，客户端联调时全都在猜。后来逐个按语义修完，联调效率提升了不止一个档次。

还有一个很实用的小技巧：如果公司内部有 API 评审环节，把"这个接口在什么场景下返回哪个 2xx"作为固定问题写进评审清单。成本极低，但能逼着设计者在画接口时就想清楚响应语义。很多状态码相关的隐患，在设计阶段就能避开，而不是拖到线上故障才被追查。