使用如http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html所示的async / await，其中一个好的做法是使用ConfigureAwait(false)，因此方法返回不必返回请求上下文。使用它有什么潜在的后果？问另一种方式，这个不什么时候被推荐？
答案 0 :(得分：3)
何时推荐 ？
如果依赖于该上下文的方法中的代码进一步向下，则您的方法必须返回到相同的上下文。如果该方法的其余部分不需要特定的上下文，那么使用ConfigureAwait(false)是一个好习惯。
有两个主要示例：UI代码和ASP.NET代码。
UI代码必须在UI线程上运行;这包括大多数UI小部件访问，并且我扩展了“UI代码”的定义以包括我的ViewModel（在WPF中有一些情况可以让你从后台线程更新UI，但对所有人来说并非如此） MVVM平台）。因此，如果您的方法以textBox1.Text = ""或myViewModel.MyObservableCollection.Add(4)结束，则必须先返回UI线程才能执行该代码。
ASP.NET代码必须在ASP.NET请求上下文中运行;这包括依赖HttpContext.Current的任何代码（许多System.Web API隐式假设ASP.NET请求上下文）。因此，如果您的方法以HttpContext.Current.Items...结尾，那么它必须返回到ASP.NET请求上下文才能执行该代码。 （旁注：在.NET 4.6及更高版本的ASP.NET vNext中，ASP.NET请求上下文实际上已经消失了。）
实际上，这意味着大多数库代码应该使用ConfigureAwait(false)，因为编写良好的库代码不依赖于特定的UI框架或{{1} }。同样，大多数应用程序代码不应使用System.Web，因为它必须更新UI /发送HTTP响应。