async/await 本身不创建新线程，仅通过状态机挂起方法并注册延续；线程切换取决于上下文捕获（如 ConfigureAwait）和执行环境，I/O 异步不占线程，CPU 密集型操作须用 Task.Run。
async/await 本身不创建新线程
绝大多数情况下，async/await 不会主动创建新线程。它依赖于当前 SynchronizationContext 或 TaskScheduler 来决定后续代码在哪执行——比如 UI 线程（WinForms/WPF）或 ASP.NET Core 的请求上下文，都不是新线程。
常见误解是“await 就等于后台线程”，其实只有显式调用 Task.Run()、Task.Factory.StartNew() 或 I/O 操作底层触发的线程池回调，才可能用到线程池线程（但那也不是 await 创建的）。
-
await只是把方法拆成状态机，挂起当前逻辑，注册一个延续（continuation） - 挂起后控制权立刻交还给调用方，不阻塞当前线程
- I/O 完成时，.NET 通过 I/O Completion Port（IOCP）通知线程池取一个空闲线程来执行 continuation，这个线程可能是原线程，也可能是线程池里的任意一个
线程切换发生在 await 后续代码（continuation）的调度时刻
是否发生线程切换，取决于 await 后面那部分代码（即 await 之后的语句）被调度到哪个上下文执行。关键看两点：
- 有没有捕获当前上下文（默认会，除非用了
.ConfigureAwait(false)） - 当前上下文是否支持同步调度（如 UI 线程有
SynchronizationContext，ASP.NET Core 6+ 默认没有）
例如在 WinForms 中：
private async void button1_Click(object sender, EventArgs e)
{
var result = await DoSomethingAsync(); // 可能在线程池线程完成
label1.Text = result; // 这行一定回到 UI 线程执行（因为捕获了 WinForms SynchronizationContext）
}
而加了 .ConfigureAwait(false) 后，后续代码就不再强制回原上下文，大概率在线程池线程执行，避免上下文切换开销。
Task.Run() 才真正把工作推到线程池线程
如果你需要 CPU 密集型操作不阻塞主线程，必须显式使用 Task.Run()，否则 async/await 对纯计算毫无帮助：
public async TaskGetResultAsync() { // ❌ 错误：这仍是同步执行，阻塞当前线程 // return HeavyComputation(); // ✅ 正确：委托给线程池 return await Task.Run(() => HeavyComputation()); }
-
HeavyComputation()是同步 CPU 绑定方法，不 await 任何东西 - 不包
Task.Run()，它就在当前线程跑完，async完全没意义 -
Task.Run()内部调用ThreadPool.QueueUserWorkItem()，这才真正借用线程池线程
容易被忽略的关键点：I/O 和 CPU 场景完全不是一回事
这是最常混淆的地方：
- 网络请求（
HttpClient.GetAsync）、文件读写（FileStream.ReadAsync）、数据库查询（DbCommand.ExecuteReaderAsync）——这些是真正的异步 I/O，不占线程，靠操作系统 IOCP 回调驱动 - 循环计算、JSON 序列化、图像处理等——这些是同步 CPU 工作，必须靠
Task.Run()搬到线程池，否则async壳子只是假异步 -
await Task.Delay(1000)也不占线程，靠Timer+ 回调，和线程池无关
所以判断要不要用 async/await，先看底层是不是真异步（即是否基于 IOCP 或 ThreadPool.UnsafeQueueUserWorkItem），而不是看有没有 async 关键字。
