AbortController是浏览器原生提供的异步操作中止机制，用于解决fetch无默认取消能力的问题；它通过controller.abort()触发signal信号，使绑定该signal的fetch立即reject AbortError，需在请求发起后、完成前调用，并配合错误类型判断和useEffect清理逻辑实现优雅取消。
AbortController 是什么，为什么 fetch 需要它
浏览器原生 fetch 默认没有取消机制，一旦发起就只能等完成或失败。而实际场景中（比如用户快速切换搜索关键词、离开页面、表单多次提交），你得主动中断旧请求，避免浪费资源或覆盖错误数据。AbortController 就是为此设计的：它生成一个 signal 对象，传给 fetch 后，调用 abort() 就能立刻终止对应请求。
怎么把 AbortController 和 fetch 正确配对使用
关键不是“创建一次复用”，而是“每次请求都新建一对 Controller + signal”，否则多个请求会互相干扰。常见错误是把同一个 AbortController 实例反复传给不同 fetch，结果一 abort 全挂了。
- 每次发请求前，必须新建
const controller = new AbortController() - 把
controller.signal作为signal选项传入fetch的配置对象 - 保留对
controller的引用（比如存在组件 state 或变量里），以便后续调用controller.abort() - 不要在
fetch().then()里再 abort —— 请求已完成，abort 无效；要在发起后、完成前触发（例如用户点击取消按钮、输入框防抖重置时）
示例：
const controller = new AbortController();
fetch('/api/data', { signal: controller.signal })
.then(r => r.json())
.catch(err => {
if (err.name === 'AbortError') {
console.log('请求已被取消');
} else {
console.error('其他错误', err);
}
});
// 后续某处调用
controller.abort(); // 立即中止该次 fetch
AbortError 怎么捕获和区分
fetch 被 abort 后不会进 .then，而是直接 reject 一个 AbortError 实例。但这个错误和其他网络错误（如 404、断网）一样走 .catch，所以必须靠 err.name === 'AbortError' 判断，不能只看 err.message 或类型转换。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 服务端返回的 HTTP 错误（如 500）仍会进
.then，需手动检查response.ok - 网络中断、DNS 失败等会 reject 其他错误（如
TypeError），和AbortError不同源 - React 中若在组件卸载后才收到 reject，需检查组件是否 still mounted，否则
setState会警告
实际项目里容易漏掉的边界情况
AbortController 解决的是“请求发出后中途取消”，但它不处理“还没发出去就被取消”的情况（比如防抖中旧请求未发，新请求已覆盖）。这时候 controller 还没传给 fetch，abort() 没意义，得靠逻辑层清理 pending controller 引用。
- 防抖/节流场景下，每次新请求前先
oldController?.abort()，再创建新 controller - React useEffect 中，cleanup 函数里必须调用
controller.abort()，防止内存泄漏和状态错乱 - Safari 15.4 之前不支持
AbortController，需要abort-controllerpolyfill（注意不是全量 polyfill，仅需构造函数） - 如果用
axios，它内部也支持signal，但默认不透出 controller，需自己封装或改用cancelToken（已废弃）
真正麻烦的从来不是写那行 controller.abort()，而是想清楚在哪一刻、对哪个 controller、以什么条件去调它——这取决于你的业务状态流，而不是 API 本身。
