Server-side Blazor按钮重复点击：Task.Yield()是否为正确解决方案？

你的问题本质是同步阻塞导致UI更新延迟：原代码里IncrementCount方法中的Thread.Sleep(300)是同步阻塞操作，会占用Blazor的渲染线程，导致按钮禁用的UI更新要等整个同步代码执行完才触发。用户在这300ms内双击，第二次点击会在按钮还没禁用时被触发，进而重复执行逻辑。

Task.Yield()为什么能解决问题？ #

await Task.Yield()会让异步方法暂时交出控制权，把后续代码放到线程池队列等待执行。此时Blazor的渲染线程会先处理UI更新（把按钮设为禁用），之后再执行Thread.Sleep(300)。这样用户双击时，第二次点击会遇到已禁用的按钮，无法触发。

但这只是临时的变通方案，并非最优解——Thread.Sleep本身是同步阻塞，会浪费Blazor的线程资源（Server-side Blazor的线程池是共享的，阻塞线程会影响其他用户请求）。

更可靠的解决方案 #

推荐用异步等待+显式状态管理的组合，从根源避免问题：

1. 用await Task.Delay()替代Thread.Sleep()，让方法全程异步，不阻塞线程。
2. 单独用布尔变量管理按钮的处理状态，和业务逻辑解耦，同时添加异常保障。

修改后的代码示例：

@page "/counter"

<PageTitle>Counter</PageTitle>

<h1>Counter</h1>

<p role="status">Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount" disabled="@isProcessing">Click me</button>

@code {
    private int currentCount = 0;
    private bool isProcessing = false;

    private async Task IncrementCount()
    {
        // 额外防护：如果正在处理，直接返回
        if (isProcessing) return;
        
        isProcessing = true;

        try
        {
            currentCount++;
            await Task.Delay(300); // 异步等待，不阻塞线程
        }
        finally
        {
            // 无论是否异常，都恢复按钮状态
            isProcessing = false;
        }
    }
}

这个方案的优势 #

• 状态解耦：isProcessing专门管理按钮禁用状态，不依赖业务变量（比如currentCount），逻辑更清晰。
• 线程友好：Task.Delay是异步操作，不会占用线程池资源，不影响其他用户请求。
• 异常安全：finally块确保即使异步操作抛出异常，按钮也能恢复可用，避免永久禁用。
• 双重防护：开头的if (isProcessing) return能在UI更新前拦截重复点击，彻底杜绝重复触发。

总结：Task.Yield()能解决当前问题，但不是规范做法。更推荐使用异步等待+显式状态管理的方案，既保证功能正确，又符合Blazor的异步编程模型。

内容的提问来源于stack exchange，提问作者StefanFFM