能，但仅在响应开始接收前有效；之后abort仅使Promise拒绝并停止解析，不切断TCP连接或丢弃已收数据。
AbortController 能否真正中止正在传输的 Fetch 请求
能，但只在请求发出后、响应开始接收前有效。一旦服务器已返回部分响应（比如 response.headers 已可读），abort() 不会中断 TCP 连接或丢弃已到达的数据，只是让 fetch() 返回的 Promise 立即 reject，并停止后续解析（如 response.json() 不会执行）。
这意味着：对慢速网络或大文件下载，abort 更像“放弃处理”，而非“切断连接”。浏览器底层仍可能继续收包，但 JS 层已不再监听。
- 常见错误现象：
AbortError: The user aborted a request.抛出后，catch里没做清理，导致组件重复渲染或状态错乱 - 使用场景：搜索框防抖时取消上一次未完成的请求、页面卸载前清理 pending 请求、切换 tab 时终止旧数据拉取
- 注意：不能用于已 resolve 的 Promise；也不能中止 service worker 中的 fetch（需在 SW 内部另行控制）
如何避免多次 new AbortController 导致内存泄漏
每次调用 fetch() 都 new AbortController() 是安全的，但若控制器被长期持有（比如存在闭包、全局变量或 React 组件实例中未清理），就可能阻止 GC 回收，尤其在频繁触发的场景下（如输入实时搜索）。
实操建议：
- 在函数作用域内创建并使用，用完即弃 —— 大多数情况推荐此方式
- React 中，应在
useEffect清理函数里调用controller.abort()，而不是保留 controller 引用等待下次复用 - 不要把
controller.signal存进 Redux 或 Context，除非你明确管理其生命周期 - 测试是否泄漏：打开 DevTools → Memory → 拍摄堆快照，反复触发 fetch + abort，观察
AbortController实例数是否持续增长
AbortController 与 axios.CancelToken 的关键区别
AbortController 是原生标准，axios.CancelToken 是 axios 1.x 的旧机制（v0.22+ 已标记 deprecated，v1.0+ 完全移除）。两者语义相似，但行为细节不同：
-
AbortController.signal可被多个fetch()共享，一个abort()同时取消全部；CancelToken每次只能绑定一个请求 -
AbortController的abort()是幂等的，重复调用无副作用；CancelToken多次 cancel 会抛错 - axios 新版本直接支持传入
signal：axios.get('/api', { signal })，此时行为与fetch()一致 - 兼容性：Chrome 66+/Firefox 57+/Safari 12.1+ 支持；如需支持 IE，必须降级为
Promise.race()+ 手动 clearTimeout，无法真正中止网络层
React 中配合 useEffect 正确取消请求的写法
核心原则：每个 effect 对应一个独立的请求生命周期，abort 必须发生在该 effect 的清理阶段，且不能跨 effect 复用 signal。
useEffect(() => {
const controller = new AbortController();
const signal = controller.signal;
fetch('/api/data', { signal })
.then(r => r.json())
.then(data => setData(data))
.catch(err => {
if (err.name === 'AbortError') return; // 忽略取消错误
setError(err);
});
return () => {
controller.abort(); // 卸载或依赖变化时取消
};
}, [someDependency]);
- 错误做法：在
catch里再调一次controller.abort()—— 此时 signal 已终止，无效且可能干扰调试 - 容易踩的坑：把
setData放在then里不加 mounted 判断，组件卸载后仍尝试更新 state（React 18 会警告，但不会 crash） - 更稳妥的做法：在 effect 清理后加个标志位，或改用
useRef记录是否已卸载，但对大多数场景，仅靠AbortError过滤已足够
AbortController 的“优雅”不在语法多简洁，而在于它迫使你直面请求的生命周期 —— 每次发起都要考虑何时结束，以及结束之后要不要忽略错误、清空 loading 状态、还是重试。漏掉清理逻辑比写错 abort 更常见。
