async/await 本身不创建新线程，但上下文切换仍可能发生
不会自动导致“更多线程”——
async/await默认不占用新线程，它只是把异步操作的控制流交还给当前上下文，等 I/O 完成后再恢复。但“上下文切换”是否增多，取决于你所处的上下文类型和代码写法。
UI 线程（WinForms/WPF）或 ASP.NET（旧版）中容易触发同步上下文切换
这类环境默认启用
SynchronizationContext，
await后会尝试回到原上下文执行后续代码，即使只是简单赋值，也可能排队等待 UI 消息循环或请求上下文可用。这不是线程切换，而是**同步上下文调度开销**，在高频率 await 场景下可观测到延迟。 用
ConfigureAwait(false)可跳过上下文捕获（尤其在类库、非 UI 层） 但 UI 层更新控件时必须回到 UI 线程，此时
ConfigureAwait(true)（默认）是必要代价 ASP.NET Core 已移除
SynchronizationContext，所以
ConfigureAwait(false)在那里无实际影响
ThreadPool 线程上 await Task.Delay 或 HttpClient.GetAsync 不引发线程切换
这些操作本质是 I/O 完成端口（IOCP）或计时器回调驱动，完成时由 ThreadPool 线程拾取继续执行。关键点在于：这个“继续执行”的线程不一定是原来的那个，但也不需要保存/恢复完整线程栈——
async/await编译为状态机，只保存局部变量和位置，开销远小于传统线程切换。
var result = await httpClient.GetAsync("https://api.example.com");
// 这行之后的代码可能在另一个 ThreadPool 线程运行
// 但不是因为“创建了新线程”，而是 IOCP 回调被分发给了空闲线程
真正增加上下文切换风险的操作
不是
await本身，而是你在
async方法里混用了同步阻塞调用或不当配置： 调用
.Result或
.Wait()→ 可能死锁（尤其有同步上下文时），并强制线程挂起等待 大量短生命周期
Task.Run(() => { ... }) + await → 确实会频繁争抢 ThreadPool 线程，间接推高调度压力
未设限的并发 await（如 Task.WhenAll(list.Select(x => ProcessAsync(x)))）→ 若
ProcessAsync内部含同步 I/O 或 CPU 密集操作，会耗尽线程池 在
async void方法中异常未被捕获 → 调用栈断裂，调试时看似“跳变”，实为上下文丢失
async/await 的轻量性建立在“不滥用同步等待”和“理解执行上下文归属”之上。最容易被忽略的是：你以为没切线程，其实正卡在 UI 消息泵排队；你以为在后台线程，其实刚被调度到一个刚唤醒的 ThreadPool 线程上——区别在于，这都不是传统意义上的“线程上下文切换”，而是更细粒度的状态调度。
