我以前看到请求失败就统一显示“网络错误”。这句话对用户不够准确，对排错也没有帮助，所以做了一个只有三个分支的最小实验。

先写出三个结果

第一个分支让请求直接断网，第二个请求一个不存在的路径，第三个让服务端返回一个结构合法但业务失败的 JSON。

实验结果很快把误解拆开：fetch 只有在网络层失败时才会 reject；收到 404 或 500 时，它依然会 resolve，只是 response.ok 是 false。

这件事为什么重要

如果只写 catch，HTTP 错误会被当成成功响应继续往下解析。反过来，如果所有错误都显示成网络异常，用户会以为自己断网，开发者也会错过真正的接口问题。

现在的处理顺序是：先判断是否拿到 response，再判断 response.ok，最后才解析业务数据。每一步都对应一种可以复现的失败。

观察输出，而不是猜

最小复现的价值不是马上写出最好的封装，而是把“我以为会这样”变成浏览器实际输出。等边界稳定之后，再加超时、重试和错误提示，代码会更容易解释。

下一步

接下来会给请求封装加入 AbortController。目标不是把所有错误藏起来，而是让调用方知道：这次是超时、主动取消，还是服务端明确拒绝。