AbortError 是请求被主动取消时抛出的标准错误，name 属性恒为"AbortError"，应静默处理；其余错误按类型区分处理，组件中需结合卸载检查与 controller 复用防止状态错乱。
AbortError 是请求被主动取消时 fetch 或 node-fetch 抛出的标准错误，不是网络故障，也不该弹窗提示用户。关键在于区分“可预期的取消”和“真实异常”，避免误报、状态错乱或内存泄漏。
只捕获 AbortError，其他错误正常处理
AbortError 的 name 属性固定为 "AbortError"，这是最可靠、最轻量的判断依据。不要依赖 message 字符串匹配（内容可能随浏览器/环境变化），也不要把它和其他网络错误混在一起处理。
- 在
catch块中优先检查err.name === 'AbortError' - 命中则直接 return 或静默忽略，不更新 UI、不重试、不记录 error 级日志
- 其余错误（如网络中断、500、JSON 解析失败）走常规错误分支：提示用户、上报监控、触发 fallback
React/Vue 组件中必须配合卸载检查
即使请求被取消，如果组件已卸载，仍可能在 .then 中调用 setState 或更新响应式数据，引发警告甚至崩溃。AbortController 只中断请求，不阻止后续回调执行。
- 在 useEffect 或 onMounted 中创建 controller，并在清理函数中调用
controller.abort() - fetch 后的 then/catch 中，额外加一层“是否仍挂载”的判断（例如 React 用 useRef 记录 mounted 状态）
- 推荐写法：
if (!signal.aborted && isMounted()) { updateState(data) }，双重保险
node-fetch 场景下要识别 err.type 分类
node-fetch 对错误做了更细粒度划分：AbortError 是取消；FetchError 是操作型错误（如超时、重定向循环）；系统级错误还会带 err.code（如 ECONNREFUSED）。仅靠 name 不够。
- 先判断
err.name === 'AbortError'—— 主动取消，安静退出 - 再判断
err.name === 'FetchError' && err.type === 'request-timeout'—— 超时，可重试或提示“请求超时” - 最后看
err.type === 'system' && err.code === 'ECONNRESET'—— 网络层问题，需记录并降级
搜索等高频场景别漏掉 controller 复用逻辑
输入框连续触发请求时，每次都要 abort 上一个 controller，否则旧请求返回后仍会执行回调，覆盖最新结果。
- 声明一个外部变量（如
let controller = null），每次新请求前先controller?.abort() - 立刻新建 controller 并赋值，确保 signal 是新鲜的
- 不要在事件回调里直接 new AbortController() 后不存引用——下次无法 abort 它
