跨浏览器处理网络错误及拦截请求是否存在统一标准方案？

问题 #

根据Fetch规范，网络错误响应的状态码应为0，但各浏览器的Fetch API实现会抛出通用错误，且不同浏览器抛出的错误消息存在差异。这种未标准化的行为给团队的遥测与告警系统带来困扰——我们需要区分网络错误和服务器错误，目前只能通过匹配不同浏览器的错误消息字符串过滤，现有匹配列表如下：

const NETWORK_OR_FIREWALL_ERROR_MESSAGES = [
  'TypeError: Failed to fetch', // Chrome
  'Failed to fetch', // Chrome, Edge
  'NetworkError when attempting to fetch resource.', // Firefox
  'Load failed', // iOS Safari,
];

但这个列表并不全面，只能靠值班工程师收到告警后排查日志逐步补充。现咨询：

1. 是否有更优的网络错误过滤方案？
2. 是否只能依赖Error.message字符串匹配？
3. Fetch API的此类行为为何未标准化？

回答 #

1. 更优的网络错误过滤方案 #

有几种更可靠的替代方案，比匹配错误消息稳定得多：

• 检查错误的name属性：网络错误通常会被标记为TypeError（Chrome/Edge/Safari）或NetworkError（Firefox），先通过error.name做第一层过滤，再结合其他特征缩小范围，比直接匹配消息更靠谱。
• 结合navigator.onLine辅助判断：虽然这个API不是绝对精准，但可以作为补充——如果请求失败时navigator.onLine返回false，基本可以判定是客户端离线类的网络问题。
• 捕获网络请求的底层错误码：Chrome/Edge等浏览器会在控制台输出net::ERR_XXX类的网络错误码（如net::ERR_CONNECTION_REFUSED、net::ERR_TIMED_OUT），可以通过监听performance.getEntries()或浏览器的网络请求事件来获取这些错误码，不过需要额外的埋点逻辑。
• 统一封装Fetch请求：在团队内部封装一层Fetch工具函数，集中处理网络错误的判断逻辑，后续新增浏览器适配只需修改这一处，不用在业务代码里分散处理。

2. 是否只能依赖Error.message字符串匹配？ #

绝对不是。依赖Error.message是最不可靠的方案，浏览器随时可能修改错误文案（比如版本更新调整措辞、适配本地化语言），很容易出现漏判或误判。前面提到的error.name、底层网络错误码、离线状态判断，都是比匹配消息更稳定的方式。如果一定要用消息匹配，建议只把它作为兜底方案，结合其他判断条件一起使用。

3. Fetch API的此类行为为何未标准化？ #

主要有三个核心原因：

• 浏览器网络引擎差异：不同浏览器使用的网络引擎不同（Chrome用Blink，Firefox用Gecko，Safari用WebKit），网络错误的触发逻辑、细分类型本来就存在差异，规范很难覆盖所有场景并强制统一。
• 规范的弹性设计：Fetch规范仅定义了"网络错误"的核心概念（状态码为0），但没有强制规定抛出错误的具体格式（比如name、message的具体内容），只要求抛出DOMException或TypeError，给了浏览器厂商足够的实现空间。
• 本地化需求：错误消息需要适配不同地区的语言，浏览器厂商会根据用户的系统语言返回本地化文案，这就决定了message字段本身不可能被标准化。

内容的提问来源于stack exchange，提问作者Patrick Finnigan