Blazor Server 的事件处理默认不是线程安全的
Blazor Server 使用 SignalR 长连接通信，所有 UI 事件（如
@onclick）都在同一个逻辑“请求上下文”中同步执行，但不等于线程安全。多个用户操作或快速连续点击可能触发并发调用，而组件实例是按用户会话单例复用的，
StateHasChanged()和字段更新若未加防护，会导致状态错乱或
ObjectDisposedException。 常见错误现象：
System.ObjectDisposedException: Cannot access a disposed object，尤其在异步操作完成前组件已卸载 典型场景：按钮连续点击触发同一
async Task方法；后台任务（如
Timer）更新组件字段后调用
StateHasChanged()关键限制：Blazor Server 不允许从非渲染线程直接调用
StateHasChanged()—— 必须通过
InvokeAsync()
用 InvokeAsync()
包裹所有跨上下文的状态更新
即使你在
async方法中 await 了外部服务，回调一旦脱离原始渲染上下文（例如从
Task.Run、
Timer或第三方库回调中返回），就必须显式切回组件上下文才能安全更新状态或触发重绘。
private async Task HandleClick()
{
// ❌ 危险：若 DoWorkAsync 内部用了 Task.Run 或延迟回调，后续更新可能并发
var result = await DoWorkAsync();
currentData = result;
StateHasChanged(); // 可能抛 ObjectDisposedException
// ✅ 正确：确保所有 UI 更新都经 InvokeAsync 调度
await InvokeAsync(() =>
{
currentData = result;
StateHasChanged();
});
}
InvokeAsync(Action)是线程安全的入口，Blazor 会排队执行并自动忽略已销毁组件的调用 不要对每个字段赋值都单独调用
InvokeAsync；合并到一个委托里减少调度开销 如果方法本身被多次快速调用，仅靠
InvokeAsync不足以防重复提交 —— 还需业务层节流或禁用按钮
避免在事件处理中裸写 Task.Run
或长时间运行同步代码
Blazor Server 渲染线程（即
SynchronizationContext）是单线程的。在事件处理器里直接调用阻塞式 IO 或 CPU 密集型代码（如
Thread.Sleep、大数组排序、XML 解析），会卡住整个用户的会话通道，影响响应甚至引发超时断连。 错误示例：
Task.Run(() => { Thread.Sleep(2000); return GetData(); }) —— 没解决根本问题，反而增加线程调度负担
正确做法：将真正耗时操作移至后台服务（如 IHostedService），用
Channel<t></t>或
EventCallback通知组件；或使用真正异步 API（
HttpClient.GetAsync、
Stream.ReadAsync） 若必须同步计算，至少加取消检查：
if (CancellationToken.IsCancellationRequested) return;，并在组件
Dispose时传递取消令牌
用 CancellationToken
主动取消挂起的异步操作
用户导航离开页面、组件被销毁后，未完成的
await任务仍可能继续执行，并在完成后尝试调用
InvokeAsync—— 此时组件已释放，
InvokeAsync会静默丢弃该调用，但后台任务仍在浪费资源。
private CancellationTokenSource? _cts;
protected override void OnInitialized()
{
_cts = new();
}
private async Task LoadData()
{
try
{
var data = await _api.GetDataAsync(_cts.Token); // 传入 token
await InvokeAsync(() =>
{
items = data;
StateHasChanged();
});
}
catch (OperationCanceledException)
{
// 被主动取消，无需处理
}
}
public void Dispose()
{
_cts?.Cancel();
_cts?.Dispose();
}
每次启动新异步操作前应取消旧的 CancellationTokenSource，防止竞态残留 不要依赖
IsDisposed判断组件状态 ——
InvokeAsync已内置防护，重点是及时取消上游 I/O 第三方库若不支持
CancellationToken，考虑用
Task.WaitAsync(TimeSpan, CancellationToken)包装超时 Blazor Server 的并发风险不在“多线程争抢”，而在“生命周期与异步生命周期错位”。最易被忽略的是：**你以为的“顺序执行”其实依赖于 SignalR 消息到达顺序和服务器端队列调度，而非代码书写顺序**。任何绕过
InvokeAsync的 UI 更新、任何未绑定取消令牌的 await、任何未清理的后台计时器，都会在高交互场景下暴露问题。
