取消异步任务时 cancellationtoken 不生效的主因是未将同一令牌实例传入所有可取消的异步操作；同步代码需手动轮询 iscancellationrequested 且须在合理位置（如循环体内）检查。
取消异步任务时 CancellationToken 不生效？检查是否传入了正确实例
最常见的情况是：你调用了 Cancel()，但目标方法毫无反应。根本原因往往是「没把令牌传进真正干活的函数里」——比如只在方法签名里声明了 CancellationToken token，却在内部调用 Task.Delay(1000) 时忘了传它。
正确做法是所有可取消的异步原语（如 Task.Delay、HttpClient.GetAsync、Stream.ReadAsync）都必须显式接收并使用同一个 CancellationToken 实例：
await Task.Delay(5000, token); // ✅ 传入
await httpClient.GetAsync("https://api.example.com", token); // ✅ 传入
await stream.ReadAsync(buffer, token); // ✅ 传入
- 别自己写轮子去轮询
token.IsCancellationRequested，除非底层 API 不支持 token - 多个 await 调用之间要共用同一个
token，不能每个都 new 一个CancellationTokenSource().Token - 如果封装了自定义异步方法，务必把
CancellationToken作为参数透传到底层调用链
长时间同步操作（比如密集计算或文件读取）怎么响应取消？
同步代码不会自动响应 CancellationToken，必须手动轮询。但轮询位置很关键：不能只在循环开头检查，否则一次迭代耗时太久就失去响应性。
典型场景是处理大数组或逐块读文件：
for (int i = 0; i
- 不要只在循环外检查一次，那等于没取消逻辑
- 避免在阻塞 I/O（如
FileStream.Read）中轮询——应改用支持 token 的异步版本（ReadAsync） - 若必须用同步 I/O，可在每次读块后加
token.ThrowIfCancellationRequested()，但要注意线程上下文和超时精度
CancellationTokenSource 的生命周期管理容易出什么问题？
忘记调用 Dispose() 或过早释放 CancellationTokenSource，会导致资源泄漏或取消信号丢失。
常见错误现象：OperationCanceledException 没抛出、后续调用突然失败、GC 压力异常升高。
-
CancellationTokenSource是可释放资源，应在使用完后尽快Dispose()，尤其在短生命周期方法中 - 不要把
CancellationTokenSource.Token存到静态字段或长期缓存里——它的取消状态不可重置，失效后只能重建 - 跨线程传递时，确保
CancellationTokenSource实例未被提前Dispose()；推荐用using语句包裹 - 不要重复调用
Cancel()—— 多次调用无副作用，但暴露了设计意图混乱
为什么 Task.Run 里传了 CancellationToken 却不触发取消？
Task.Run 本身只负责调度，它不会主动监听 token 或中断线程。取消能否生效，完全取决于你传进去的委托里有没有响应逻辑。
错误写法：
Task.Run(() => {
Thread.Sleep(5000); // ❌ 同步阻塞，不响应 token
});
正确写法：
Task.Run(() => {
for (int i = 0; i
-
Task.Run(Action, CancellationToken)中的 token 仅用于「在任务启动前取消调度」，不是运行中取消的机制 - 真正在后台线程里做长时间工作，必须在委托体内手动轮询或使用支持 token 的 API
- 如果委托里有
await，记得整个方法标记为async，并把 token 传给每个 awaitable 调用
真正难的不是记住语法，而是判断「哪一层该响应取消」「谁负责释放 CancellationTokenSource」「同步路径里轮询频率够不够细」——这些地方一松懈，取消就变成摆设。
