C#中任务取消的协作式原理是通过CancellationTokenSource发送取消信号，任务需主动检查CancellationToken或调用ThrowIfCancellationRequested响应，而非强制终止。
C#中，
CancellationTokenSource提供了一种优雅且协作式的机制来取消正在执行的任务。它不是强制中断，而是向任务发出“请停止”的信号，任务本身需要主动监听并响应这个信号。这就像你给一个正在工作的同事发消息说“你手头的事可以先放下了”，至于他什么时候放下，以什么方式放下，最终还是由他自己决定和执行。
要实现任务取消，我们通常会遵循一套流程。 首先，你需要创建一个
CancellationTokenSource的实例。这个对象就是取消操作的“发令员”。
var cts = new CancellationTokenSource();
接着，从
CancellationTokenSource中获取一个
CancellationToken。这个
Token就像一张通行证，你需要把它传递给你想要取消的任务或方法。
CancellationToken token = cts.Token;
在你的任务或长时间运行的方法内部，你需要周期性地检查这个
Token的状态。最直接的方式是检查
token.IsCancellationRequested属性。
// 示例：一个长时间运行的任务
Task.Run(() =>
{
while (true)
{
if (token.IsCancellationRequested)
{
Console.WriteLine("任务收到取消请求，准备退出...");
// 在这里执行一些清理工作
break; // 退出循环
}
Console.WriteLine("任务正在执行...");
Thread.Sleep(500); // 模拟耗时操作
}
}, token); // 也可以将token传递给Task.Run，这样如果token被取消，Task会进入Canceled状态更推荐的做法是使用
token.ThrowIfCancellationRequested()方法。当
Token被取消时，这个方法会立即抛出一个
OperationCanceledException。这种方式能更简洁、更符合异常处理范式地中断任务执行。
Task.Run(() =>
{
try
{
for (int i = 0; i < 100; i++)
{
token.ThrowIfCancellationRequested(); // 如果取消，这里会抛异常
Console.WriteLine($"任务执行到第 {i} 步...");
Thread.Sleep(200);
}
}
catch (OperationCanceledException)
{
Console.WriteLine("任务因取消请求而终止。");
}
}, token);当你想取消任务时，只需调用
CancellationTokenSource实例的
Cancel()方法即可。
cts.Cancel();
最后，别忘了
CancellationTokenSource实现了
IDisposable接口。用完之后，最好调用
Dispose()方法释放资源，或者更常见的做法是将其包裹在
using语句中。
using (var cts = new CancellationTokenSource()) { /* ... */ }C#中任务取消的协作式原理是什么？
我们谈到
CancellationTokenSource，很多人会把它想象成一个“急停按钮”，一按任务就立马停了。但实际上，它更像是一个“请示停止”的信号灯。这背后的核心理念就是“协作式取消”。与过去
Thread.Abort()那种粗暴、不安全的强制终止方式（现在已经废弃，也不推荐使用）截然不同，协作式取消要求被取消的任务本身要“配合”。
微信公众平台开发入门教程 中文WORD版
下载
由于微信的大热，为了更好的方便使用微信的用户查询一些信息，这篇文章是入门级的微信公众平台开发教程，需要的朋友可以参考下 这篇入门教程将引导你完成如下任务： 创建百度云平台应用启用微信公众平台开发模式获取订阅、文字、图片、语音、视频消息回复文本、图文及音乐消息程序开发
简单来说，
CancellationTokenSource发出的
CancellationToken只是一个请求，一个意图。任务代码内部必须主动去检查这个
Token的状态，并根据
IsCancellationRequested的值或者
ThrowIfCancellationRequested()抛出的异常来决定何时、何地停止执行。这种设计，在我看来，是C#并发编程中一个非常成熟和负责任的选择。它避免了强制终止可能带来的各种问题，比如资源泄露（文件句柄、网络连接没来得及关闭）、数据损坏（操作进行到一半，数据处于不一致状态），以及死锁等难以预料的副作用。
通过协作，任务可以在收到取消请求时，有机会完成当前的原子操作、释放已持有的资源、回滚未提交的事务，或者至少记录下当前状态，然后才优雅地退出。这给了开发者极大的控制权，确保了程序的健壮性和稳定性。当然，这也意味着如果你的任务代码里没有检查
CancellationToken，那么即便你调用了
Cancel()，任务也可能会继续运行，直到它自然结束。所以，开发者在编写长时间运行或可取消的任务时，肩负着主动响应取消请求的责任。
在异步方法中如何正确捕获和处理OperationCanceledException？
当
CancellationToken被取消，并且你的代码中调用了
ThrowIfCancellationRequested()，或者你将
CancellationToken传递给了
Task.Run、
HttpClient.GetAsync等支持取消的方法，那么当取消发生时，通常会抛出
OperationCanceledException。处理这种异常，我觉得需要一些特别的思考，因为它和我们平时处理的“错误”不太一样。
OperationCanceledException并不是一个指示程序出错的信号，它更多的是一种预期的控制流。它表明任务按照设计被取消了，这通常不是一个需要崩溃或记录为严重错误的情况。因此，在
async/await结构中，我们应该用
try-catch块来捕获它，并进行适当的处理，而不是让它传播出去导致程序崩溃。
看一个例子：
public async Task DoSomethingCancellableAsync(CancellationToken token)
{
try
{
Console.WriteLine("异步任务开始...");
for (int i = 0; i < 10; i++)
{
token.ThrowIfCancellationRequested(); // 检查取消
await Task.Delay(500, token); // 这里的Task.Delay也支持取消
Console.WriteLine($"异步任务进行到 {i + 1} 步。");
}
Console.WriteLine("异步任务完成。");
}
catch (OperationCanceledException ex)
{
// 这是一个预期的取消，不是错误
Console.WriteLine($"异步任务被取消了: {ex.Message}");
// 在这里可以进行一些清理工作，比如关闭文件、释放网络连接等
// 如果需要，可以重新抛出，但通常不需要
// throw;
}
catch (Exception ex)
{
// 处理其他非取消引起的错误
Console.WriteLine($"异步任务发生未知错误: {ex.Message}");
}
finally 
