2xx 是什么
2xx 表示请求已被成功接收、理解并接受处理。但「成功」并不等于「一定有响应体」：有的码明确不带内容，有的码表示只是受理而结果还没确定，有的码只返回部分内容。这一类别内部的分工正是 REST 设计的表达力所在——把不同语义的成功区分开，监控、缓存与客户端分支才能各取所需。把所有成功统一用最通用的那个码返回，是最常见的接口设计退化。
基本信息
| 范围 | 以二开头的状态码 |
|---|---|
| 含义 | 成功接收并处理请求 |
| 常见码 | 通用成功、创建成功、已受理、无内容、部分内容 |
| 注意 | 成功不等于有响应体，也不等于结果已经确定 |
| 设计原则 | 按语义选择精确的码，而不是一律使用通用成功码 |
典型使用场景
- 读取资源：通用成功码配合内容类型返回数据
- 创建资源：创建成功码并用位置头指出新资源
- 异步任务：已受理码加进度查询地址
- 修改或删除：无内容码表示成功且无需回传数据
- 大文件传输：部分内容码支持分段与断点续传
判断成功不要写死一个码
判断成功不要写死一个码
curl -s -o /dev/null -w '%{http_code}\n' https://api.example.com/health # 健康检查只取状态码
# 健康检查应接受整段成功码，服务可能返回通用成功也可能返回无内容
# 客户端分支按首位数字判断，而不是逐个码硬编码常用成功码选择速记
| 场景 | 推荐码 | 关键点 |
|---|---|---|
| 普通读取成功 | 通用成功码 | 带上正确的媒体类型 |
| 创建成功 | 创建码 | 用位置头指向新资源 |
| 异步受理 | 已受理码 | 给出进度查询地址 |
| 修改删除且无内容 | 无内容码 | 不带响应体 |
| 大文件分段与续传 | 部分内容码 | 用范围头说明返回的是哪一段 |
排查要点
- 客户端只认一个成功码时，服务端一改成无内容就会误报失败
- 下载与续传场景要正确处理部分内容码，否则会重复下载或丢数据
- 异步接口只返回已受理却不让查询进度，调用方无法判断最终结果
这一类别里的「已受理」只表示请求被登记，结果尚未确定。返回它就必须同时给出可查询进度的地址，并在任务真正结束时改变该资源的可观察状态，否则调用方只能盲目轮询。
把健康检查或客户端逻辑写死为只认通用成功码，会在服务改成无内容响应或异步受理时误报故障，造成不必要的告警与自动重启。