取消异常是主动中断，网络错误是被动失败；前者由abort()等显式调用触发，属可控中断，错误名含AbortError/CanceledError；后者为底层链路崩溃导致的TypeError，消息含“failed to fetch”等关键词；处理上取消异常应静默忽略，网络异常需提示用户并重试。
取消异常是主动中断，网络错误是被动失败
取消异常（如 AbortError 或 CanceledError）源于代码显式调用 abort()，属于可控的、人为触发的中断；而普通网络错误（如断网、DNS 失败、连接被拒）是底层通信链路崩溃导致的不可控失败，fetch 会以 TypeError 形式 reject，且无响应体。
错误类型和消息特征明显不同
区分关键看 error 的构造函数和内容：
-
取消异常：
•
err.name === 'AbortError'（原生 fetch + AbortController） • 或axios.isCancel(err) === true/err.name === 'CanceledError'（axios） • 错误消息通常含"The user aborted a request"或"canceled" -
网络异常：
•
err instanceof TypeError为真 • 消息含"failed to fetch"、"network error"、"offline"等关键词（大小写不敏感）
处理策略应有明确分工
取消异常一般无需重试或提示用户检查网络，而是静默忽略或清理 UI 状态；网络异常则需引导用户恢复连接、展示离线态、或自动重试。
- 对取消异常：可直接 return 或标记“请求已取消”，避免触发错误提示弹窗
- 对网络异常：建议记录日志、显示友好提示（如“网络不可用，请检查 Wi-Fi 或移动数据”）、并提供手动重试入口
- 对 HTTP 错误（如 404/500）：它们仍会进入
then，需靠response.ok或response.status判断，不属于取消或网络层问题
推荐统一捕获结构
使用 async/await 时，一个清晰的错误分支能避免混淆：
立即学习“Java免费学习笔记（深入）”；
- 先判断是否为取消错误 → 忽略或做卸载清理
- 再判断是否为网络类
TypeError→ 触发离线逻辑 - 最后处理其他错误（JSON 解析失败、业务码异常等）→ 按需上报或提示
这样分层识别，既符合错误本质，也便于后续扩展监控与埋点。
