ConfigureAwait(false)能避免死锁，因它禁止捕获和恢复SynchronizationContext，使await后续逻辑交由线程池执行，从而打破UI/旧ASP.NET中“主线程等任务、任务等主线程”的循环等待。
ConfigureAwait(false) 为什么能避免死锁
死锁常出现在 UI 线程或旧版 ASP.NET（非 Core）中，当你在同步上下文里调用 .Result 或 .Wait()，而被 await 的方法内部又默认尝试恢复上下文时，就会卡住：主线程在等任务完成，任务又在等主线程空闲来继续执行。
根本原因是 await 默认会捕获当前的 SynchronizationContext（比如 WinForms 的 WindowsFormsSynchronizationContext），并在任务结束后调度回它。而 ConfigureAwait(false) 告诉运行时：别捕获、别恢复，直接扔给线程池执行后续逻辑。
- UI 层事件处理中不建议加
ConfigureAwait(false)，否则后续代码无法访问this.Button1.Text等控件 - 类库方法里不加
ConfigureAwait(false)，等于把上下文依赖“传染”给调用方，极易引发隐式死锁 - ASP.NET Core 已移除全局
SynchronizationContext，但保留该调用仍是好习惯，避免误入旧框架环境或测试模拟场景
ConfigureAwait(true) 和省略 ConfigureAwait 的区别
二者行为完全一致：await task; 等价于 await task.ConfigureAwait(true)。它们都会尝试捕获并恢复同步上下文。
区别只在语义和可读性——显式写 ConfigureAwait(true) 是在说：“我需要这个上下文，且这是有意为之”，这对代码审查和后期维护有实际价值。
- 不要为了“看起来完整”而补上
ConfigureAwait(true)，除非你明确依赖上下文（如更新 WPFDispatcher对象） - 在 ASP.NET Core 中，
SynchronizationContext.Current通常为null，此时ConfigureAwait(true)实际退化为线程池调度，但行为不可靠，不应依赖 - 第三方库若未统一使用
ConfigureAwait(false)，可能在你项目里悄悄引入上下文切换开销
哪些地方必须用 ConfigureAwait(false)
不是“推荐”，而是“必须”：所有不直接面向终端交互、也不持有上下文敏感资源的异步代码路径。
典型位置包括：
- 类库（NuGet 包）中的所有
public async Task方法内部的每个await - ASP.NET Core 中间件、服务层（
IServiceProvider注入的服务）、仓储接口实现 - 后台任务（
IHostedService）、定时作业（BackgroundService）里的异步调用链
反例：public async Task<string> GetUserInfo() { var res = await _http.GetStringAsync(url); return res; }</string> —— 缺少 .ConfigureAwait(false)，一旦被 WinForms 项目引用，就埋下死锁隐患。
ConfigureAwait 不影响异常传播和状态机逻辑
有人误以为 ConfigureAwait(false) 会让异常丢失或改变 try/catch 行为，其实不会。它只控制“在哪条线程上继续执行”，不改变任务完成状态、不跳过 catch 块、也不绕过 finally。
真正要注意的是：如果后续代码依赖 HttpContext、CallContext 或自定义 AsyncLocal<T> 变量，这些数据在 ConfigureAwait(false) 后可能不可见——因为它们绑定在原始上下文上，而非线程本身。
所以：
-
ConfigureAwait(false)不影响Task.Exception或await抛出的异常类型和堆栈 - 但
AsyncLocal<string> userToken这类上下文变量，在ConfigureAwait(false)后续代码中读不到原始值 - 若需传递，应显式作为参数传入，或改用
ExecutionContext.Capture()+Restore()（极少需手动做）
最易被忽略的点是：上下文变量的隐式依赖比线程亲和更难排查，尤其在跨团队复用的中间件里。写类库时，要么不用 AsyncLocal，要么文档里白纸黑字写清约束。
