据我了解，C# 中的 async/await 功能将 await 调用之间的段拆分为运行在在每个等待的方法在单独的工作线程上返回后调用线程。调用线程在等待期间是“空闲的”。必须通过某种事件循环在调用线程上安排回调。
此事件循环仅存在于 GUI 应用程序中，例如 Windows 窗体或 WPF。释放此循环可确保 UI 在长时间操作期间对其他用户交互保持响应。
控制台应用程序和网络应用程序 (ASP.NET) 没有此类事件循环，因此此回调机制不起作用。但话又说回来，他们没有事件循环，因为他们不需要。任何时候都没有用户试图与正在运行的程序进行交互，并期待立即得到反馈。所以没有必要为此释放调用线程。操作使用多少线程并不重要，它只会在最后一位完成后返回。
那么 async 和 await 在控制台和网络应用程序中有什么用，或者任何类型的非交互式代码，例如 Windows 服务？与简单的同步调用相比，这有何不同或更高效？
我正在设计一个由 GUI 和非交互式(服务和网络)程序使用的 API，并且很难理解它在非 GUI 环境中的行为方式。
最佳答案
async-await 的要点是当您到达第一个异步点(即未完成任务的第一个 await)时，调用线程总是被释放。
在 UI 应用程序中，您有一个 SynchronizationContext，它将等待后的代码发布到 UI 线程，因为与 UI 交互的代码必须由 UI 线程执行，否则您将获得异常。您可以使用 ConfigureAwait(false) 来控制它。
在控制台应用程序(和服务等)中没有这样的需要，因此代码在某些 ThreadPool 线程上运行。调用线程(很可能也是 ThreadPool 线程)被释放并且能够同时执行其他类型的工作，而不是同步阻塞。因此 async-await 提高了可扩展性，因为它可以使用相同数量的线程完成更多工作。
关于c# - 在控制台或 Web 应用程序中使用 async/await，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37877803/