async/await 不是线程切换，而是编译器生成的状态机在驱动控制流暂停与恢复——它不创建新线程，也不依赖 Task.Run，核心靠 MoveNext()
推进状态、靠 TaskAwaiter
挂起和唤醒。
async 方法怎么被编译器“重写”成状态机？
你写的这段代码：
public async Task<int> GetDataAsync()
{
await Task.Delay(100);
return 42;
}在编译后，不会生成线程或后台任务，而是被 C# 编译器（csc）自动转换为一个实现了
IAsyncStateMachine的私有结构体（Release 模式下通常是
struct，避免堆分配）。这个结构体包含：
state：整型字段，记录当前执行到第几个
await点（比如 -1=未开始，0=刚过第一个 await，-2=已完成） 所有局部变量（如中间值、
HttpClient实例等）都被“提升”为该结构体的字段，以跨暂停点保持上下文
awaiter：由
Task.GetAwaiter()返回的
TaskAwaiter实例，负责注册回调并检查是否已完成
MoveNext()：唯一入口方法，按
state值跳转到对应逻辑块，执行完当前阶段后决定是继续还是挂起
await 到底做了什么？不是“等待”，而是“注册 + 退出”
await不是阻塞指令，也不是轮询。它本质是三步操作： 调用
task.GetAwaiter().IsCompleted快速判断任务是否已同步完成 若未完成，调用
awaiter.OnCompleted(action => { /* 调用 MoveNext() */ }) 注册延续（continuation）
立即返回一个未完成的 Task给调用方，当前栈帧退出（不压栈、不占线程）
例如：
await client.GetStringAsync(url)触发的是底层 I/O 完成端口（Windows）或
epoll（Linux）的非阻塞通知机制，操作系统就绪后才调度回
MoveNext()—— 这中间线程可能早已去处理其他请求了。
为什么 ConfigureAwait(false) 能提升性能？
默认情况下，
await会捕获当前
SynchronizationContext（如 WinForms 的 UI 上下文、ASP.NET Core 的
AspNetCoreSynchronizationContext），确保恢复时回到原上下文。但多数后台逻辑（如数据访问、计算）并不需要 UI 线程或特定上下文。 捕获上下文要额外保存/恢复执行环境，有开销 在 ASP.NET Core 早期版本中，还可能导致死锁（尤其误用
.Result或
.Wait()）
ConfigureAwait(false)显式告诉编译器：“恢复时随便哪个线程池线程都行”，跳过上下文捕获逻辑
推荐在所有非 UI、非上下文敏感的异步方法末尾加：
await someTask.ConfigureAwait(false);
常见陷阱：你以为的“异步”，其实同步执行了
以下情况会让
await表现得像同步调用，却毫无收益： 等待一个已
Completed的
Task（如
Task.FromResult(1)）：直接走
IsCompleted == true分支，
MoveNext()一路执行到底，没挂起也没调度 在
async void方法里抛异常：无法被调用方
try/catch捕获，只能由
SynchronizationContext.UnhandledException处理，极易静默失败 误把 CPU 密集型操作包进
async（如
await Task.Run(() => HeavyCalc())）：这属于“假异步”，真正该做的是用
Task.Run显式卸载到线程池，而非套
async/await壳子
最隐蔽的问题是：状态机本身是值类型（
struct），但如果方法里引用了闭包或
this，编译器可能被迫装箱为
class，引发不必要的 GC 压力——调试时可用
dotnet dump analyze查看堆上是否大量存在
*StateMachine类型实例。
