在 Blazor 应用开发过程中，异步操作几乎贯穿了数据加载、接口调用以及后台计算等核心场景。当组件因为用户导航或参数变化而被销毁时，那些已经发起但还没有结束的异步任务若不被及时中止，就会继续消耗线程资源，甚至试图修改已经不存在的组件状态，从而抛出 ObjectDisposedException 或引发难以排查的渲染异常。CancellationToken 作为 .NET 提供的协作式取消机制，能够让异步方法感知到调用方的取消意图，并主动释放资源退出执行。在 Blazor 的组件模型中，合理地把令牌与生命周期绑定，是构建稳定应用的关键一步。
Blazor 组件生命周期与取消信号的来源
Blazor 的组件从加载到卸载会经历一系列生命周期方法，其中 OnInitialized、OnParametersSet、OnAfterRender 等常用于触发异步逻辑。当组件从 UI 树中移除时，框架会调用 IDisposable.Dispose 方法（如果组件实现了 IDisposable 或 IAsyncDisposable）。这个销毁时机正是发出取消信号的最佳节点，因为此时组件已经不再需要任何后台任务的结果。
如果我们在组件中直接调用 HttpClient.GetAsync 而不传入令牌，那么即使组件被销毁，HTTP 请求仍会在底层完成，返回的结果在到达时由于组件已释放，赋值给组件字段就会出错。相反，通过在生命周期末尾释放 CancellationTokenSource，可以让所有持有对应令牌的异步方法在下一个检查点抛出 OperationCanceledException，从而自然终止。理解这种“销毁即取消”的映射关系，是正确使用令牌的前提。
需要注意的是，Blazor 服务端托管模型与 WebAssembly 托管模型在生命周期取消上行为一致，但服务端由于连接可能断开，框架还会在电路断开时统一取消相关资源，因此开发者自己管理的令牌源仍不可省略，它是更细粒度的控制手段。
在组件中创建与传递 CancellationToken 的常规写法
最常见的模式是在组件类中声明一个私有的 CancellationTokenSource 字段，在 OnInitialized 或 OnParametersSet 中创建实例，并把它的 Token 属性传给异步方法。组件销毁时在 Dispose 中取消并释放该源。这样可以保证每次组件初始化都有独立的取消范围，避免不同参数刷新之间的任务互相干扰。
下面这段 C# 代码展示了基础用法：在初始化时建立令牌源，在加载数据时使用令牌，在 Dispose 中取消。注意 _cts.Token 被传入 GetAsync，并且用 await using 或显式调用保证释放。
using System;
using System.Net.Http;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Components;
public class UserPanelBase : ComponentBase, IDisposable
{
private CancellationTokenSource _cts = new CancellationTokenSource();
protected string UserInfo { get; set; } = "加载中...";
[Inject]
protected HttpClient Http { get; set; }
protected override async Task OnInitializedAsync()
{
try
{
var response = await Http.GetAsync("https://ipipp.com/api/user", _cts.Token);
response.EnsureSuccessStatusCode();
UserInfo = await response.Content.ReadAsStringAsync(_cts.Token);
}
catch (OperationCanceledException)
{
UserInfo = "已取消";
}
}
public void Dispose()
{
if (_cts != null)
{
_cts.Cancel();
_cts.Dispose();
_cts = null;
}
}
}
上述写法虽然简单，但如果组件因参数变化而重新初始化，旧的 _cts 若未取消就直接覆盖，会导致旧任务失去取消能力。因此更严谨的做法是在 OnParametersSet 开头先取消并重建源，确保每次参数变更都对应新的取消范围。同时，捕获异常时应区分取消与其他错误，避免把取消当作普通失败记录日志。
结合组件参数刷新与多层异步调用的令牌传播
实际业务中，组件往往会在 OnParametersSetAsync 中根据传入参数重新拉取数据。这时如果每次刷新都新建令牌源，就要注意取消上一次还未完成的请求。我们可以在设置新参数时调用 _cts.Cancel()，然后新建源，从而让旧任务快速失败，防止旧数据覆盖新数据。这种“取消上一轮”的策略在搜索框联想、分页切换等高频刷新场景中尤为重要。
当异步逻辑被拆分到多个服务层方法时，令牌必须沿着调用链一路传递，而不是在中间层忽略。例如组件调用 UserService.LoadAsync(token)，该方法内部再调用 HttpClient 或 Task.Delay 时都应传入同一个 token。如果某一层没有传递，那一层就无法被取消，形成取消盲区。下面的例子演示了三层调用中令牌的透传：
public class UserService
{
private readonly HttpClient _http;
public UserService(HttpClient http) { _http = http; }
public async Task<string> LoadAsync(int id, CancellationToken token)
{
await Task.Delay(100, token); // 模拟预处理，可被取消
var resp = await _http.GetAsync($"https://ipipp.com/api/user/{id}", token);
return await resp.Content.ReadAsStringAsync(token);
}
}
public class ProfileComponent : ComponentBase, IDisposable
{
private CancellationTokenSource _cts = new();
[Parameter] public int UserId { get; set; }
protected string Data { get; set; }
[Inject] UserService Service { get; set; }
protected override async Task OnParametersSetAsync()
{
_cts.Cancel();
_cts = new CancellationTokenSource();
try
{
Data = await Service.LoadAsync(UserId, _cts.Token);
}
catch (OperationCanceledException) { }
}
public void Dispose() { _cts.Cancel(); _cts.Dispose(); }
}
除了手动传递，Blazor 还提供了 IComponentContext 之类的扩展机制（部分版本通过自定义逻辑实现），可把当前组件的取消令牌注入到依赖服务中，减少逐层传参的样板代码。但在官方基础 API 层面，显式传递依然是最清晰、最可控的方式。对于长时间轮询，也可以结合 Task.WhenAny 与令牌，在组件销毁时立即退出循环，避免无谓的网络流量。
最后需要提醒的是，CancellationToken 本身是不可逆且结构轻量的，但 CancellationTokenSource 属于非托管资源，必须释放。若组件频繁创建却不释放，会造成句柄与内存压力。在 Blazor WebAssembly 中虽无服务端连接问题，但取消能显著提升响应速度与电池续航，同样不应忽视。
BlazorCancellationToken组件生命周期修改时间：2026-08-15 12:54:33