201 是什么
201 Created 表示请求成功，并且导致服务器创建了一个新资源。它与 200 的区别不在成功与否，而在「有没有真的产生新东西」：创建类接口回 201 时，规范建议用 Location 给出新资源的地址，响应体可以顺带返回创建后的完整表示，帮客户端省掉一次查询。
基本信息
| 语义 | 请求成功且创建了新资源 |
|---|---|
| 规范 | RFC 9110 §15.3.2 |
| 关键头部 | Location，指向新资源 |
| 响应体 | 可选，通常返回创建后的资源表示 |
| 常见用法 | POST 创建、PUT 幂等创建 |
创建后拿到新地址
创建后拿到新地址
curl -si -X POST https://api.example.com/users \
-H 'Content-Type: application/json' -d '{"name":"bob"}' | head -8
# HTTP/1.1 201 Created
# Location: /users/1024
# {"id":1024,"name":"bob"} # 响应体可直接给出创建结果
curl -s https://api.example.com/users/1024 # 验证 Location 指向的资源确实可读同类场景怎么选码
| 场景 | 推荐码 | 说明 |
|---|---|---|
| 同步创建并返回结果 | 201 + Location | 最常见；客户端可直接按 Location 取用 |
| 创建后由后台异步生成 | 202 Accepted | 给任务地址而不是资源地址 |
| PUT 幂等写入同一路径 | 首次 201、覆盖 200/204 | 反映「是否真的新建了」 |
| 参数校验未通过 | 400 或 422 | 不要用 201 掩盖失败 |
| 重复提交命中幂等 | 200 | 明确返回既有资源，避免重复创建 |
Location 允许是相对引用（如 /users/1024），解析基准是请求 URL；跨域跳转或经过多层代理重写时，用绝对 URL 更稳。
客户端怎么处理
- 判断成功以 2xx 为准，不能只认 200，否则会漏掉创建成功的结果
- 有 Location 时优先按它取资源，不要自己拼路径
- 响应体可直接作为本地缓存，省掉紧跟的一次查询
- 对 201 同样适用重试语义，但必须配幂等键，避免重复创建
常见误用
- 写入失败仍回 201 并带空对象，用「成功码」掩盖失败，调用方无从察觉
- 批量创建只回一个 201，不返回各条结果，调用方无法对应到具体条目
- 把 201 用于更新成功，语义混淆，客户端很难区分新建与覆盖
- Location 用相对路径但客户端按错误基准解析，拿到 404 却以为是服务端问题