企业官网建设流程全解析

我写协程写了快一年半，网络请求、数据库查询、列表刷新全挂在suspend函数上。我一直觉得自己对协程已经算熟，直到一次内部技术评审被人追问："你说这是CPS变换，那CPS到底改了哪些东西？Continuation对象里藏了什么？状态机是怎么流转的？"我当场只能背出"改变签名、返回值、引入状态机"的骨架，细节全是模糊的。说真的，那感觉就像一直在API层面打转，从没真正看过底牌。这周末我把自己写过的suspend函数全部反编译了一遍，对着字节码逐行看，还用Java手写了一遍等价的CPS状态机。这篇文章就是这次"渡劫"的完整记录。如果你也想真正把Kotlin协程吃透，不去官网翻一遍文档，而是直接看字节码，这一篇应该能帮你省下不少瞎折腾的时间。

1. 挂起函数到底"挂"的是什么：CPS变换要解决的真实问题

1.1 JVM没有原生的挂起指令，Kotlin只能在编译期动手脚

先问一个底层问题：JVM支持"一个方法先暂停执行，等某个条件满足后，再从暂停的位置继续往下跑"吗？答案是不支持。JVM的方法调用模型很死板：一个方法一旦开始执行，要么正常返回，要么抛异常，要么因为阻塞而白白占用线程，它没有用户态的挂起语义。Kotlin要在JVM上实现协程，就只能靠编译器在字节码层面偷天换日。

Kotlin的做法是把"挂起"转换成"提前返回"。一个suspend函数执行到挂起点时，不是真的暂停在方法栈帧里等结果，而是直接return一个特殊信号。等异步条件满足之后，外界通过之前传入的continuation对象，再次进入这个方法，从上次离开的位置继续写。这样就能把原本需要阻塞线程的等待阶段，变成线程可以先去做其他事情的自由时间。

理解这个转变很重要。很多人以为协程挂起是"方法被临时冻结了"，从字节码看完全不是。它更像你取了个号，把手机号留给银行，然后回家等短信，而不是原地坐一下午。难点在于：方法已经return了，局部变量全没了，编译器怎么保证你回来时还记得之前跑到哪、要用到的变量是什么？这就引出了CPS变换和状态机的存在意义。

1.2 suspend修饰符如何改变函数契约，以及为什么普通函数不能调用它

一个普通Kotlin函数：

fun getToken(): String { return "token" }

调用方拿到的是一个String。

但如果你在前面加上suspend：

suspend fun getToken(): String { return "token" }

看起来用法几乎一样，调用方拿到的还是一个String。但Kotlin编译器会强制约束：只有suspend函数或协程构建器里才能调用它。这个约束不是拍脑袋想出来的，而是因为经过CPS变换后，getToken的JVM签名已经彻底变了，它带上了一个Continuation参数。普通函数没有这个对象，自然无法完成调用。语言层面的"只能这样写"，本质上是字节码层面的"缺少一个参数"。

所以别再背"挂起函数必须在协程上下文里调用"这句话了，真正原因是：没有Continuation，CPS变换后的函数根本没有完整入参。这也是Kotlin编译器在你试图从普通函数调用suspend函数时报错的内在逻辑——它不只是在做语法限制，而是在保证编译后的字节码能正常对上参数。

1.3 CPS与普通回调的区别，以及Kotlin的务实变体

CPS全称Continuation-Passing Style，是一种把"调用后继续执行的操作"显式作为参数传递的编程风格。它和回调很像，但比回调更彻底：回调只是"我这里做完之后要通知你"，而CPS要求把接下来的整个计算过程打包成一个continuation对象，后续所有步骤都围绕这个对象展开。

Kotlin并没有做教科书级别的完整CPS。函数正常算完时，仍然直接返回结果；只有遇到真正挂起的操作，才返回COROUTINE_SUSPENDED这个哨兵值。这种做法是性能和可读性的平衡，也直接决定了你在字节码里看到的形态不是那种清一色回调嵌套，而是一个可以被重复调用的状态机。下面进正题，看编译器到底改了什么。

2. 反编译工具与最小样本：先看suspend函数在字节码里的签名变化

2.1 工具选择：IDEA内置反编译能力的用法

