CancellationToken.IsCancellationRequested 不会“突然”变 true，而是由 CancellationTokenSource.Cancel() 等显式触发后置为 true；它仅反映取消请求状态，需在每个可中断点主动检查并响应。
什么时候 CancellationToken.IsCancellationRequested 会突然变成 true
它不会“突然”变，而是由调用 CancellationTokenSource.Cancel() 显式触发，或超时、协作式取消等外部条件满足后置为 true。关键在于：这个值只反映“是否已被请求取消”，不保证任务立刻停止——你得自己检查并退出。
常见错误是只在任务开头检查一次：if (token.IsCancellationRequested) return;，结果后续长时间运行的循环或 I/O 操作完全忽略取消信号。
- 必须在长耗时操作的每个可中断点（如循环体开头、await 前、大数组处理间隙）重复检查
token.IsCancellationRequested - 更推荐用
token.ThrowIfCancellationRequested()，它会在被取消时抛出OperationCanceledException，语义更清晰，也方便上层统一捕获 - 注意：如果任务已进入不可中断的 native 调用（如某些 Win32 API 或未封装的阻塞 I/O），
IsCancellationRequested可能已为 true，但线程仍卡住——这不是 CancellationToken 的问题，而是你没选对可取消的 API
async 方法里 await 一个带 token 的 Task 为什么没响应取消
因为不是所有 await 的对象都真正支持取消；很多 Task 是“已完成”或“已取消”状态的静态返回值（比如 Task.CompletedTask），压根不看传入的 CancellationToken。
真正起作用的，是那些显式接受 CancellationToken 参数且内部做了检查的异步方法，比如 HttpClient.GetAsync(string, CancellationToken)、Stream.ReadAsync(byte[], int, int, CancellationToken)。
- 确认你调用的异步方法签名里确实有
CancellationToken参数，并且传了进去（别漏掉！） - 不要自己写
Task.Run(() => { ... }).Wait(token)这类伪异步——它只是把同步代码塞进线程池，取消只能中断 Wait，不能中断实际工作 - 如果封装了自己的 async 方法，记得把 token 一路向下传递，尤其经过
Task.WhenAll或Task.WhenAny时，要确保每个子任务都收到了 token
Task.Run + CancellationToken 为什么 Cancel() 后线程还在跑
Task.Run 本身不“监听” token；它只是把委托丢给线程池执行。所谓“取消”，其实是靠你在委托内部主动检查 token.IsCancellationRequested 并提前返回，或者调用 token.ThrowIfCancellationRequested() 中断执行。
如果你没在委托里做任何检查，CancellationTokenSource.Cancel() 调用完，线程照常跑完，只是对应 Task 的 IsCanceled 属性会变成 true——这是个事后标记，不是实时刹车。
- 错误写法：
Task.Run(() => Thread.Sleep(5000));→ 无法被取消 - 正确写法：
Task.Run(() => { for (int i = 0; i - 更优解：改用可取消的异步原语，比如
Task.Delay(5000, token)，它内部会响应取消并立即抛出异常
为什么捕获 OperationCanceledException 后 Task.Status 是 Canceled 而不是 Faulted
因为 OperationCanceledException 是唯一被 .NET 运行时特殊对待的异常：只要它是被 CancellationToken 触发的（即 exception.CancellationToken == token），Task 就会进入 Canceled 状态，而不是 Faulted。这是设计使然，不是 bug。
这意味着你不能靠 try/catch 来“吞掉”取消——即使你 catch 住了，只要没重新 throw，Task 依然算作“成功取消”。但这也带来一个坑：
- 如果在 catch 块里又抛出了别的异常（比如 log 失败），Task 会变成
Faulted，掩盖原本的取消意图 - 不要在 finally 里做可能抛异常的清理——取消路径和错误路径应尽量分离
- 判断任务是否因取消结束，请优先看
task.IsCanceled或task.Exception?.InnerExceptions.Any(e => e is OperationCanceledException)，别只依赖 catch
CancellationToken 不是魔法开关，它是一套协作协议。最常被忽略的，是你自己写的那几行检查逻辑——少一次 ThrowIfCancellationRequested()，就可能让整个取消流程失效。
