Fetch 的 Promise 在网络层成功收到响应时即 fulfilled，仅断网、DNS 失败等网络异常才 reject；业务成功需通过 response.ok（等价于 status ≥ 200 且

因为 Fetch 的设计哲学是：只要网络层成功收到响应，就视为 Promise “fulfilled”，不管 HTTP 状态码是多少。

它只在真正“连不上”的时候 reject

Fetch 把“网络请求是否发出并收到响应”和“业务逻辑是否成功”做了明确分离：

• 断网、DNS 解析失败、CORS 被拦截、TLS 握手失败 → 触发 reject
• 服务器返回了响应（哪怕内容是 "Not Found" 或 "Internal Server Error"）→ 进入 then，response 对象可用

response.ok 是判断业务成功的标准

response.ok 是一个只读布尔值，等价于 response.status >= 200 && response.status ：

Java Api Extractor

从 Java 项目中提取 Controller 层接口定义为 JSON 数据。

下载

• 200、201、204 → response.ok === true
• 400、401、404、500、503 → response.ok === false，但不会进 catch

为什么这样设计？

HTTP 状态码本身不全是“错误”——比如 401（未认证）、403（禁止访问）、409（冲突）、429（限流），这些是服务端有意返回的合法业务反馈，客户端需要解析并做出相应处理（跳转登录页、提示重试、显示友好文案等），而不是统一当异常抛掉。

立即学习“Java免费学习笔记（深入）”；

实际开发中怎么处理才稳妥？

建议在 then 链中主动检查状态，避免静默失败：

• 用 if (!response.ok) throw new Error(...) 主动抛错，让后续 catch 捕获
• 对不同 status 做分支处理：if (response.status === 401) { redirectToLogin() }
• 封装通用 fetch 函数，在内部统一校验 ok 并解析 JSON，减少重复逻辑