AbortController不能直接控制fetch超时，它仅提供中止信号；超时必须由setTimeout主动触发abort()，且fetch不支持timeout选项，正确做法是手动结合AbortController与Promise.race或定时器封装。
AbortController 能不能直接控制 Fetch 超时
不能。AbortController 本身不提供超时逻辑，它只负责发出「中止信号」；超时必须由你自己用 setTimeout 主动触发 abort()。很多开发者误以为传个 timeout 选项就能生效，但 Fetch API 根本不支持该配置项。
常见错误现象：fetch(url, { signal, timeout: 5000 }) 完全无效，浏览器会忽略 timeout 字段，请求照常发出去且永不超时。
- 正确做法是手动创建
AbortController实例，再用setTimeout在指定毫秒后调用其abort() - 务必在
fetch的init对象中传入{ signal: controller.signal } - 如果请求提前完成，记得清除定时器（避免内存泄漏或误 abort）
如何写一个带超时的 fetch 封装函数
下面是一个轻量、可复用的封装，支持传入毫秒级超时值，并自动处理清理：
function fetchWithTimeout(url, options = {}, timeoutMs = 5000) {
const controller = new AbortController();
const id = setTimeout(() => controller.abort(), timeoutMs);
return fetch(url, {
...options,
signal: controller.signal
}).finally(() => clearTimeout(id));
}
使用场景：适合在 React useEffect、工具函数、表单提交等需要防呆的异步调用中复用。
-
signal是只读属性，必须从controller.signal取，不能直接 new Signal() -
finally确保无论成功/失败/中止，定时器都会被清除 - 如果
options.signal已存在（比如外部想统一控制多个请求），需做合并逻辑，不能粗暴覆盖
AbortController 抛出的错误怎么判断和处理
当请求被 abort，fetch 会 reject 一个 TypeError，且其 name 为 "AbortError"。这是唯一可靠的判断依据，不要依赖 message 字符串（不同浏览器内容不一致）。
常见错误现象：用 err.message.includes("abort") 做判断，在 Safari 或新版本 Chrome 中可能失效。
- 正确判断方式：
err.name === "AbortError" - 注意：这个错误不是网络错误，也不代表服务端没收到请求——TCP 连接可能已建立，甚至服务端已返回部分响应
- 如果要区分「用户取消」和「超时」，需额外记录原因（例如在
setTimeout里抛出自定义错误，或用闭包传参）
多个并发请求共用一个 AbortController 会怎样
可以，而且很常用——比如页面卸载时批量取消所有待处理请求。但要注意：一旦调用 controller.abort()，所有监听该 signal 的 fetch 都会立即 reject，无法单独取消某一个。
性能影响：无额外开销，AbortSignal 是轻量对象，内部用事件机制通知订阅者。
- React 场景下，推荐在组件 unmount 时调用
abort()，避免 setState on unmounted component - 如果某个请求需要独立生命周期（比如轮询接口不随页面卸载而停），就别把它和页面级 signal 绑定
- 已 abort 的 controller 不能重用；再次调用
abort()无效果，也不会报错
AbortController 的核心其实就两件事：发信号、收信号。真正容易被忽略的是信号发出后的边界情况——比如请求已完成但定时器还没清，或者 signal 被多个地方引用却只在一个地方 abort。这些细节不处理，轻则浪费资源，重则引发难以复现的竞态问题。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
