async/await本质是编译器实现的CPS变换,将async方法重写为状态机并把await后代码作为continuation回调注册;它自动处理同步/异步分支、变量生命周期和异常传播,而手写CPS需显式管理这些细节。

async/await 本质是编译器生成的 CPS 变换
你写的 async 方法,C# 编译器不会把它变成多线程代码,而是重写为状态机,并把后续逻辑(await 后面的语句)拆成回调——这正是 continuation-passing style 的核心特征:不靠调用栈返回,而是显式把“接下来要做的事”作为参数(即 continuation)传下去。
比如 await Task.Delay(100) 后面的代码,在编译后会被包进一个 MoveNext 委托里,作为 Task 完成时的 continuation 注册进去。这不是你手动写的回调,但语义等价于 CPS 中的“把剩余计算作为函数传入”。
和手写 CPS 的关键区别在控制流抽象层
C# 的 async/await 隐藏了 continuation 的构造和调度细节,而手写 CPS(比如用 Task.ContinueWith 或自定义高阶函数)需要你显式管理:
-
await自动处理同步/异步分支(SynchronizationContext、ConfigureAwait 等),手写 CPS 得自己判断是否需要TaskScheduler.Current -
await保持局部变量生命周期(通过状态机字段保存),手写 CPS 容易因闭包捕获导致意外对象驻留 - 异常传播方式不同:
await把异常重抛到原始上下文,ContinueWith默认吞掉异常,需显式检查Task.Exception
不要用 ContinueWith 模拟 await,除非你真需要 CPS 的细粒度控制
常见误区是用 task.ContinueWith(t => { /* 后续逻辑 */ }) 替代 await task,这看似“更底层”,实则绕过了编译器的状态机优化,还引入额外委托分配和调度开销。
真正适合手写 CPS 的场景极少,例如:
- 实现自定义 awaiter(需实现
GetAwaiter()和OnCompleted(Action)) - 跨语言互操作中对接 callback-first 的 C API(如 Windows Runtime 的
IAsyncAction) - 构建 DSL 或 async-aware 的流程引擎,需要动态拼接 continuation 链
public static TaskThen (this Task task, Func > func) { return task.Unwrap().ContinueWith(t => t.IsFaulted ? Task.FromException(t.Exception.InnerException) : func(t.Result), TaskContinuationOptions.ExecuteSynchronously) .Unwrap(); }
调试时看到的 “awaiter.OnCompleted” 就是 CPS 的入口点
当你在 await 行设断点,然后看调用栈,常会看到类似 TaskAwaiter.OnCompleted(Action) 的帧——这就是 CPS 的“注册 continuation”动作。它不执行逻辑,只登记“等我好了,就调你”。真正的 continuation 执行发生在 ThreadPool 或 UI 线程的下一次调度循环中。
容易忽略的是:如果 await 的 Task 已完成(IsCompleted == true),编译器可能直接内联 continuation,跳过调度,这时你根本看不到 OnCompleted 被调用——这说明 CPS 在这里退化成了普通顺序执行,但语义仍一致。









