Fetch 为何不捕获网络错误？真相揭秘

你是否曾困惑为什么 fetch 在遇到 404 或 500 错误时既不抛异常也不进 catch？真相是：fetch 的“成功”仅表示网络通信完成（请求发出、响应头到达），而非业务逻辑正常——HTTP 状态码属于合法响应的一部分，因此 404/500 会 resolve 而非 reject；真正被拒绝的只有 DNS 失败、断网、CORS 拦截等底层网络问题。要可靠处理业务错误，必须主动检查 response.ok 或 status，并将所有异步操作（fetch、res.json() 等）置于同一 try 块中，避免静默失败和 UI 卡顿。掌握这一底层逻辑，才能写出健壮、可维护的真实世界 API 调用代码。

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() 并人工处理

今天关于《Fetch 为何不捕获网络错误？真相揭秘》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！