ASP.NET Core 中没有同步上下文，SynchronizationContext
默认为 null
ASP.NET Core 应用启动后，
System.Threading.SynchronizationContext.Current通常为
null，意味着
await后的延续（continuation）默认在线程池线程上执行，不强制回到“原始上下文”。这与 ASP.NET Framework 的
AspNetSynchronizationContext完全不同。
实际影响包括：
ConfigureAwait(false)在 ASP.NET Core 中基本是冗余的——因为本就没有同步上下文可捕获 控制器中
await DoSomethingAsync()返回后，后续代码大概率仍在
ThreadPool线程，但不会引发跨线程 UI 异常（因为没 UI 线程概念） 若手动安装了自定义
SynchronizationContext（极少见），才需考虑配置延续行为
WPF 中 SynchronizationContext
绑定到 UI 线程，await
默认会回调回 UI 线程
WPF 应用启动时，
DispatcherSynchronizationContext会被自动安装到主线程，
SynchronizationContext.Current指向该实例。因此，未经配置的
await表达式会在 await 完成后，通过
Dispatcher.BeginInvoke回调到 UI 线程执行后续代码。
这意味着：
直接在按钮点击事件里写await LoadDataAsync()，后续更新
TextBox.Text是安全的 若在后台线程（如
Task.Run）中调用
await，则首次
await前的
SynchronizationContext.Current是
null，后续延续也不会自动切回 UI 线程 高频调用
await且不做
ConfigureAwait(false)，可能造成 Dispatcher 队列积压，尤其在循环中反复 await 小任务时
跨平台类库中混用时，ConfigureAwait(false)
不是“保险丝”，而是明确意图
一个被 ASP.NET Core 和 WPF 共同引用的
ServiceLibrary.dll，若内部方法使用
await Task.Delay(100)但未加
ConfigureAwait(false)，其行为会因调用方上下文而异： 在 WPF 中调用 → 延续被封送到 UI 线程 → 可能阻塞 UI（如果延续逻辑重） 在 ASP.NET Core 中调用 → 延续在线程池线程 → 实际等效于
ConfigureAwait(false)
所以通用类库应显式写出：
await SomeIoOperationAsync().ConfigureAwait(false);
这不是为了兼容旧框架，而是向调用方声明：“此处无需上下文，也不应强求回调”——避免 WPF 场景下意外拖慢 UI，也避免未来某天在其他同步上下文环境（如 WinUI 3 自定义调度器）中引发不可预知的调度开销。
容易忽略的关键点：WPF 的 Dispatcher.Invoke
和 await
不等价
有人误以为
await Task.Run(() => { Dispatcher.Invoke(...); }) 能替代自然的 await回调，这是危险的。前者会阻塞线程池线程等待 UI 线程空闲，而后者是纯异步调度。
更隐蔽的问题是：
在BackgroundWorker或
Task.Factory.StartNew中启动 async 方法，若忘记
.ConfigureAwait(false)，第一次
await后仍可能尝试捕获已丢失的
SynchronizationContext（返回
null），看似正常，实则掩盖了上下文依赖问题 WPF 的
async void事件处理程序无法被外层
await，且异常会直接崩溃应用——这点和 ASP.NET Core 的
async void（编译器警告+运行时抛出）表现不同
真正需要跨线程更新 UI 时，优先走
await+
ConfigureAwait(true)（默认）；若必须从非 UI 线程触发，用
Dispatcher.InvokeAsync显式调度，而不是绕路套
Task.Run。
