Kotlin协程中Continuation工作原理及相关技术疑问

我正在学习CPS（续体传递风格），想了解它的工作机制。有人认为CPS本质只是回调，但我对下面的Kotlin代码存在几个疑问：

相关代码示例 #

object createPost(
    Token token,
    Item item,
    Continuation<Post> const){...}

interface Continuation<in T> {
    val context: CoroutineContext
    fun resume(value: T)
    fun resumeWithException(exception: Throwable)
}

疑问与解答 #

1. 为何此处使用接口作为参数？

• 核心是解耦：createPost不需要关心续体的具体实现，只要传入的对象符合Continuation接口的约定就行。比如Kotlin协程里，不同调度器（IO/Default）、不同协程作用域下的续体实现各不相同，但都能被这个方法接收，灵活性更高。
• 强制规范：接口明确要求实现resume（处理成功返回）和resumeWithException（处理异常）两个方法，避免了普通回调常出现的“只处理成功场景、漏掉异常”的问题，保证逻辑的完整性。

2. Continuation接口中的<in T>有什么作用？

• 这是Kotlin的逆变声明，简单说就是：父类型的Continuation可以替代子类型的Continuation使用。比如如果Post是VideoPost的父类，那么Continuation<Post>可以传给需要Continuation<VideoPost>的方法。
• 逆变适配了Continuation的使用场景：因为Continuation只接收T类型的值（resume方法的参数是T），这种“只进不出”的场景下，逆变能让类型兼容性更好，续体的复用性更强。

3. Continuation作为参数，其内部实际功能是什么，底层如何被调用？

• 内部功能：Continuation就是CPS里的“续体”——它保存了当前函数暂停时的所有上下文（比如局部变量、代码执行的位置），以及拿到结果后要执行的后续逻辑。当createPost的异步操作（比如网络请求创建帖子）完成后，调用resume(value)就能把结果传递给续体，让之前暂停的代码继续执行；如果操作失败，就调用resumeWithException把异常传递给后续逻辑处理。
• 底层调用逻辑：在Kotlin协程中，编译器会自动将suspend修饰的挂起函数转换为CPS风格的代码。当你调用挂起函数时，协程框架会生成对应的Continuation实例，把协程的调度器、异常处理器等上下文信息存在context属性中。当异步操作完成后，框架会根据context指定的调度器，在合适的线程上调用resume或resumeWithException，恢复协程的执行。

内容的提问来源于stack exchange，提问作者c-an