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 Task<string> GetResultAsync()
{
// ❌ 错误：这仍是同步执行，阻塞当前线程
// 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关键字。
