总体思路是正确的-该方法的其余部分被制成各种形式的延续。
在“快速通道”的博客文章有如何的细节
async/
await编译器改造工程。
差异，浮现在脑海：
该
await关键字还使用“调度环境”的概念。调度上下文是（
SynchronizationContext.Current如果存在的话），返回
TaskScheduler.Current。然后，继续在调度上下文上运行。因此，如果需要的话，可以更近似地传递
TaskScheduler.FromCurrentSynchronizationContext给
ContinueWith，然后再回落
TaskScheduler.Current。
实际
async/
await实现基于模式匹配；它使用“等待”模式，该模式允许等待任务以外的其他事情。例如WinRT异步API，某些特殊方法（例如
YieldRx
observables和特殊套接字可等待），它们对GC的影响不那么严重。任务功能强大，但并不是唯一可以等待的任务。
还有一点细微的挑剔的区别：如果等待已完成，则该
async方法实际上不会在此时返回；它同步地继续。因此，这有点像传递
TaskContinuationOptions.ExecuteSynchronously，但是没有与堆栈相关的问题。
