c# async/await 和 continuation-passing style (CPS) 的关系

来源：这里教程网时间：2026-02-21 17:38:16 作者：

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 Task<T> Then<T, U>(this Task<T> task, Func<T, Task<U>> func)
{
    return task.Unwrap().ContinueWith(t =>
        t.IsFaulted ? Task.FromException<U>(t.Exception.InnerException)
                    : func(t.Result),
        TaskContinuationOptions.ExecuteSynchronously)
        .Unwrap();
}