fetch“成功”指网络通信完成而非业务正常，404/500等状态码仍会resolve；需用res.ok判断业务失败，网络错误才reject。

fetch 的“成功”不是按业务是否达成来定义的，而是严格按网络通信是否完成来判断。只要请求发出去、响应头收到了，哪怕状态码是 404 或 500，fetch 就算“成功 resolve”，不会进 catch —— 因为服务器已经完成了 HTTP 交互，这在协议层面不算错误。

fetch 的 success 指的是“通信完成”，不是“业务正常”

HTTP 协议把状态码（如 404、500）看作响应的一部分，而非传输失败。fetch 遵循这一语义：

• 网络层出问题（DNS 失败、TCP 连不上、离线、CORS 被浏览器拦截）→ fetch 返回 rejected promise → 可被 try/catch 或 .catch() 捕获
• 服务器返回了完整响应（含 404 Not Found 或 500 Internal Server Error）→ fetch 返回 resolved promise，response 对象存在 → 必须手动检查 res.ok 或 res.status

如何判断真正的业务失败

response.ok 是最简洁可靠的判断依据：它只在 status ∈ [200, 299] 时为 true。

• 推荐写法：if (!res.ok) throw new Error(`${res.status} ${res.statusText}`)
• 不建议只依赖 status === 404：有些接口用 422 表示参数错、用 401 表示未登录，统一用 !res.ok 更健壮
• 注意 response.headers 可读性：在 if (!res.ok) 分支里，res.headers 仍可安全访问，可用于读取自定义错误原因（如 X-Error-Code）

常见误解与后果

误以为 catch 能捕获 404/500，会导致错误静默、UI 不更新、用户无反馈。

• ❌ 错误模式：fetch(url).then(res => res.json()).catch(err => console.error(err)) —— 404 会进 then，但 res.json() 可能因后端返回 HTML 错误页而抛 SyntaxError，且脱离当前 try/catch
• ✅ 正确模式：所有 await 操作（fetch、res.json()、res.text()）必须在同一个 try 块内，且显式校验 res.ok
• ⚠️ 网络错误时 res 不存在，所以不能在 catch 里读 res.status 或 res.headers —— 会报 ReferenceError

区分网络错误和 HTTP 错误的实际方法

需要差异化提示时，靠 error 实例类型和来源判断：

• 网络错误：通常是 TypeError，message 含 "Failed to fetch"、"NetworkError"、"AbortError"
• HTTP 错误：是你自己 throw 的 Error，可用自定义属性标记，比如 err.type = 'http' 或 err.status = res.status
• JSON 解析失败：SyntaxError，说明后端返回了非 JSON 内容（如 HTML 错误页），此时应 fallback 到 res.text() 并人工处理