被取消的异步操作抛出特定异常（.NET为OperationCanceledException，JS为AbortError/DOMException），需在await处显式捕获并区分类型，结合取消令牌主动退出以实现协作式中断。
在 async/await 场景中，被取消的任务通常抛出 OperationCanceledException（.NET）或 AbortError / DOMException（JavaScript），但直接用 try-catch 捕获并不总是有效——关键在于异常是否“逃逸”出 async 函数边界，以及取消信号如何传播。
明确取消源与异常类型
不同运行时对取消的建模方式不同，捕获前需确认实际抛出的错误类型：
- .NET（C#）中，
await task.WithCancellation(cancellationToken)或使用CancellationToken.ThrowIfCancellationRequested()时，抛出的是OperationCanceledException，且其CancellationToken属性与触发取消的 token 匹配； - JavaScript 中，
fetch()被AbortController中止时抛出DOMException，name为"AbortError"； - Node.js 的
AbortSignal相关 API（如stream.pipeline）也遵循类似约定。
避免误捕通用异常
不要用空 catch 块吞掉所有错误，尤其不能把取消当成普通失败处理：
- 取消是预期控制流的一部分，不是故障；记录或重试被取消的操作通常是错误行为；
- 建议显式判断异常类型：
if (err instanceof AbortError || err.name === 'AbortError')（JS），或检查ex is OperationCanceledException（C#）； - 若混用其他错误（如网络超时、解析失败），应在同一 try 块中区分处理，而非统一 fallback。
在 await 表达式外层包裹 try-catch
取消异常只会在 await 等待的 Promise/Task 完成时抛出，因此必须在调用 await 的位置捕获：
- ❌ 错误：在内部函数里 try-catch，但该函数未 await 被取消的异步操作；
- ✅ 正确：在调用
await fetchData()的 async 函数体内直接包围； - 若使用 Promise 链（
.then().catch()），需确保catch绑定在对应 Promise 上，而非外层未 await 的链。
配合 cancellation token 主动退出
仅靠 try-catch 不够，应结合 token 提前终止冗余工作：
- 在 long-running async 操作中（如循环读取流、分页请求），定期检查
token.IsCancellationRequested（C#）或signal.aborted（JS）； - 主动 throw 对应的取消异常，使控制流快速回退到最近的 try-catch；
- 这样可避免资源浪费，也让异常来源更清晰——是外部取消，还是内部逻辑中断。
不复杂但容易忽略：取消不是“错误”，而是协作式中断机制。try-catch 只是出口，真正重要的是理解谁发起了取消、何时响应、以及是否需要清理状态。
