异步函数中何时可省略await关键字？

你对await的理解偏差 #

你以为await是让异步函数“同步执行”，这是关键错误。await的本质是暂停当前的async方法，将线程释放回线程池，等异步操作完成后，再从暂停的位置继续执行当前方法的后续代码。它和真正的同步阻塞（比如调用.Result或.Wait()）完全不同——同步阻塞会死死占用线程不放，而await是“让出线程”，这才是异步编程提升系统吞吐量的核心逻辑。

比如你写的这段代码：

await MyAsyncMethod();
await MyOtherAsyncMethod();

它不是“同步执行两个异步方法”，而是顺序执行两个异步操作，但每个异步操作执行时都不会阻塞线程。如果MyAsyncMethod是IO密集型操作（比如数据库读写），await会把线程还给线程池，让线程去处理其他请求，等数据库操作完成后再回来执行下一行代码。

为什么编辑器警告你要加await？ #

直接调用NotifySubscribersAsync()而不await，会导致几个严重问题：

• 无法捕获异步方法的异常：如果NotifySubscribersAsync内部抛出异常，这个异常会在后台线程中触发，你的try/catch块根本抓不到它，最终可能导致进程崩溃（.NET Core早期版本）或者引发未观察任务异常，完全不可控。
• 任务生命周期不受控：如果Web应用进程在邮件发送过程中被回收（比如应用重启、容器缩放），这个后台任务会被直接终止，邮件发送失败且你无法感知。
• 违反异步编程规范：编译器警告是在提醒你“启动了异步任务但未跟踪其状态”，这几乎都是潜在bug的源头。

你的场景该怎么正确处理？ #

你想要的是“返回成功给用户，同时后台执行邮件发送”，但直接丢弃Task是错误的做法，推荐两种正确实现方式：

方式1：使用托管后台服务（生产环境首选） #

如果邮件发送是长期运行的后台任务，应该用.NET的BackgroundService结合消息队列（内存队列、RabbitMQ等）处理。把邮件任务放入队列，后台服务从队列中取出任务执行，即使Web进程重启，任务也不会丢失。

简化示例代码：

// 构造函数注入消息队列服务
private readonly IEmailTaskQueue _emailTaskQueue;

public async Task<IActionResult> Create(Blogpost blogpost)
{
  try 
  {
     await CreateBlogPostAsync(blogpost);
     // 将邮件任务加入队列
     await _emailTaskQueue.QueueEmailTaskAsync(() => NotifySubscribersAsync(blogpost));

     return Ok(blogpost);
  }
  catch
  {
    return StatusCode(500);
  }
}

// 后台服务实现
public class EmailBackgroundService : BackgroundService
{
    private readonly IEmailTaskQueue _emailTaskQueue;
    private readonly ILogger<EmailBackgroundService> _logger;

    public EmailBackgroundService(IEmailTaskQueue emailTaskQueue, ILogger<EmailBackgroundService> logger)
    {
        _emailTaskQueue = emailTaskQueue;
        _logger = logger;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            var emailTask = await _emailTaskQueue.DequeueAsync(stoppingToken);
            try
            {
                await emailTask();
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "邮件发送任务执行失败");
                // 可添加重试逻辑
            }
        }
    }
}

方式2：捕获异步任务异常（临时简单场景用） #

如果只是小型测试场景，不想引入队列，至少要捕获异步任务的异常，避免进程崩溃：

public async Task<IActionResult> Create(Blogpost blogpost)
{
  try 
  {
     await CreateBlogPostAsync(blogpost);
     // 启动后台任务并捕获异常
     _ = NotifySubscribersAsync().ContinueWith(task =>
     {
         if (task.IsFaulted)
         {
             // 记录异常日志
             // _logger.LogError(task.Exception, "邮件发送失败");
         }
     }, TaskContinuationOptions.OnlyOnFaulted);

     return Ok(blogpost);
  }
  catch
  {
    return StatusCode(500);
  }
}

这种方式仍存在进程终止丢失任务的问题，但至少不会因为未处理异常导致进程崩溃。

总结 #

• await不是让异步变同步，而是非阻塞地等待异步操作完成，这是异步编程的核心。
• 绝不要直接丢弃异步Task，否则会丢失异常和任务状态。
• 生产环境的后台任务，优先用托管服务+消息队列的方式保证可靠性。

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