如果你反编译过异步方法（我非常希望你会这么做），会看到状态机中的 MoveNext() 方法 非常长，变化非常快，像是一个计算有多少 await 表达式的函数。它包含原始方法中的所有逻辑， 和处理所有状态变换所需要的芭蕾舞步 ① ，以及用来处理整个结果或异常的包装代码。
在手动编写异步代码时，你通常会将后续操作分散到多个方法内：在一个方法内开始，然后 在另一个方法内继续，并且可能在第三个方法中结束。但这样很难处理循环等流控制，对C#编译 器来说更是不可能的。这和生成代码的可读性差是两码事。状态机具有单独的入口，即 MoveNext() 方法。该方法在一开始便投入使用，并且可用于所有 await 表达式的后续操作。每当调用 MoveNext() 方法时，状态机就会通过 state 字段计算出方法要跳转到的位置。在准备计算结果 时，则跳转到方法的逻辑起始位置或 await 表达式的末尾。每个状态机只执行一次操作。实际上， 在方法内部存在一个基于 state 的 switch 语句，每种情况都具有包含不同标签的对应 goto 语句。
MoveNext() 方法一般为以下形式：
1 void IAsyncStateMachine.MoveNext() 2 { 3 //对于声明返回Task<int>的异步方法 4 int result = default(int); 5 try 6 { 7 bool doFinallyBodies = true; 8 switch (state) 9 { 10 //跳转到正确的位置 11 } 12 //方法主体 13 } 14 catch (Exception e) 15 { 16 state = -2; 17 builder.SetException(e); 18 return; 19 } 20 state = -2; 21 builder.SetResult(result); 22 }
初始状态始终为 -1 ，方法执行时状态也是 -1 （与等待时被暂停相反）。非负值均表示一个后 续操作的目标。状态机在结束时状态为 -2 。在调试配置下创建的状态机中，你会看到一个指向 -3 状态的引用——此状态是我们未曾预料到的。退化的 switch 语句会导致糟糕的调试体验，而 -3 状态即是为避免该退化语句的出现而存在的。
在方法执行过程中，在原始异步方法的 return 语句处，会设置 result 变量。然而在到达方 法的逻辑末尾时，将其用于 builder.SetResult() 的调用。即使是非泛型的 AysncTask MethodBuilder 和 AsyncVoidMethodBuilder 类型，也包含 SetResult() 方法。前者表示对 于从骨架方法返回的任务来说，该方法已经完成；后者则表示原始的 SynchronizationContext 已经完成。（异常会以同样的方式向原始的 SynchronizationContext 传播。这是一种相当丑陋 的跟踪方式，但却对必须使用 void 方法的场景提供了一种解决方案。）
doFinallyBodies 变量用于计算执行过程离开 try 块的作用域时，原始代码中的 finally 块（包括 using 或 foreach 语句中的隐式 finally 块）是否应该执行。理论上，只有以正常方式 离开 try 块的作用域时，我们才希望执行 finally 块。如果我们只是从之前为awaiter附加了后续 操作的方法中返回，由于该方法逻辑上已经“暂停”了，因此我们不希望再执行 finally 块。 finally 块均位于相关的 try 块之后，并出现在代码方法部分的 Main 主体中。
从原始异步方法的角度来看，大多方法体都是可识别的。当然，你需要习惯于所有局部变量 都作为状态机的实例变量，但这并不是什么难事。正如你所想的那样，棘手之处是 await 表达式。