.NET WebAPI中移除SendEmail调用的await关键字存在哪些风险？

上下文代码：

public async Task CheckOut(CheckOutData checkOutData){
     // 其他业务逻辑
     // What are the risks if I remove the await
     await SendEmail(checkOutData);
     // 其他业务逻辑
}

public async Task SendEmail(CheckOutData checkOutData)
{
  try{
      // 邮件发送逻辑
  }
  catch (Exception ex){
      // 记录错误日志
  }
}

只要你的WebAPI服务进程没有触发回收、重启、退出等操作，未等待的SendEmail任务默认不会被主动终止：

• .NET Core / .NET 5+ 版本的ASP.NET没有请求上下文绑定的任务终止机制，请求结束后，未await的异步任务只要还在执行或排队，线程池会继续调度运行，直到任务完成
• 但如果遇到服务发布、进程崩溃、容器缩容等场景，所有未完成的后台任务都会被强制终止，此时会出现邮件发送失败的情况

依然存在多个潜在风险，包括但不限于：

• Scoped服务释放问题：如果SendEmail方法内依赖了请求Scoped生命周期的服务（比如注入的DbContext、请求级别的自定义服务等），CheckOut方法执行完成代表当前请求的Scope已经被销毁，此时SendEmail如果再调用这些Scoped服务，会直接抛出ObjectDisposedException，即便你内部捕获了异常，邮件也会发送失败
• 线程池资源积压风险：如果你的CheckOut接口并发量较高，且SendEmail执行耗时较长（比如SMTP服务器响应慢、网络波动），大量未等待的后台任务会占用线程池工作线程/IO线程资源，导致正常接口请求的调度被阻塞，出现接口响应超时、吞吐量下降的问题
• 异常覆盖风险：如果SendEmail内部的异常捕获逻辑存在遗漏（比如异步任务嵌套时的异常未被捕获、非托管代码抛出的异常未被捕获等），未被观察的Task异常在部分.NET Framework版本中会直接导致进程崩溃；.NET Core+版本虽然默认不会终止进程，但依然会被写入系统日志，可能触发运维告警
• 故障补偿能力缺失：即发即弃模式下，你无法对发送失败的邮件做自动重试、补偿逻辑，只能事后通过日志排查，用户感知会受到影响

如果你不希望发邮件的逻辑阻塞CheckOut的响应流程，不要直接移除await使用即发即弃，建议使用.NET内置的后台任务队列（IHostedService实现）来托管发邮件的逻辑，将发邮件的请求丢到队列中由独立的后台服务消费执行，既不会阻塞接口响应，也能规避上述风险。

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