Response 状态、Headers 与 body

Fetch 的 Promise 成功只表示拿到了 Response；404、500 仍会得到响应对象。业务代码必须分别检查 ok/status、Headers 和 body 的消费方式。

最小实验：用 Response 构造可控输入

async function inspect(response) {
  const contentType = response.headers.get('content-type')
  const body = contentType?.includes('json') ? await response.json() : await response.text()
  return { ok: response.ok, status: response.status, contentType, body }
}

const success = new Response(JSON.stringify({ id: 1 }), {
  status: 200,
  headers: { 'content-type': 'application/json' }
})
const failure = new Response('missing', { status: 404 })
console.log(await inspect(success))
console.log(await inspect(failure))

预期第一项是 ok: true、状态 200 和对象；第二项是 ok: false、状态 404 和字符串。把 inspect 改成先 throw 再解析，说明错误路径为什么仍应保留 status 和 body 的诊断信息。

机制与边界

response.ok 只覆盖 200–299；它不会检查业务 JSON 中的 success 字段。Headers 可能受 CORS 暴露规则限制，body 只能消费一次。网络拒绝、HTTP 错误、解析失败和业务失败应进入不同错误分类，不能全部显示成“请求失败”。

练习

1. 为 204、401、500 和错误 JSON 各构造一个 Response，写出状态分类和用户反馈。
2. 增加 content-type 缺失分支，确保不会盲目调用 json()。
3. 说明为什么 fetch() 的 Promise reject 不代表所有 HTTP 错误。

查看本节答案