1. 理解CancellationToken你的异步任务“紧急停止按钮”想象一下你正在用手机下载一部高清电影进度条已经走到一半突然发现下错了文件或者手机快没电了。这时候你会怎么做当然是立刻点击“取消下载”。在异步编程的世界里CancellationToken就是那个至关重要的“取消按钮”。我刚开始接触异步编程时经常遇到一个头疼的问题一个任务启动后就像脱缰的野马想停都停不下来。要么是用户点了取消但程序还在后台吭哧吭哧地跑要么是任务超时了但资源还被占用着。直到我发现了CancellationToken才真正解决了这个痛点。简单来说CancellationToken是一个轻量级的对象专门用来在异步操作之间传递“取消”信号。它不是强制终止线程那太粗暴了容易导致数据不一致或资源泄漏而是礼貌地通知任务“嘿可以停下来了请做好收尾工作。” 这是一种协作式的取消机制任务收到信号后可以决定如何优雅地结束自己。它的核心工作模式就像一个广播系统。CancellationTokenSource是广播站信号源负责创建和发出“取消”指令。而CancellationToken则是每个任务手里的收音机令牌用来监听这个指令。当你调用CancellationTokenSource.Cancel()时所有通过关联的CancellationToken注册了监听的任务都会收到这个“停止”通知。为什么这种方式比直接终止线程要好我举个例子。假设你有一个任务正在向数据库写入一批数据写到一半时被强行终止数据库可能就留下了一堆不完整的脏数据。而使用CancellationToken任务可以在收到信号后先把当前这组数据安全地提交记录好断点再释放数据库连接最后从容退出。整个过程可控、安全。2. 基础实战从零开始使用CancellationToken2.1 创建与触发你的第一个取消操作让我们从一个最简单的场景开始。假设我们有一个模拟长时间运行的任务比如从网络下载文件。用户随时可能点击取消按钮。using System; using System.Threading; using System.Threading.Tasks; class Program { static async Task Main(string[] args) { // 1. 创建“广播站” - CancellationTokenSource var cts new CancellationTokenSource(); // 2. 获取“收音机” - CancellationToken CancellationToken token cts.Token; Console.WriteLine(开始下载任务...); // 3. 启动异步任务并传入令牌 var downloadTask DownloadFileAsync(bigfile.zip, token); // 模拟用户3秒后点击取消 await Task.Delay(3000); Console.WriteLine(\n用户点击了取消按钮); // 4. 发出取消信号 cts.Cancel(); try { // 等待任务完成或被取消 await downloadTask; Console.WriteLine(下载完成); } catch (OperationCanceledException) { // 5. 处理取消异常 Console.WriteLine(下载已被用户取消。); } finally { // 6. 释放资源重要 cts.Dispose(); } } static async Task DownloadFileAsync(string fileName, CancellationToken token) { const int totalSteps 10; for (int i 0; i totalSteps; i) { // 关键一步检查是否收到取消请求 token.ThrowIfCancellationRequested(); // 模拟下载一个数据块 await Task.Delay(500, token); // 注意这里也传入了token Console.WriteLine($已下载 {((i 1) * 10)}%); } } }运行这段代码你会看到类似这样的输出开始下载任务... 已下载 10% 已下载 20% 已下载 30% 已下载 40% 已下载 50% 已下载 60% 用户点击了取消按钮 下载已被用户取消。这里有几个关键点我踩过坑需要特别注意第一ThrowIfCancellationRequested()这个方法名很直白如果取消被请求了就抛出异常。这是最常用的检查方式它会抛出一个OperationCanceledException。注意这不是一个错误而是一个正常的控制流异常表示任务是被预期取消的。第二注意Task.Delay(500, token)这行代码。很多异步方法比如HttpClient.GetAsync、Stream.ReadAsync都支持直接传入CancellationToken。这样做的好处是如果取消信号在等待期间到达这些方法能立即响应而不是傻等到时间结束。这是第一道防线。第三一定要用try-catch包裹await调用。因为取消是通过异常机制实现的不捕获的话异常会往上抛可能导致程序崩溃。OperationCanceledException是专门为这种场景设计的异常类型。第四别忘了finally块里的cts.Dispose()。CancellationTokenSource内部可能使用了定时器等资源及时释放是好习惯。更推荐的做法是使用using语句这样即使发生异常也能确保释放。2.2 两种检查方式ThrowIfCancellationRequested vs IsCancellationRequested你可能注意到了检查取消有两种方式。它们看起来相似但使用场景完全不同。让我用实际例子说明它们的区别。方式一ThrowIfCancellationRequested()- 立即停止型async Task ProcessDataImmediately(CancellationToken token) { // 在关键操作前检查 token.ThrowIfCancellationRequested(); await LoadConfigurationAsync(token); token.ThrowIfCancellationRequested(); var data await FetchDataAsync(token); token.ThrowIfCancellationRequested(); await SaveToDatabaseAsync(data, token); // 如果上面任何一处检查到取消方法会立即抛出异常退出 }这种方式适合“要么全部完成要么全部不做”的场景。比如银行转账如果中途取消我们宁愿整个操作回滚也不希望只转了一半的钱。方式二IsCancellationRequested- 优雅退出型async Task ProcessDataGracefully(CancellationToken token) { var results new Liststring(); for (int i 0; i 100; i) { // 检查但不抛出异常 if (token.IsCancellationRequested) { Console.WriteLine(检测到取消请求正在保存已处理的数据...); // 保存部分结果 await SavePartialResultsAsync(results); // 清理资源 await CleanupResourcesAsync(); Console.WriteLine(已安全退出。); return; // 正常返回不抛异常 } // 继续处理 var result await ProcessItemAsync(i, token); results.Add(result); } await SaveAllResultsAsync(results); }这种方式适合可以“部分完成”的场景。比如批量处理图片用户取消时我们已经处理好的图片应该保存未处理的就停止。那么在实际项目中该如何选择呢我的经验法则是如果任务不能被部分完成比如事务操作用ThrowIfCancellationRequested()如果任务有中间状态需要保存用IsCancellationRequested在循环中如果每次迭代都很耗时可以在循环内用IsCancellationRequested如果迭代很快用ThrowIfCancellationRequested更简洁对外公开的API通常使用ThrowIfCancellationRequested让调用者知道任务是被取消的3. 进阶模式超时控制与组合令牌3.1 内置超时让任务自动过期在实际开发中很多操作都需要超时控制。比如调用外部API如果5秒没响应就应该放弃等待而不是无限期等下去。CancellationTokenSource原生支持超时设置非常方便。async Task CallExternalApiWithTimeout() { // 方法1创建时直接指定超时时间3秒 using var cts new CancellationTokenSource(TimeSpan.FromSeconds(3)); try { var result await httpClient.GetAsync(https://api.example.com/data, cts.Token); Console.WriteLine($API调用成功: {await result.Content.ReadAsStringAsync()}); } catch (OperationCanceledException) { Console.WriteLine(请求超时3秒限制); } } async Task AnotherWayToSetTimeout() { // 方法2先创建后设置超时 using var cts new CancellationTokenSource(); // 5秒后自动取消 cts.CancelAfter(TimeSpan.FromSeconds(5)); try { // 模拟一个耗时操作 await LongRunningOperationAsync(cts.Token); } catch (OperationCanceledException) { Console.WriteLine(操作超时5秒限制); } }CancelAfter方法有个很重要的特性它是非阻塞的。调用后立即返回不会卡住当前线程。时间到了会自动触发取消。这在UI程序中特别有用不会让界面卡死。我遇到过的一个实际场景是文件上传功能。用户上传大文件时我们设置10分钟超时。如果网络太慢10分钟还没传完就自动取消并提示用户“上传超时请检查网络后重试”。用CancelAfter实现这个功能只需要一行代码。3.2 组合令牌应对复杂取消逻辑有时候一个任务可能需要响应多种取消信号。比如一个数据导出任务既要响应用户的手动取消也要在系统内存不足时自动取消还要在超过10分钟时超时取消。这时候就需要组合令牌。async Task ExportDataWithMultipleCancellationSources() { // 创建三个独立的取消源 using var userCancelSource new CancellationTokenSource(); // 用户手动取消 using var memoryMonitorSource new CancellationTokenSource(); // 内存监控取消 using var timeoutSource new CancellationTokenSource(TimeSpan.FromMinutes(10)); // 10分钟超时 // 创建关联令牌任意一个源取消组合令牌就取消 using var linkedSource CancellationTokenSource.CreateLinkedTokenSource( userCancelSource.Token, memoryMonitorSource.Token, timeoutSource.Token ); // 模拟内存监控当内存超过80%时取消 _ Task.Run(async () { while (!linkedSource.Token.IsCancellationRequested) { var memoryUsage GetMemoryUsagePercentage(); if (memoryUsage 80) { Console.WriteLine(内存使用超过80%取消导出操作); memoryMonitorSource.Cancel(); break; } await Task.Delay(1000); // 每秒检查一次 } }); try { // 使用组合令牌执行导出任务 await ExportLargeDatasetAsync(linkedSource.Token); Console.WriteLine(导出成功); } catch (OperationCanceledException ex) { // 判断是哪个原因导致的取消 if (timeoutSource.IsCancellationRequested) Console.WriteLine(导出超时超过10分钟); else if (memoryMonitorSource.IsCancellationRequested) Console.WriteLine(因内存不足取消导出); else if (userCancelSource.IsCancellationRequested) Console.WriteLine(用户取消了导出); else Console.WriteLine(导出被取消原因未知); } }CreateLinkedTokenSource这个方法非常强大它创建了一个“逻辑或”关系的组合令牌。只要传入的任意一个令牌被取消返回的链接令牌就会立即被取消。这在分布式系统或微服务架构中特别有用因为一个操作可能依赖多个服务任何一个服务失败都应该取消整个操作。我在一个电商系统中用过这个模式。用户下单后我们需要同时扣减库存库存服务创建订单订单服务扣款支付服务如果其中任何一步失败其他步骤都应该取消。用链接令牌就能完美实现这个需求。4. 高级技巧注册回调与资源清理4.1 注册取消回调最后的清理机会有些资源清理工作必须在取消发生时立即执行不能等到方法结束。比如关闭文件句柄、断开数据库连接、删除临时文件等。这时候可以使用Register方法注册回调函数。async Task ProcessWithCleanup(CancellationToken token) { // 创建一个临时文件 string tempFile Path.GetTempFileName(); Console.WriteLine($创建临时文件: {tempFile}); try { // 注册取消回调删除临时文件 using var registration token.Register(() { if (File.Exists(tempFile)) { Console.WriteLine(取消发生正在删除临时文件...); File.Delete(tempFile); Console.WriteLine(临时文件已删除); } }); // 模拟处理过程 for (int i 0; i 10; i) { token.ThrowIfCancellationRequested(); // 向临时文件写入数据 await File.AppendAllTextAsync(tempFile, $Data block {i}\n, token); Console.WriteLine($已处理 {i 1}/10); await Task.Delay(500, token); } Console.WriteLine(处理完成保存最终文件...); // 处理成功将临时文件移动到正式位置 File.Move(tempFile, final_result.txt, true); } catch (OperationCanceledException) { Console.WriteLine(操作被取消); // 注意回调已经自动执行过了这里不需要再清理 throw; } finally { // 最终检查如果临时文件还存在比如正常完成时已移动就删除 if (File.Exists(tempFile)) { File.Delete(tempFile); } } }这里有几个重要细节第一Register返回一个CancellationTokenRegistration对象它实现了IDisposable。用using语句包裹可以确保在不需要时正确注销回调。虽然不注销通常也不会内存泄漏因为CancellationTokenSource被释放时会清理所有回调但显式注销是好习惯。第二回调的执行是同步的并且在调用Cancel()的线程上执行。这意味着如果回调很耗时会阻塞取消操作的完成。所以回调函数应该尽量简单快速。第三如果注册回调时令牌已经被取消回调会立即执行。这个特性可以用来确保清理逻辑一定会执行。第四多个回调按注册顺序执行。如果你有依赖关系比如先关闭数据库连接再删除临时文件要注意注册顺序。4.2 在异步迭代器中使用取消令牌C# 8.0 引入了异步流IAsyncEnumerableT配合取消令牌可以创建可取消的数据流。public static async IAsyncEnumerableint GenerateNumbersAsync( [EnumeratorCancellation] CancellationToken token default) { for (int i 0; i 100; i) { // 每次迭代前检查取消 token.ThrowIfCancellationRequested(); // 模拟一些工作 await Task.Delay(100, token); yield return i; } } // 消费异步流 async Task ConsumeAsyncStream() { using var cts new CancellationTokenSource(TimeSpan.FromSeconds(3)); await foreach (var number in GenerateNumbersAsync(cts.Token) .WithCancellation(cts.Token)) // 这里也需要指定令牌 { Console.WriteLine($收到: {number}); // 可以在消费过程中决定取消 if (number 20) { Console.WriteLine(已收到足够数据主动取消); cts.Cancel(); break; } } }注意[EnumeratorCancellation]这个属性它允许我们在调用WithCancellation时传入新的取消令牌。这样设计很灵活生产者和消费者可以使用不同的取消逻辑。5. 实战场景在Web API和客户端中的应用5.1 ASP.NET Core Web API中的取消令牌在ASP.NET Core中控制器方法会自动接收到一个CancellationToken参数它会在客户端断开连接时自动触发取消。这个特性对于防止资源浪费特别有用。[ApiController] [Route(api/[controller])] public class DataController : ControllerBase { private readonly IDataService _dataService; public DataController(IDataService dataService) { _dataService dataService; } [HttpGet(large-report)] public async TaskIActionResult GenerateLargeReport(CancellationToken token) { try { // token会自动在以下情况被取消 // 1. 客户端关闭连接 // 2. 请求超时Kestrel默认超时时间 // 3. 服务器关闭 var report await _dataService.GenerateReportAsync(token); return Ok(report); } catch (OperationCanceledException) { // 客户端取消了请求这不是错误是正常情况 // 返回499 Client Closed Request虽然不是标准HTTP状态码但Nginx等常用 return StatusCode(499, 请求已被客户端取消); } catch (Exception ex) { // 其他真正的错误 return StatusCode(500, $服务器错误: {ex.Message}); } } } public class DataService : IDataService { public async TaskReport GenerateReportAsync(CancellationToken token) { // 将令牌传递给所有底层操作 var data await _database.FetchDataAsync(token); var processed await ProcessDataAsync(data, token); var report await FormatReportAsync(processed, token); return report; } private async TaskListData FetchDataAsync(CancellationToken token) { // 在数据库查询中传递令牌 // 支持CancellationToken的ORM如EF Core会利用它取消查询 return await _context.Data .Where(d d.IsActive) .ToListAsync(token); } }这里的关键是令牌传播。从控制器接收到的CancellationToken应该传递给所有异步操作。这样只要客户端断开连接整个调用链上的所有操作都会收到取消信号立即停止工作释放资源。我做过一个性能测试一个生成报表的接口如果不传递取消令牌即使用户在1秒后关闭页面服务器仍然会继续生成完整的报表可能耗时30秒。传递令牌后用户关闭页面时所有数据库查询、计算都会立即停止。5.2 在WinForms/WPF客户端中的应用在桌面客户端中CancellationToken通常与“取消”按钮配合使用。这里有个常见陷阱UI线程和工作线程的交互。public partial class MainForm : Form { private CancellationTokenSource _currentOperationCts; private async void btnStart_Click(object sender, EventArgs e) { // 禁用开始按钮启用取消按钮 btnStart.Enabled false; btnCancel.Enabled true; progressBar1.Value 0; // 重要每次开始新操作时创建新的CancellationTokenSource // 不要复用旧的否则可能取消错误的操作 _currentOperationCts new CancellationTokenSource(); var token _currentOperationCts.Token; try { // 启动长时间操作 await ProcessDataAsync(token); // 操作完成 MessageBox.Show(处理完成, 成功, MessageBoxButtons.OK, MessageBoxIcon.Information); } catch (OperationCanceledException) { // 用户取消了操作这不是错误 MessageBox.Show(操作已取消, 提示, MessageBoxButtons.OK, MessageBoxIcon.Information); } catch (Exception ex) { // 真正的错误 MessageBox.Show($处理失败: {ex.Message}, 错误, MessageBoxButtons.OK, MessageBoxIcon.Error); } finally { // 恢复UI状态 btnStart.Enabled true; btnCancel.Enabled false; _currentOperationCts?.Dispose(); _currentOperationCts null; } } private void btnCancel_Click(object sender, EventArgs e) { // 触发取消 _currentOperationCts?.Cancel(); btnCancel.Enabled false; } private async Task ProcessDataAsync(CancellationToken token) { for (int i 0; i 100; i) { token.ThrowIfCancellationRequested(); // 模拟工作 await Task.Delay(50, token); // 更新UI进度必须回到UI线程 if (InvokeRequired) { Invoke(new Action(() { progressBar1.Value i 1; lblStatus.Text $处理中... {i 1}%; })); } else { progressBar1.Value i 1; lblStatus.Text $处理中... {i 1}%; } } } }这个例子中有几个重要实践第一_currentOperationCts是类级别的字段这样取消按钮才能访问到它。但每次开始新操作时都要创建新的实例不能复用。第二UI更新必须回到UI线程。WinForms中可以用InvokeWPF中可以用Dispatcher.Invoke。注意检查InvokeRequired避免在UI线程上再次调用Invoke导致的死锁。第三finally块中一定要恢复UI状态并释放资源。即使用户取消了操作也要让界面回到可用的状态。第四错误处理要区分“取消”和“真正错误”。取消是正常流程不应该作为错误提示给用户。6. 性能优化与最佳实践6.1 避免过度检查的性能损耗在紧密循环中频繁检查IsCancellationRequested可能会有性能影响。虽然单次检查成本很低就是读取一个布尔值但在每秒数百万次的循环中这个开销就不可忽视了。// 不推荐的写法每次迭代都检查 async Task ProcessMillionsOfItems(ListItem items, CancellationToken token) { foreach (var item in items) // 假设有100万个item { token.ThrowIfCancellationRequested(); // 检查100万次 await ProcessItemAsync(item, token); } } // 推荐的写法每N次迭代检查一次 async Task ProcessMillionsOfItemsOptimized(ListItem items, CancellationToken token) { const int CheckInterval 1000; // 每1000次检查一次 for (int i 0; i items.Count; i) { // 每1000次迭代检查一次取消 if (i % CheckInterval 0) { token.ThrowIfCancellationRequested(); } await ProcessItemAsync(items[i], token); } // 循环结束后再检查一次确保没有遗漏 token.ThrowIfCancellationRequested(); }这个优化技巧的平衡点是响应性和性能。如果CheckInterval设得太大用户点击取消后可能要等很久才有反应。设得太小又失去了优化意义。根据我的经验对于CPU密集型循环1000到10000是个不错的范围对于IO密集型操作因为本身就有await间隙可以更频繁地检查。6.2 处理不支持取消的遗留代码现实项目中我们经常需要调用一些不支持CancellationToken的老代码或第三方库。这时候可以用一些技巧来增加取消支持。// 方法1使用Task.Run包装适合CPU密集型操作 async Task CallLegacyCodeWithCancellation(CancellationToken token) { // 将同步方法包装成Task并传入token await Task.Run(() LegacySynchronousMethod(), token); } // 方法2使用TaskCompletionSource创建可取消的包装 async Taskint CallThirdPartyApiWithTimeout(string url, CancellationToken token) { var tcs new TaskCompletionSourceint(); // 注册取消回调 using var registration token.Register(() { tcs.TrySetCanceled(token); }); // 调用不支持取消的第三方API _ Task.Run(async () { try { // 假设这是不支持取消的第三方方法 var result await ThirdPartyLibrary.MakeRequestAsync(url); tcs.TrySetResult(result); } catch (Exception ex) { tcs.TrySetException(ex); } }); return await tcs.Task; } // 方法3使用Polly等重试库的取消支持 async Task ResilientApiCall(string url, CancellationToken token) { var policy Policy .HandleHttpRequestException() .OrTimeoutException() .WaitAndRetryAsync(3, retryAttempt TimeSpan.FromSeconds(Math.Pow(2, retryAttempt))); // Polly策略天然支持CancellationToken return await policy.ExecuteAsync(async ct { var response await _httpClient.GetAsync(url, ct); response.EnsureSuccessStatusCode(); return await response.Content.ReadAsStringAsync(); }, token); }6.3 诊断与调试技巧当取消不按预期工作时调试可能会很困难。这里分享几个我常用的诊断技巧// 技巧1给CancellationTokenSource命名方便调试 var cts new CancellationTokenSource(); // 在调试器中可以看到这个名称 cts.GetType().GetField(m_name, BindingFlags.NonPublic | BindingFlags.Instance) ?.SetValue(cts, UserExportOperation); // 技巧2注册调试回调 cts.Token.Register(() { Debug.WriteLine($令牌在 {DateTime.Now:HH:mm:ss.fff} 被取消); // 可以在这里记录堆栈跟踪 Debug.WriteLine($取消调用堆栈:\n{new StackTrace()}); }); // 技巧3使用调试代理包装令牌 public class DebuggableCancellationToken { private readonly CancellationToken _token; private readonly string _operationName; public DebuggableCancellationToken(CancellationToken token, string operationName) { _token token; _operationName operationName; } public bool IsCancellationRequested { get { if (_token.IsCancellationRequested) { Debug.WriteLine($[{_operationName}] 检测到取消请求); LogCancellationSource(); } return _token.IsCancellationRequested; } } public void ThrowIfCancellationRequested() { if (_token.IsCancellationRequested) { Debug.WriteLine($[{_operationName}] 抛出取消异常); LogCancellationSource(); _token.ThrowIfCancellationRequested(); } } private void LogCancellationSource() { // 可以在这里记录更多上下文信息 Debug.WriteLine($操作 {_operationName} 被取消); } } // 使用方式 var debugToken new DebuggableCancellationToken(cts.Token, 数据导出); await ExportDataAsync(debugToken);7. 分布式系统中的取消令牌传递在微服务架构中一个用户请求可能经过多个服务。如果第一个服务取消了操作后续服务也应该知道并停止工作。这就需要跨服务传递取消令牌。7.1 通过HTTP头部传递取消信号// 客户端将取消信息放入HTTP头部 public class CancellationAwareHttpClient { private readonly HttpClient _httpClient; public async Taskstring GetWithCancellationAsync( string url, CancellationToken token, TimeSpan timeout) { using var timeoutCts new CancellationTokenSource(timeout); using var linkedCts CancellationTokenSource.CreateLinkedTokenSource( token, timeoutCts.Token); var request new HttpRequestMessage(HttpMethod.Get, url); // 将取消信息放入自定义头部 request.Headers.Add(X-Cancellation-Timeout, timeout.TotalMilliseconds.ToString()); // 可以添加请求ID用于跟踪 request.Headers.Add(X-Request-Id, Guid.NewGuid().ToString()); var response await _httpClient.SendAsync(request, linkedCts.Token); return await response.Content.ReadAsStringAsync(linkedCts.Token); } } // 服务端从头部读取取消信息 [ApiController] public class DistributedController : ControllerBase { [HttpGet(process)] public async TaskIActionResult ProcessDistributed(CancellationToken token) { // 从头部获取超时时间如果有 if (Request.Headers.TryGetValue(X-Cancellation-Timeout, out var timeoutStr)) { if (long.TryParse(timeoutStr, out var timeoutMs)) { // 创建带超时的链接令牌 using var timeoutCts new CancellationTokenSource( TimeSpan.FromMilliseconds(timeoutMs)); using var linkedCts CancellationTokenSource.CreateLinkedTokenSource( token, timeoutCts.Token); return await ProcessWithTimeoutAsync(linkedCts.Token); } } // 没有超时头部使用原始令牌 return await ProcessAsync(token); } private async TaskIActionResult ProcessWithTimeoutAsync(CancellationToken token) { // 调用其他服务时传递令牌 var result1 await _serviceA.ProcessAsync(token); var result2 await _serviceB.ProcessAsync(token); return Ok(new { result1, result2 }); } }7.2 使用Polly实现弹性取消策略public class ResilientServiceClient { private readonly IAsyncPolicy _retryPolicy; public ResilientServiceClient() { _retryPolicy Policy .HandleHttpRequestException() .OrTimeoutException() .OrOperationCanceledException() // 注意这里要区分是超时取消还是用户取消 .WaitAndRetryAsync( retryCount: 3, sleepDurationProvider: retryAttempt { // 指数退避 return TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)); }, onRetry: (exception, timeSpan, retryCount, context) { // 如果是取消异常判断是否应该重试 if (exception is OperationCanceledException oce) { // 如果是超时导致的取消可以重试 // 如果是用户主动取消不应该重试 if (oce.CancellationToken context.PolicyKey) { // 这是策略超时可以重试 Log.Warning($请求超时第{retryCount}次重试...); } else { // 这是用户取消不应该重试 Log.Information(用户取消了请求停止重试); throw; // 重新抛出停止重试 } } }); } public async Taskstring CallServiceWithResilienceAsync( string url, CancellationToken userToken) { // 创建策略超时比如每个请求最多等5秒 var perRequestTimeout TimeSpan.FromSeconds(5); return await _retryPolicy.ExecuteAsync(async (ct) { using var requestCts new CancellationTokenSource(perRequestTimeout); using var linkedCts CancellationTokenSource.CreateLinkedTokenSource( ct, requestCts.Token, userToken); var response await _httpClient.GetAsync(url, linkedCts.Token); return await response.Content.ReadAsStringAsync(linkedCts.Token); }, userToken); // 将用户令牌作为策略上下文 } }这个模式的关键是区分不同类型的取消用户主动取消不应该重试立即失败网络超时取消应该重试策略超时取消应该重试通过OperationCanceledException中的CancellationToken可以判断取消的来源。8. 常见陷阱与解决方案8.1 陷阱一忘记传递令牌这是最常见的错误。你创建了CancellationTokenSource但在调用深层方法时忘记传递令牌。// 错误示例令牌没有传递下去 async Task ProcessOrderAsync(CancellationToken token) { // 这里检查了令牌 token.ThrowIfCancellationRequested(); // 但是调用子方法时忘记传递了 var user await _userService.GetUserAsync(order.UserId); // 这里应该传token var inventory await _inventoryService.CheckAsync(order.ProductId); // 这里也应该传 // 结果即使token被取消这些子调用还会继续执行 } // 正确做法始终传递令牌 async Task ProcessOrderAsync(CancellationToken token) { token.ThrowIfCancellationRequested(); // 将令牌传递给所有异步调用 var user await _userService.GetUserAsync(order.UserId, token); var inventory await _inventoryService.CheckAsync(order.ProductId, token); // 即使这里被取消子调用也会收到信号 }我的经验是在方法签名中加上CancellationToken token default参数这样调用者可以选择是否传递。在方法内部把这个令牌传递给所有支持取消的异步调用。8.2 陷阱二在finally块中执行长时间操作// 危险示例finally中的阻塞操作 async Task DangerousFinallyAsync(CancellationToken token) { try { await DoWorkAsync(token); } finally { // finally块中的代码在取消后仍然会执行 // 但如果这里也有异步操作可能会被取消 await CleanupAsync(); // 如果token已取消这里可能抛出异常 } } // 更好的做法使用单独的清理令牌 async Task SafeFinallyAsync(CancellationToken token) { // 创建链接令牌但给清理操作更多时间 using var cleanupCts new CancellationTokenSource(TimeSpan.FromSeconds(30)); using var linkedCts CancellationTokenSource.CreateLinkedTokenSource( token, cleanupCts.Token); try { await DoWorkAsync(linkedCts.Token); } finally { // 清理操作使用独立的超时而不是用户令牌 try { await CleanupAsync(cleanupCts.Token); } catch (OperationCanceledException) { // 清理操作超时了记录日志但不要抛出 Log.Warning(清理操作超时但已尽力而为); } } }8.3 陷阱三没有处理AggregateException中的取消当使用Task.WhenAll等待多个任务时如果多个任务都取消了会抛出AggregateException里面包含多个OperationCanceledException。// 错误处理方式 try { await Task.WhenAll(task1, task2, task3); } catch (OperationCanceledException) // 这里抓不到AggregateException { Console.WriteLine(任务被取消); } // 正确处理方式 try { await Task.WhenAll(task1, task2, task3); } catch (OperationCanceledException) { Console.WriteLine(单个任务被取消); } catch (AggregateException agEx) { // 检查是否所有内部异常都是取消异常 if (agEx.InnerExceptions.All(ex ex is OperationCanceledException)) { Console.WriteLine(所有任务都被取消); } else { // 有其他类型的异常 throw; } }在实际项目中我通常会写一个辅助方法来统一处理这种复杂情况public static async Task WhenAllWithCancellationHandling( IEnumerableTask tasks, CancellationToken token) { var taskList tasks.ToList(); try { await Task.WhenAll(taskList).WaitAsync(token); } catch (OperationCanceledException) when (token.IsCancellationRequested) { // 外部令牌取消等待所有任务完成或取消 await Task.WhenAll(taskList.Select(t t.ContinueWith(_ { }, TaskContinuationOptions.ExecuteSynchronously))); // 检查任务状态 var canceledCount taskList.Count(t t.IsCanceled); var faultedCount taskList.Count(t t.IsFaulted); var completedCount taskList.Count(t t.IsCompletedSuccessfully); Log.Information($取消统计: {canceledCount}取消, {faultedCount}失败, {completedCount}完成); throw; } }掌握CancellationToken需要一些实践但一旦习惯你会发现它能让你的异步代码更加健壮和可控。关键是要记住取消是协作式的不是命令式的。你的代码需要主动检查取消信号并做出恰当的响应。从简单的单任务取消到复杂的分布式取消传播CancellationToken提供了一套统一的模式来处理各种取消场景。在实际项目中我建议从简单的超时控制开始逐步应用到更复杂的场景最终形成一套完整的取消策略。