必须为事件监听器中的 fetch 绑定 abortcontroller.signal 才能中止请求；每次事件触发应新建独立控制器，避免复用；可利用 addeventlistener 的 signal 选项自动解绑；需捕获 aborterror 静默处理，避免误报。
事件监听器中触发请求，必须绑定 signal 才能中止
直接在 click、input 等事件回调里发起 fetch，却不把 AbortController.signal 传进去，请求就无法被中止。signal 不是可选的“附加功能”，而是取消机制的必要桥梁。浏览器原生 fetch 只有收到 signal 后，才会在 controller.abort() 调用时抛出 AbortError 并终止连接。
每个监听事件应配独立控制器，避免复用或泄漏
不要在组件外或模块顶层创建单个 controller 全局复用——这会导致多个点击触发的请求共用一个 signal，abort 时一锅端，或未及时清理造成内存残留。正确做法是：每次事件触发时新建 controller，并将其与当前请求生命周期对齐。
- 点击按钮 → 新建 const controller = new AbortController()
- fetch 时传入 { signal: controller.signal }
- 若需手动取消（如用户再点“取消”按钮），调用 controller.abort()
- 若监听器本身需随组件卸载自动清理，可将 controller.signal 传给 addEventListener 的 options，实现监听器自动解绑
结合事件选项自动清理监听器，减少手动 remove
addEventListener 第三个参数支持传入 { signal }，这样当 controller.abort() 被调用时，该监听器会自动移除，无需再保存 handler 引用并手动 removeEventListener。这对防止重复绑定、避免监听器堆积特别有用。
- 示例：button.addEventListener('click', handler, { signal: controller.signal })
- 后续调用 controller.abort()，不仅中止 fetch，也自动解绑这个 click 监听器
- 适合一次性操作（如提交表单后禁用按钮）、临时监听（如拖拽开始/结束）等场景
捕获 AbortError 并区分处理，不干扰其他错误流
abort 后 fetch 会 reject，但错误名固定为 'AbortError'，不是网络错误或业务错误。如果不加判断直接报错，用户可能看到“请求失败”提示，实际只是主动取消。
- 在 catch 块中检查 err.name === 'AbortError'
- 可静默处理，或显示“已取消”状态，不触发错误 Toast 或日志告警
- 避免和 401、500 等真实异常混为一谈，保障错误监控准确性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