在做实验之前，先说工具。最方便的是IntelliJ IDEA或Android Studio，打开任意Kotlin文件，菜单栏选Tools -> Kotlin -> Show Kotlin Bytecode。右侧会打开一个字节码窗口，顶部有个Decompile按钮，点击后能生成将近Java源码的等价代码。我下面展示的都是反编译后的Java等价代码，因为原生字节码全是aload、areturn这类助记符，阅读成本太高。

真实操作时我建议两个窗口对照着看：左边Java反编译结果，右边原始字节码。一旦Java结果里出现不理解的跳转逻辑，去右边看对应的标签跳转，会清楚很多。另一个小技巧是，反编译之后搜索COROUTINE_SUSPENDED，这一个关键词基本上能把所有挂起相关的路径都标出来。

2.2 最简单的挂起函数：签名和返回类型两条硬变化

先看一个没有任何真实挂起的suspend函数：

suspend fun getToken(): String { return "token" }

反编译后的Java等价代码（已删掉元数据注解等噪音）：

public static final Object getToken(Continuation<? super String> $completion) { return "token"; }

对比原方法签名，有两条硬性变化。第一条，参数列表末尾多了一个Continuation<? super String> $completion，这是整个CPS变换最直观的标志。Continuation的泛型参数代表"挂起函数完成后应该恢复给调用方的结果类型"。第二条，返回类型从String变成了Object。为什么必须是Object？因为函数可能有两种返回：一种是正常完成，返回String；另一种是真正挂起，返回一个固定的信号值COROUTINE_SUSPENDED。String这个类型装不下这个信号，所以编译器把统一返回类型提升成了Object。

注意即使这个函数体内没有任何真正挂起的调用，只要加了suspend，签名和返回类型也会发生这两条变化。第一层CPS适配是强制性的，跟函数体内是否挂起无关。

2.3 加入真正挂起点：COROUTINE_SUSPENDED哨兵值的传递流程

现在加一个真正的挂起函数delay：

suspend fun getUserId(token: String): String { delay(100) return "id-$token" }

反编译并简化后的Java等价代码如下：

