AbortController 仅对 fetch 等显式支持 signal 的 API 有效，无法中断 HTML 标签加载；需每次请求新建实例，abort 后须手动处理错误与状态，且不保证服务端终止。
AbortController 不能直接用在纯 HTML 中——它是个 JavaScript API，必须配合 fetch 或 XMLHttpRequest 等可中断的请求方式使用。HTML 标签本身（比如 <script></script>、）不支持 AbortController 取消。
AbortController 必须和 fetch 一起用才有效
只有 fetch 的 signal 选项能接收 AbortController.signal，并真正响应 abort()。其他 DOM 加载行为（如图片加载、脚本执行）完全无视这个 signal。
-
fetch('/api/data', { signal: controller.signal })—— ✅ 支持取消 -
new Image().src = '/logo.png'—— ❌ 无法用 AbortController 中断 -
document.createElement('script').src = 'app.js'—— ❌ 不响应 signal
常见错误是以为给任意请求加个 signal 就能取消，其实底层实现必须显式监听 signal 状态——目前仅 fetch 和 WebSocket（部分浏览器实验性支持）做到了。
中止 fetch 请求后，状态和错误要手动处理
调用 controller.abort() 后，fetch 会立刻 reject，抛出 AbortError（实际是 DOMException，name 属性为 'AbortError'），但不会自动清理 pending 状态或重置 UI。
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 必须用
catch捕获错误，并区分是网络错误还是主动中止：fetch('/search', { signal }).catch(err => { if (err.name === 'AbortError') { console.log('用户取消了请求'); // 清除 loading 状态、恢复按钮等 } else { console.error('真实网络错误', err); } }); - 如果请求已发出但服务端仍在处理，abort 只是断开客户端连接，服务端逻辑不会自动终止（需额外设计 cancel token 或 idempotent 接口）
多个请求共用一个 AbortController 很危险
一个 AbortController 实例调用 abort() 会中止所有绑定它的 fetch，哪怕它们语义上无关。典型翻车场景：搜索框防抖时，连续输入触发多次请求，却只用一个 controller。
- ✅ 正确做法：每次新请求都新建
const controller = new AbortController() - ❌ 错误做法：全局复用 controller，导致“按一次取消键，整个页面请求全挂”
- 注意：
signal是一次性对象，abort 后不可重用；也不能把已 abort 的 signal 再传给新 fetch（会立即 reject）
最常被忽略的一点：AbortController 不是“取消队列”，它只是通知信号。如果你在 fetch 调用前就调用了 abort()，请求根本不会发出去；但如果已经进入网络栈，是否真能及时断连，取决于浏览器实现和网络层状态——别假设它 100% 实时生效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
