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

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 Task Then(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 的入口点