async方法会被编译器重写为实现IAsyncStateMachine的状态机，含MoveNext、状态字段和提升的局部变量；await本质是注册回调而非线程阻塞，通过状态保存与恢复实现异步流。
async 方法一写，编译器就悄悄生成了一个状态机
你写的 async Task，根本不是“原样执行”的方法——C# 编译器在 IL 层面把它重写成了一个实现了 IAsyncStateMachine 接口的结构体（或类），里面包含 MoveNext()、SetStateMachine() 和一堆字段。这个状态机才是实际被调度和执行的主体。
- 每个
await表达式都会被编译器拆成一个“暂停点”，对应状态机中的一个整数状态
值（如 state = 0、state = 1）；初始为-1，完成为-2 - 所有局部变量（比如
string result = "hello"）会被“提升”为状态机的字段，确保跨 await 仍能访问 -
await实际调用的是GetAwaiter().OnCompleted(continuation)，本质是注册回调，不是线程切换 - 如果你反编译一个 async 方法（用 ILSpy 或 dotPeek），会看到类似
d__0
值（如 为什么 await 不阻塞线程，但看起来像同步代码？
因为状态机把“挂起”和“恢复”这两件事做了封装：遇到 await 时，它保存当前状态 + 局部变量 + 当前上下文，然后立即返回一个未完成的 Task；等底层异步操作（如 IOCP 完成、Timer 触发）就绪后，调度器调用 MoveNext() 继续执行后续逻辑。
- 关键点：没有线程在等——线程执行完
await就去干别的了，不是 Sleep，也不是 Join - IO 密集型操作（
HttpClient.GetStringAsync、FileStream.ReadAsync）真正由操作系统内核处理，不占 CLR 线程 - CPU 密集型任务（如
Task.Run(() => Calc())）仍需线程池线程，这时await只是让调用方不阻塞，但没节省线程资源 - 若在 UI 线程中
await后恢复，默认会回到 UI 上下文（通过SynchronizationContext），这就是为什么你能直接更新控件——但也是死锁高发区
ConfigureAwait(false) 到底禁用了什么？
它禁用的是“恢复时必须回到原始上下文”这一行为，也就是跳过 SynchronizationContext.Current 或 TaskScheduler.Current 的捕获与恢复逻辑。
- 库代码（如 NuGet 包里的工具方法）**必须加**
.ConfigureAwait(false)，否则在 WinForms/WPF/ASP.NET（旧版）里可能引发死锁 - 应用层代码（如 MVC Controller Action、WPF Command Handler）通常**不该加**，因为你确实需要回到 UI 线程更新界面
- 从 .NET 5 开始，ASP.NET Core 默认没有
SynchronizationContext，所以ConfigureAwait(false)在 Web API 中影响变小，但仍是好习惯 - 错误写法：
await DoSomething().ConfigureAwait(false).ContinueWith(...)——ConfigureAwait返回的是ConfiguredTaskAwaitable，不能链式调用ContinueWith
状态机调试难？看这几处关键线索
状态机本身不可见，但你可以通过几个可观测点定位问题：
- 异常堆栈里如果出现
d__N.MoveNext - 用 Visual Studio 调试时，在“并行堆栈”窗口能看到
AsyncMethodBuilder相关帧，配合“仅我的代码”开关可聚焦业务逻辑 - IL 层面，状态机类型有
[AsyncStateMachine(typeof(...))]特性，且方法体只剩 builder.Start() 调用——真正的逻辑全在MoveNext()里 - 别试图手动 new 状态机类型：它的构造函数是私有的，且依赖
AsyncTaskMethodBuilder初始化内部状态
最易被忽略的一点：状态机不是“运行时动态构建”的，而是编译期确定的有限状态集合。你加第 5 个 await，状态值就多一个分支，但不会因此变慢——慢的是 await 对象本身的开销（比如 Task.Delay 的 Timer 注册），不是状态机跳转。