public static final Object getUserId(String token, Continuation<? super String> $completion) { GetUserIdKt$getUserId$1 continuation; if ($completion instanceof GetUserIdKt$getUserId$1) { continuation = (GetUserIdKt$getUserId$1) $completion; } else { continuation = new GetUserIdKt$getUserId$1($completion); } Object $result = continuation.result; switch (continuation.label) { case 0: { continuation.label = 1; Object delayResult = DelayKt.delay(100L, continuation); if (delayResult == IntrinsicsKt.getCOROUTINE_SUSPENDED()) { return IntrinsicsKt.getCOROUTINE_SUSPENDED(); } $result = delayResult; // 如果delay没有真正挂起，继续往下执行case 1 } case 1: { return "id-" + token; } } throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine"); }

最核心的是那个if判断。当delay真的需要等待100毫秒时，它返回COROUTINE_SUSPENDED，getUserId看到这个信号后也跟着返回同一个信号。这个信号一路往调用链上层传，调度器发现协程挂起了，就会把线程让出来去做其他任务。等100毫秒时间到了，delay内部通过continuation的resumeWith方法把结果塞回来，协程状态机再根据label记录的坐标，从case 1继续执行。

同时也注意到，token是函数参数，它放在方法栈帧里，方法return后栈帧销毁，但恢复时需要再次传入token吗？不需要。调用方在第一次调用getUserId时已经传了token，而语音层的函数调用逻辑保证了后续resume调用仍然复用同一个入口方法？实际上这里的状态机恢复时，方法参数token之所以还能用，是因为反编译代码显示case 1直接用了token，但真实字节码中token会被保存到continuation字段里。我这个简化版本隐藏了存储细节，下一节用更复杂的例子把局部变量跨挂起点的存储逻辑展示清楚。

3. 状态机编排：多个挂起点和局部变量如何被编译器管理

3.1 用三个挂起点的fetchUserSummary做样本

看一个更贴近业务的函数：

suspend fun fetchUserSummary(): String { val token = getToken() val user = getUserInfo(token) val score = getScore(user.id) return "user: $user, score: $score" }

这里面有三个挂起点：getToken、getUserInfo、getScore。并且getUserInfo依赖token，getScore依赖user。如果采用传统的回调写法，三层嵌套已经很难看了，更多挂起点会直接变成回调地狱。Kotlin编译器用一个状态机就能管住所有挂起点，不管你有3个还是30个。

3.2 Continuation子类的字段设计：L$0、L$1和label

为了跨过挂起点保存局部变量，编译器会生成一个ContinuationImpl的子类。反编译后的结构大致如下：

final class FetchUserSummaryKt$fetchUserSummary$1 extends ContinuationImpl { Object L$0; Object L$1; int label; FetchUserSummaryKt$fetchUserSummary$1(Continuation<? super String> $completion) { super($completion); } @Override public final Object invokeSuspend(Object $result) { // 状态机主逻辑 } }

这里L$0、L$1就是编译器指定的局部变量槽位。函数第一次执行时，方法栈帧里存着token、user这些局部变量；一旦执行到挂起点并return，整个栈帧销毁。为了让协程恢复后还能拿到这些值，编译器会把可能跨挂起点的局部变量逐个存到continuation对象的字段里。label字段则记录"当前执行到第几个挂起点"，相当于给状态机做了一个书签。

另外，编译器还会很聪明地判断变量的生命周期。有些局部变量只在当前case内使用，后续不再用到，就不会浪费一个L$槽位；有些变量被多个case共用，就复用同一个槽位。这层优化在源码里完全不可见，只有看反编译结果才能体会。

3.3 状态机执行流程拆解：从case 0到case 2

fetchUserSummary被反编译成Java后的核心逻辑如下（我做了适度简化，保留状态机骨架）：

public static final Object fetchUserSummary(Continuation<? super String> $completion) { FetchUserSummaryKt$fetchUserSummary$1 continuation; if ($completion instanceof FetchUserSummaryKt$fetchUserSummary$1) { continuation = (FetchUserSummaryKt$fetchUserSummary$1) $completion; } else { continuation = new FetchUserSummaryKt$fetchUserSummary$1($completion); } switch (continuation.label) { case 0: { continuation.label = 1; Object tokenResult = getToken(continuation); if (tokenResult == IntrinsicsKt.getCOROUTINE_SUSPENDED()) { return IntrinsicsKt.getCOROUTINE_SUSPENDED(); } continuation.L$0 = tokenResult; // 继续执行 case 1 } case 1: { String token = (String) continuation.L$0; continuation.label = 2; Object userResult = getUserInfo(token, continuation); if (userResult == IntrinsicsKt.getCOROUTINE_SUSPENDED()) { return IntrinsicsKt.getCOROUTINE_SUSPENDED(); } continuation.L$1 = userResult; continuation.L$0 = null; // 手动置空，帮助GC // 继续执行 case 2 } case 2: { User user = (User) continuation.L$1; Object scoreResult = getScore(user.id, continuation); if (scoreResult == IntrinsicsKt.getCOROUTINE_SUSPENDED()) { return IntrinsicsKt.getCOROUTINE_SUSPENDED(); } return "user: " + user + ", score: " + scoreResult; } } throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine"); }

这段代码有几个设计上的讲究。

第一个是case 0末尾没有return，直接fall-through到case 1。这是因为如果getToken没有真实挂起，说明结果已经拿到了，那就不需要再绕一圈状态机，直接在当前这轮调用里继续处理token。这个处理可以省掉一次方法重入的代价，属于非常实在的优化。

第二个是每次调用内部suspend函数之前，先把label改成"下一步该去哪"。比如在case 0里先把label改成1，然后再调getToken。这样即使getToken真的挂起了，等它resume回来时，状态机一看label是1，就知道应该走case 1。

第三个是局部变量在生命周期结束后被置为null。比如case 1用完了token，马上把L$0清空；case 2用完了user，理论上也会清空。这是为了在长时间运行的协程里尽量让大对象不被continuation对象长期引用，避免内存泄漏。这种字节码层面的洁癖，业务代码里你是永远看不见的。

3.4 continuation复用机制与内存优化细节

每个反编译结果的开头都有一块instanceof判断：

if ($completion instanceof FetchUserSummaryKt$fetchUserSummary$1) { continuation = (FetchUserSummaryKt$fetchUserSummary$1) $completion; } else { continuation = new FetchUserSummaryKt$fetchUserSummary$1($completion); }

这段代码的意思是：如果外部传入的completion已经是我们这个状态机类型的实例，就直接复用；否则新建一个。为什么可以复用？因为协程在一次完整执行周期里，外部调用方拿到的continuation始终是同一个对象。第一次进入fetchUserSummary时创建状态机对象，把它传给getToken；getToken如果挂起，后续resume触发时，又带着同一个continuation对象回到fetchUserSummary入口。既然类型匹配，就无需再分配一个新对象。这个做法大幅减少了协程高频挂起时的对象分配压力，也是协程性能能打的一个隐藏原因。

明白了这一点，你再去看协程崩溃栈里频繁出现的那些带$1、$2的类名，就不会觉得它们是随机生成的一堆临时对象了。它们就是那个被一路复用的状态机，只是长得丑了点。

4. Continuation接口、CoroutineContext与resume：字节码视角下的框架地基

4.1 Continuation接口与BaseContinuationImpl的模板方法

Kotlin标准库里的Continuation接口非常短：

public interface Continuation<in T> { public val context: CoroutineContext public fun resumeWith(result: Result<T>) }

但在字节码层面，编译器生成的状态机基类并不直接实现这个接口，而是继承kotlin.coroutines.jvm.internal.BaseContinuationImpl。BaseContinuationImpl把resumeWith做成一个模板方法：它接收Result，内部做一些状态判断，然后调用abstract的invokeSuspend(result)。而invokeSuspend正是编译器给每个状态机生成的入口方法。

所以外部看，resumeWith是"从挂起状态恢复的入口"；内部看，调用的就是状态机里那个大switch。resumeWith并不负责计算结果，只是负责拿着结果，驱动状态机进入下一段逻辑。

4.2 CoroutineContext在continuation对象中的实际作用

再看BaseContinuationImpl或者编译器生成的子类，你会发现每一个状态机对象都持有CoroutineContext。这不是摆设。CoroutineContext里装的是Job、Dispatcher、CoroutineName等元素，它决定了协程的父级关系、调度方式、调试名称。在resume被调用时，调度器会检查这个上下文中的ContinuationInterceptor，决定要不要把恢复工作派发到另一个线程。

举一个常见场景：你在主线程启动协程，里面调用withContext(Dispatchers.IO)做文件读取。withContext本质上就是创建了一个新的continuation，把IO调度器放到它的context里。恢复时，IO调度器会拦截resumeWith，让状态机在IO线程池上继续执行。任务完成后切回主线程，也是同样的机制在切换。CPS变换只负责打包"接下来的步骤"，不负责决定在哪个线程上执行；线程切换完全是CoroutineContext和调度器配合的结果。

4.3 Dispatcher如何用resume实现线程切换而非阻塞

理解了CoroutineContext之后，"挂起不阻塞线程"这句话从字节码看就非常实在。普通线程阻塞时，方法没有返回，线程卡在那个栈帧上。协程挂起时，状态机函数在挂起点直接return COROUTINE_SUSPENDED，调用栈被释放，线程可以继续执行别的任务。关键区别就在于：一个占用线程，一个释放线程。

resumeWith被调用时，Dispatcher的Interceptor会把恢复动作post到目标线程队列。状态机的invokeSuspend在新线程上重新执行，看起来就像函数在另一个线程里"恢复"了。整个过程没有线程被无谓地长时间占住，这是协程在IO密集场景下比"直接起线程阻塞"更省资源的根本原因。

4.4 协程构建器与CPS的关系：launch为什么能启动挂起函数

最后把范围拉大一点。launch接收的block本身是一个suspend lambda，它也会被编译成一个Continuation子类，通常叫SuspendLambda。launch做的事很简单：创建coroutine上下文，创建一个受DispatchedContinuation包装的continuation，然后调用一次resumeWith。这次resumeWith开始执行SuspendLambda状态机，第一次进入block，运行到第一个真实挂起点时返回COROUTINE_SUSPENDED，协程进入挂起状态。所以协程构建器本质上就是"构造continuation并启动它"的包装器，与suspend函数执行机制完全一致。

在Compose项目里经常会写rememberCoroutineScope().launch { ... }，背后的原理和上面一样。scope提供CoroutineContext，launch创建/启动continuation，block里的状态机遇到挂起点就返回，遇到网络回包就恢复。只是Compose的context里额外塞了Recomposer相关的拦截逻辑，让协程恢复时机和重组时机能正确联动。

5. 手写一遍CPS变换：把Kotlin编译器的活儿还原出来

5.1 一个最小可用的Java状态机实现

看再多反编译结果，不如自己写一遍。我用纯Java手写fetchUserSummary的等价状态机，先把Continuation简化为只包含label和result的最小结构：

public class Continuation<T> { public int label; public T result; }

然后是核心的状态机方法：

public static Object fetchUserSummary(Continuation<String> completion) { FetchUserSummaryStateMachine continuation; if (completion instanceof FetchUserSummaryStateMachine) { continuation = (FetchUserSummaryStateMachine) completion; } else { continuation = new FetchUserSummaryStateMachine(completion); } switch (continuation.label) { case 0: continuation.label = 1; Object tokenResult = getToken(continuation); if (tokenResult == COROUTINE_SUSPENDED) { return COROUTINE_SUSPENDED; } continuation.savedToken = (String) tokenResult; // fall through case 1: String token = continuation.savedToken; continuation.label = 2; Object userResult = getUserInfo(token, continuation); if (userResult == COROUTINE_SUSPENDED) { return COROUTINE_SUSPENDED; } continuation.savedUser = (User) userResult; continuation.savedToken = null; // fall through case 2: User user = continuation.savedUser; Object scoreResult = getScore(user.id, continuation); if (scoreResult == COROUTINE_SUSPENDED) { return COROUTINE_SUSPENDED; } return "user: " + user + ", score: " + (String) scoreResult; } throw new IllegalStateException("非法label"); }

配套的状态机类：

static final class FetchUserSummaryStateMachine extends Continuation<String> { String savedToken; User savedUser; FetchUserSummaryStateMachine(Continuation<String> completion) { super(); this.completion = completion; } }

以及三个模拟挂起函数：

public static Object getToken(Continuation<String> completion) { return "token"; // 模拟直接完成 } public static Object getUserInfo(String token, Continuation<String> completion) { return new User(token); // 模拟直接完成 } public static Object getScore(String userId, Continuation<String> completion) { return "99"; // 模拟直接完成 }

实际业务里这三个函数往往都会返回COROUTINE_SUSPENDED并稍后手动resume。如果想让这个状态机真正"活"起来，可以把getScore改成返回COROUTINE_SUSPENDED，再由别的线程在合适的时候调用continuation.resumeWith(Result.success("99"))，然后重新调用fetchUserSummary(continuation)。这样你就能亲眼看到状态机从case 2恢复并输出最终结果。

5.2 对照源码逐行复盘

写完这段Java后，我逐行对比过Kotlin编译器生成的反编译结果，核心逻辑能对上：

• 入口方法先做continuation复用判断。
• switch分支与label对应。
• 每次调用挂起函数前先改label。
• 挂起函数返回COROUTINE_SUSPENDED时，向上传递信号。
• 局部变量存入约定好的槽位。
• case之间用fall-through加速直通场景。

真要说差别，就是我手写的版本没有Kotlin编译器那么抠内存槽位。比如token可能和user复用一个槽位，编译器能根据作用域做出最优解。手写版本为了可读性用两个字段，不影响对状态机运行原理的理解。

5.3 最容易写错的三个点及其根因

第一，fall-through控制失误。如果case 0里getToken没挂起，直接返回结果，但你没有让它自然落入case 1，而是手滑return了，调用链就断了。下次带着label=1进入函数时，savedToken还没被赋值，直接NPE。Kotlin编译器不会犯这种错，因为它生成的字节码里case 0末尾就是无条件跳转到case 1的代码；但手写时最容易漏。

第二，局部变量保存范围判断错误。判断一个变量是否需要保存，标准是"它会不会跨越挂起点"。如果变量在挂起点之前完全被消费掉了，不需要保存；如果在挂起点之后还要用，就必须找个字段存下来。我一开始写状态机，习惯性把所有局部变量都塞字段，结果又慢又乱。反过来，少存一个变量，恢复时直接空指针。这个尺度必须练成肌肉记忆。

第三，没处理continuation复用。真实Kotlin协程中，每次挂起恢复之间用的是同一个状态机对象。手写时如果每次调用都new一个对象，暂时看着能跑，但一旦涉及真实的resumeWith和多次挂起，状态必然丢。这也是为什么反编译代码里那段instanceof判断极其重要。

写完这个手写版本之后，我再回头看协程源码，之前觉得很绕的suspendCoroutine、suspendCancellableCoroutine的源码都豁然开朗了。它们本质上都是在帮你控制COROUTINE_SUSPENDED这个信号，让你能在合适的时候手动resume，而不是让编译器强制你返回结果。

6. 渡劫心得：挂起函数调试、崩溃栈阅读和性能避坑

6.1 协程崩溃栈为什么长，怎么定位业务代码

协程的崩溃栈确实吓人，动不动几十层。但看多了会发现它是有固定骨架的。典型的协程崩溃栈从底层往上层大概长这样：

java.lang.ArithmeticException: divide by zero at com.example.MyRepository.fetchUser(MyRepository.kt:23) at com.example.MyRepository$fetchUser$1.invokeSuspend(MyRepository.kt:25) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(BaseContinuationImpl.kt:33) at kotlinx.coroutines.DispatchedContinuation.run(DispatchedContinuation.kt:108) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ...

我一开始看到这种栈，习惯性往上翻找业务代码。后来发现规律：业务代码一般出现在invokeSuspend帧附近，或者往上再几帧。resumeWith和DispatchedContinuation这样的类名，代表这是"协程恢复链路"的部分，并不是问题根因。真正抛异常的那一行，通常在invokeSuspend帧下面第一个非协程框架类里。学会跳过框架帧，定位速度会快很多。

6.2 利用label与协程调试工具进行有效断点

调试挂起函数时，断点打进去后留意continuation对象的label字段，尤其是编译器生成的FetchUserSummaryKt$fetchUserSummary$1这类状态机对象。如果label是0，说明第一次进入；如果是2，说明前面已经走过了两个挂起点，现在正在恢复后执行。这对排查"为什么resume后走到了错误分支"非常有用。

另外2022年之后的IntelliJ/Android Studio版本对协程调试支持已经比较成熟，Dap和Kotlin插件可以直接在调试页面看到当前协程的状态、创建栈和挂起历史。这些工具呈现的信息，本质上就是continuation对象和CoroutineContext里各种状态元素的可视化。理解了字节码模型后，再用这些功能你会觉得一切都在预料之中，不是黑盒操作。

6.3 基于字节码的几个性能避坑结论

CPS变换是有代价的。每经过一个挂起点，至少要经历一次方法返回、一次哨兵值比较；如果真的挂起，还涉及状态对象分配、resume回调、调度器切换。基于这个模型，有几个性能避坑选项值得每次写协程前都过一遍脑子。

• 循环里不要反复调用suspend函数。比如for循环逐条查询数据库、逐条请求接口，每个循环都是一次状态机挂起和恢复，开销很大，能批量查就批量查。
• 别给不需要挂起的函数加suspend。没有真实挂起逻辑的函数虽然也会生成continuation，但白白多了一次方法调用和对象分配的代价。如果你的函数只是同步返回一个计算值，不需要挂起，就不要用suspend修饰。
• 理解Flow本质后再优化。Flow的collect本身就是一个挂起函数，collect的block里每次emit都涉及状态机流转。网上很多建议"用debounce合并高频事件、用buffer分离生产和消费"，底层逻辑就是减少collect调用链上的挂起恢复次数，减少线程调度开销。

说到性能，还有一个我自己踩过的坑：在Android里Room和Retrofit的suspend支持虽然好用，但如果是高频率的极短事务，比如轮询一个小状态，建议实测一下挂起恢复的开销，必要时加一个buffer或者合并策略。不要为了"好看"把所有同步逻辑都改成suspend，毕竟每个suspend函数都在字节码里多了一层状态机。

最后分享一点个人习惯：建议你每周抽半小时，把自己最近写的三四个suspend函数反编译看看。重点看带真实挂起点、局部变量跨挂起点的那几个。看多了之后，你对协程的判断会从"API能不能跑通"变成"这几个挂起点会产生多少状态机开销、这个变量要不要存到continuation槽位里"。这种视角转变，才是真正把协程从黑盒变成白盒的过程。到这一步，你这次对挂起函数字节码的"透视"就算真正渡劫成功了。