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 ：
- 200、201、204 →
response.ok === true- 400、401、404、500、503 →
response.ok === false，但不会进 catch为什么这样设计？
HTTP 状态码本身不全是“错误”——比如 401（未认证）、403（禁止访问）、409（冲突）、429（限流），这些是服务端有意返回的合法业务反馈，客户端需要解析并做出相应处理（跳转登录页、提示重试、显示友好文案等），而不是统一当异常抛掉。
实际开发中怎么处理才稳妥？
建议在 then 链中主动检查状态，避免静默失败：
- 用
if (!response.ok) throw new Error(...)主动抛错，让后续 catch 捕获- 对不同 status 做分支处理：
if (response.status === 401) { redirectToLogin() }- 封装通用 fetch 函数，在内部统一校验 ok 并解析 JSON，减少重复逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
