abortcontroller 取消时 fetch 抛出 aborterror（domexception 类型），应通过 error.name === 'aborterror' 或 error.code === 20 精准识别并静默处理，避免误报；切勿在 finally 中重复 abort，async/await 需在 try/catch 内捕获并区分取消与其他错误。
当 AbortController 触发取消时，fetch 或其他支持 abort 的 API 会抛出 AbortError（类型为 DOMException），而不是普通错误。正确识别并静默处理它，是避免未捕获异常和误报的关键。
判断是否为取消错误
不能只靠 error.name === 'AbortError'，因为不同浏览器实现略有差异（如 Safari 曾返回 'AbortSignal' ），更可靠的方式是检查 error.name 并结合 error.code === 20（ABORT_ERR 常量）或直接用 signal.aborted 状态辅助判断：
- 推荐写法：
if (error.name === 'AbortError' || error.code === 20) - 更健壮写法（尤其兼容旧环境）：
if (signal.aborted && !response)（适用于 fetch 场景，表示请求中途终止且无响应） - 现代建议：使用
AbortSignal.abortReason（实验性，暂不广泛支持，慎用）
在 fetch 中静默处理取消错误
fetch 被中止时一定会 reject，但你通常不想把它当作业务错误上报或展示提示。应在 catch 中精准过滤：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
const controller = new AbortController();
setTimeout(() => controller.abort(), 3000);
fetch('/api/data', { signal: controller.signal })
.then(res => res.json())
.catch(err => {
if (err.name === 'AbortError') {
// ✅ 取消是预期行为，不处理、不提示、不上报
console.debug('Request was aborted');
return null;
}
// ❌ 其他错误（网络失败、500、JSON 解析失败等）需正常处理
throw err;
});
避免在 finally 中重复触发取消逻辑
有些代码会在 finally 里手动调用 controller.abort()，这可能导致重复 abort 或干扰原 abort 流程。正确做法是：
- 只在需要主动取消时调用
abort()（如组件卸载、用户切换页面） - 不要在 promise 链的
finally中无条件 abort —— 此时信号可能已处于aborted状态，调用 abort 不报错但多余 - 若需清理，可检查
!controller.signal.aborted再调用
与 async/await 配合时的常见陷阱
使用 async/await 时，取消错误仍会进入 catch 块。注意不要因忘记 await 或错误嵌套导致取消错误被吞掉或误判：
- 错误示例：
fetch(...).catch(handleError)写在 await 外层，会丢失上下文 - 正确结构：始终将 fetch 包在 try/catch 内，并在 catch 中区分
AbortError - 组合多个异步操作时（如 fetch + parse + transform），仅 fetch 受 abort 控制；后续步骤不会自动中断，需自行检查
signal.aborted
核心原则：取消不是错误，而是控制流的一部分。识别它、忽略它、不传播它，才能让 abort 机制真正服务于用户体验而非制造噪音。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
