202 表示已受理但没完成
202 Accepted 的含义是请求已经被接受处理，但处理还没有完成，结果也还不确定。它最适合异步任务：导出报表、批量处理、消息投递这类耗时的操作先受理再执行。响应里通常会给出任务标识与查询进度的地址，调用方拿到 202 之后必须自己轮询状态或等待回调，把 202 当成成功终态是设计上最常见的错误。
基本信息
| 名称 | 202 Accepted |
|---|---|
| 作用 | 异步受理，不承诺处理结果 |
| 规范 | RFC 9110 第 15.3.3 节 |
| 响应体 | 常见任务编号与进度查询地址 |
| 配套机制 | 轮询状态接口、回调通知、消息队列的完成事件 |
| 与 201 的区别 | 201 表示资源已经创建完成，202 只表示请求已被接受 |
受理与轮询
受理与轮询
curl -si -X POST https://api.example.com/jobs -H 'Content-Type: application/json' -d '{"type":"export"}'
# HTTP/1.1 202 Accepted
# Location: /jobs/j-8891 # 用 Location 或响应体给出查询地址
# {"job_id":"j-8891","status_url":"/jobs/j-8891"}
curl -s https://api.example.com/jobs/j-8891 # 轮询状态：常见 running 与 succeeded 与 failed
curl -s -H 'Idempotency-Key: req-88231' -X POST https://api.example.com/jobs -d '{"type":"export"}' # 幂等键避免重复受理输出观察项
| 观察项 | 含义 | 注意点 |
|---|---|---|
| 202 状态码 | 请求已受理 | 不代表执行成功 |
| Location 或 status_url | 任务状态查询地址 | 缺失时调用方无法跟踪进度 |
| job_id | 任务唯一标识 | 日志与工单里都用它对齐问题 |
| Retry-After | 建议的轮询间隔 | 据此设计退避，避免密集轮询 |
| 任务状态字段 | running 与 succeeded 与 failed | 失败时需要有错误原因字段 |
典型使用场景
- 大报表导出：受理后异步生成，完成后通知下载地址
- 批量数据导入：先受理再排队处理，避免请求长时间挂住
- 消息或通知投递：交给队列后立即返回受理结果
- 耗时较长的部署与构建触发：返回任务编号供后续查询
- 跨系统数据同步：受理后由后台任务完成，前端只展示进度
202 的最终结果可能是失败，调用方必须实现状态查询或回调处理，否则会出现「界面显示提交成功、实际什么也没做」的静默失败，这类问题在事故复盘里非常常见。
异步接口应配合幂等机制：同一个业务请求被重复提交时用幂等键返回同一个任务，避免用户重试产生多个重复任务。