async/await 不创建新线程，但上下文切换可能增多：UI/旧ASP.NET中因SynchronizationContext导致调度开销；ASP.NET Core已移除该机制；IOCP或计时器回调触发的执行线程可能变化，但属状态机调度而非线程切换。
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 线程上——区别在于，这都不是传统意义上的“线程上下文切换”，而是更细粒度的状态调度。
