更新： ASP.NET
Core没有
SynchronizationContext。如果您使用的是ASP.NET
Core，则无论是否使用都
ConfigureAwait(false)无所谓。
对于ASP.NET“完全”或“经典”之类的东西，其余答案仍然适用。
原始帖子（适用于非Core ASP.NET）：
该ASP.NET团队的视频提供了有关
async在ASP.NET
上使用的最佳信息。
我已经读到它具有更高的性能，因为它不必将线程上下文切换回原始线程上下文。
对于UI应用程序，这是正确的，在该应用程序中，您只需要“同步”回一个UI线程。
在ASP.NET中，情况要复杂一些。当一个
async方法恢复执行时，它将从ASP.NET线程池中的线程。如果使用禁用了上下文捕获
ConfigureAwait(false)，则线程将继续直接直接执行该方法。如果不禁用上下文捕获，则线程将重新输入请求上下文，然后继续执行该方法。
因此
ConfigureAwait(false)，不会为您节省ASP.NET中的线程跳转；它确实为您节省了重新输入请求上下文的时间，但这通常非常快。如果您尝试对请求进行少量并行处理，则
ConfigureAwait(false)
可能 会很有用，但是TPL实际上更适合大多数情况。
但是，对于ASP.NET Web
Api，如果您的请求是在一个线程上发出的，并且您在等待某个函数并调用ConfigureAwait（false），则当您返回ApiController函数的最终结果时，这有可能使您进入另一个线程。
实际上，只要这样做
await就可以做到。一旦您的
async方法达到
await，该 方法将 被阻止，但 线程
将返回线程池。当该方法准备好继续时，将从线程池中抢夺任何线程，并将其用于恢复该方法。
ConfigureAwaitASP.NET 的唯一区别是恢复该方法时该线程是否进入请求上下文。
在我的MSDN文章
SynchronizationContext和
async简介博客中，我有更多的背景信息。
