技术问询：await链顶端应采用async void还是Task.Wait()？

Great question! The "async all the way" principle is key to avoiding deadlocks and keeping your async code predictable, but the top of your await chain doesn’t have to be limited to async void or Task.Wait(). The right approach depends entirely on the context of your entry point. Let’s break down the most common scenarios:

1. UI Event Handlers (WPF, WinForms, etc.) #

This is the classic case where async void is acceptable (and often necessary). UI event handlers have a fixed signature that requires a void return type, so you can’t return a Task directly.

Just remember: async void has unique behavior around exceptions—unhandled exceptions will crash your app instead of being propagated up the call stack. Always wrap your async code in a try/catch block here:

private async void SubmitButton_Click(object sender, RoutedEventArgs e)
{
    try
    {
        await SaveFormDataAsync();
        MessageBox.Show("Save successful!");
    }
    catch (Exception ex)
    {
        MessageBox.Show($"Save failed: {ex.Message}");
    }
}

2. Console Applications #

Older versions of .NET (pre-.NET Core 3.0) didn’t support async Main methods, so developers often resorted to Task.Wait() or Task.Result to block the main thread until async work completed. But this carries deadlock risks in contexts with a SynchronizationContext (though consoles don’t have one, so it’s safer here).

Thankfully, modern .NET (Core 3.0+) lets you use an async Main directly, which is the cleanest approach:

public static async Task Main(string[] args)
{
    await RunApplicationAsync();
    // No need for Wait()—the runtime handles waiting for the Task to complete
}

3. ASP.NET Core (Kestrel, Controllers, Middleware) #

Here, you almost never need async void or Task.Wait(). The entire ASP.NET Core framework is built for async, so entry points like controller actions, middleware methods, or background services can return Task or Task<T> directly. The framework automatically awaits these tasks for you:

[HttpGet("/api/data")]
public async Task<IActionResult> GetData()
{
    var data = await _dataRepository.FetchLatestAsync();
    return Ok(data);
}

No blocking, no async void—just follow the framework’s async patterns, and it handles the top-level await.

4. Background Services (IHostedService) #

For long-running background tasks in .NET, IHostedService’s ExecuteAsync method is designed to return a Task. The host will await this task for the lifetime of the service, so again, no need for async void or blocking calls:

public class Worker : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            await DoWorkAsync();
            await Task.Delay(TimeSpan.FromMinutes(5), stoppingToken);
        }
    }
}

Key Takeaways #

• async void should be a last resort, only used when the entry point signature forces a void return (like UI events). Always handle exceptions explicitly here.
• Task.Wait()/Task.Result are compromises for old environments—avoid them in modern code where async entry points are supported.
• Whenever possible, return Task/Task<T> from your top-level async method and let the runtime or framework handle awaiting it. This keeps your code consistent with "async all the way" and avoids blocking.

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