Task.Cancel() 无效是因为它仅设置取消标记，真正响应需手动检查 CancellationToken；必须在耗时操作、循环及每层调用中主动协作检查并抛出异常。
Task.Cancel() 为什么没用？
因为 Task 本身不支持直接中断，Cancel() 是假动作——它只是设置 CancellationToken.IsCancellationRequested 为 true，真正是否响应、何时响应、怎么退出，全靠你自己在任务内部写逻辑。常见错误是只调了 cancellationTokenSource.Cancel()，但任务体里压根没检查 token，结果任务照跑不误。
典型场景：长时间轮询、IO 等待、CPU 密集循环。这些地方必须主动“让出控制权”并检查 token。
实操建议：
- 所有耗时操作（如
Task.Delay()、HttpClient.GetAsync()）优先使用带CancellationToken重载的版本，它们会在收到取消信号时抛出OperationCanceledException - 纯 CPU 循环中，每迭代若干次或每次关键节点插入
token.ThrowIfCancellationRequested()或if (token.IsCancellationRequested) break; - 不要捕获
OperationCanceledException后吞掉它——除非你明确要压制取消行为；默认应让它向上冒泡，让await task正确进入IsCanceled == true状态
async 方法里怎么正确传递和响应 CancellationToken？
很多人把 CancellationToken 当成可选参数随便加，结果在深层调用链里丢失或忽略。关键不是“有没有传”，而是“每一层是否参与协作”。比如你写了 async Task DoWorkAsync(CancellationToken token)，但里面调用的 ParseData() 是同步阻塞方法，且没暴露 token 参数，那整个链路就断了。
实操建议：
- 入口 async 方法必须声明
CancellationToken token = default，并原样传给所有下游 async 调用（如await LoadAsync(token)） - 同步辅助方法如果可能被取消路径调用，也应增加
CancellationToken参数，并在内部检查（哪怕只是开头加一行token.ThrowIfCancellationRequested();） - 避免在 async 方法里 new 一个新
CancellationTokenSource—— 这会切断与上游取消信号的关联 - 如果用了
Task.Run(() => {...})包同步代码，记得把 token 传进去，并在委托内手动检查
Task.Wait() 或 Result 被取消时抛出 AggregateException 怎么处理？
这是同步等待异步任务时最常踩的坑：task.Wait() 或 task.Result 在任务被取消后不会返回 IsCanceled，而是包装成 AggregateException，内层是 OperationCanceledException。直接 catch Exception 会漏掉这个关键信号，导致你以为失败了，其实是被正常取消。
实操建议：
- 永远优先用
await task，它天然解包OperationCanceledException并让任务状态变为IsCanceled == true - 非要用同步等待时，必须显式 catch
AggregateException，然后检查e.InnerExceptions.OfType<operationcanceledexception>().Any()</operationcanceledexception> - 更稳妥的做法是改用
task.Wait(timeout, token)配合超时和外部 token，但依然推荐转向 async/await
后台线程里启动的 Task 能响应 Web 请求的取消吗？
不能自动响应。ASP.NET Core 的 HttpContext.RequestAborted 是请求生命周期绑定的 CancellationToken，只对当前请求上下文有效。如果你在 Controller 里开了个 Task.Run 或用 ThreadPool.QueueUserWorkItem 启动后台任务，它拿不到这个 token，也不会随请求结束而取消。
实操建议：
- 需要响应请求取消的任务，必须显式把
HttpContext.RequestAborted传进任务体（例如Task.Run(() => Work(token), token)） - 后台长任务（如队列处理、定时作业）不该依赖请求级 token，应使用独立的
CancellationTokenSource，并在应用关闭时统一触发（如IHostApplicationLifetime.ApplicationStopping） - 特别注意：不要把
RequestAborted存到静态字段或跨请求复用——它是一次性的，下次请求已失效
最难的从来不是调用 Cancel()，而是确保每个执行分支都真正“看见”并“尊重”那个 token。漏掉一次检查，就等于留了一个无法终止的 goroutine —— 只不过 C# 里叫 Task。
