ConfigureAwait(true)恢复原始同步上下文，适用于需访问UI或HttpContext的场景，但可能引发死锁；ConfigureAwait(false)不恢复上下文，提升性能并避免死锁，推荐用于类库和无需上下文依赖的代码。
在 .NET 中，ConfigureAwait(true) 和 ConfigureAwait(false) 的主要区别在于是否尝试将后续的执行上下文恢复到原始的同步上下文（Synchronization Context）。
ConfigureAwait(true)：恢复同步上下文
这是默认行为（即不调用 ConfigureAwait 时等同于传 true）。它会尝试将 await 后面的代码调度回原来的上下文，比如 UI 线程或 ASP.NET 请求上下文。
适用于：
- 需要访问 UI 控件的 WPF、WinForms 应用
- ASP.NET Web Forms 或 MVC 中需要访问 HttpContext.Current 的场景
缺点是可能引发死锁，特别是在异步方法被同步等待时（如 .Result 或 .Wait()），因为线程被阻塞，无法处理上下文回调。
ConfigureAwait(false)：不恢复同步上下文
它告诉运行时不必回到原始上下文，后续代码可在任意线程池线程上执行。这提升了性能并避免了死锁风险。
推荐用于：
- 类库中的异步方法（不应依赖调用方上下文）
- 不需要访问 UI 或特定上下文的后台逻辑
- 提高吞吐量的服务器端代码
注意：一旦使用 false，后续所有 await 都不会自动回到原始上下文，直到显式切换回来（如通过 Task.Run 或 Invoke on UI thread）。
如何做出正确选择？
基本原则是：如果你的代码不需要访问当前上下文的特殊资源，就用 ConfigureAwait(false)。
- 编写通用类库时，一律使用
ConfigureAwait(false) - 在 UI 应用的事件处理中，若 await 后要更新界面，则保留默认行为或设为 true
- 在 ASP.NET Core 中，通常无需恢复 HttpContext，可安全使用 false（尤其在中间件或服务中）
- 不确定时，优先使用 false，除非明确需要上下文
基本上就这些。关键不是记住规则，而是理解上下文捕获带来的影响：性能、死锁风险和线程亲和性。多数情况下，false 更安全高效。
