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<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();
}调试时看到的 “awaiter.OnCompleted” 就是 CPS 的入口点
当你在 await 行设断点，然后看调用栈，常会看到类似 TaskAwaiter.OnCompleted(Action) 的帧——这就是 CPS 的“注册 continuation”动作。它不执行逻辑，只登记“等我好了，就调你”。真正的 continuation 执行发生在 ThreadPool 或 UI 线程的下一次调度循环中。
容易忽略的是：如果 await 的 Task 已完成（IsCompleted == true），编译器可能直接内联 continuation，跳过调度，这时你根本看不到 OnCompleted 被调用——这说明 CPS 在这里退化成了普通顺序执行，但语义仍一致。
