调用栈（call stack）与“栈无关 / 无栈（stackless）协程

一、调用栈是什么，为什么需要它

直觉：栈是"接力棒"，保证"下一步从哪儿继续"和"要用哪些局部"都能找回。

维度	Stackful 协程（有用户态栈/纤程/fiber）	Stackless 协程（无栈/状态机式）
核心思路	给每个协程一条可暂停/恢复的用户态栈	不保存整条栈；把挂起点编译成状态机（保存必要局部+下一步 label）
挂起位置	理论上几乎任意位置（只要运行时允许）	只能在标记的挂起点（await/suspend 调用处）
恢复时原生栈	恢复后栈原封在用户态栈中	恢复时原生栈很浅（通常是调度器调用 resume），上游调用链通过continuation 链表达
内存成本	每协程一条栈（起始几 KB，可增长）	仅为活跃挂起点分配状态对象（字段保存局部），更省内存
可移植性	需要运行时/VM 支持或字节码插桩	纯编译期改写+少量运行时，易跨 JVM/JS/Native
栈追踪（调试）	接近同步代码的完整栈	原生栈不显示上游帧，靠堆上"逻辑栈"与"栈追踪恢复"弥补
典型代表	传统 fibers、早期 green threads、Go（栈可增长）、部分语言库	Kotlin 协程、C# async/await、JS async、C++20 协程（均为编译期状态机）

Kotlin、C#、JS 选择 stackless ，核心是跨平台与工程复杂度/性能权衡 最优；Go/部分语言运行时选择 stackful，换来"像线程一样随处可挂起"的能力，但需要强运行时支撑。

以 Kotlin 为例：

suspend fun 会被CPS（Continuation-Passing Style）改写 ，并生成一个状态机类：把"下一步从哪儿继续（label）"与"用到的局部（L$0...）"存到堆对象里。
到达挂起点时：保存局部 → 写入下一 label → 返回一个哨兵 COROUTINE_SUSPENDED。
未来恢复时：调度器在某线程调用 resumeWith 进入 invokeSuspend()，根据 label 跳转到挂起点后面的分支，读回局部继续执行。
恢复瞬间的原生调用栈 非常浅（通常只有调度器/resume 桥接），所以称 stackless ：没有保留一条可恢复的"原生栈" ，只有堆上状态 与continuation 链。

结果：你写的是同步风格 ；机器跑的是事件驱动 + 状态机。局部、控制流与异常传播都靠编译器生成的状态机与 continuation 表达。

挂起点可达性
- Stackful：几乎随处可 yield/await；
- Stackless ：只能在经过编译器"改造"的挂起函数中 挂起，不能从普通函数或本地回调里"直接挂起"。
这就是为什么你不能在非 suspend 函数里直接 delay() ，必须把它也写成 suspend 或用 runBlocking/launch 进入协程。
跨边界/临界区挂起
- 在 synchronized、不可重入锁持有、事务临界区内挂起会导致长时间持锁或死锁风险；Kotlin 编译器会给"在临界区有挂起点"的警告。
- Stackful 也可能出现类似问题，但它可以在更多位置停下（因此需要更严格的工程规范/运行时检查）。
异常/取消传播
- Stackless 中，取消表现为在下一次恢复时向状态机注入 CancellationException，逐个 try/finally 分支执行（保证资源释放）。
- 原生栈很浅，Kotlin 通过"Stacktrace Recovery"把上游挂起帧补回，以获得更可读的堆栈（调试友好）。
性能画像
- Stackless ：每个挂起点一次小对象（状态机）+ 少量字段读写；上下文切换由调度器完成，百万级协程更可行。
- Stackful ：每协程有栈 + 调度开销；起始成本高于状态机，但恢复路径简单 、调试原生。

kotlin 复制代码

suspend fun f() { g() }           // f -> g -> h 调用链
suspend fun g() { h() }
suspend fun h() { delay(100) }    // 挂起点

首次进入：f()→g()→h()，在 delay 处保存 h 的状态 并返回 COROUTINE_SUSPENDED，再层层把哨兵往上返回；此时原生栈清空。
100ms 后：调度器调用 resume(hContinuation)，执行 h 的状态机 label=1 分支，h 结束后调用 g 的 continuation，再到 f......
调试时看到的原生栈 只有"resume → invokeSuspend..."，但逻辑上仍按 f→g→h 顺序恢复，try/finally 会被逐帧执行。

只在需要的地方挂起：把 suspend 限定在 I/O、等待、互斥等"可阻塞点"，其余逻辑用普通函数，降低状态机数量。
避免在锁内挂起：将 withContext/await 等移出临界区；或使用无阻塞结构（如 Mutex.withLock { ... } 但仍要谨慎）。
结构化并发 ：用 coroutineScope/supervisorScope 管理"逻辑栈"，让异常/取消沿父子协程可预期传播，弥补无原生栈的可见性。
理解"不能从回调里直接挂起" ：把回调适配成 suspend（suspendCancellableCoroutine/callbackFlow），让它纳入状态机。
栈追踪恢复：启用 kotlinx-coroutines 的 Stacktrace Recovery（默认开启），定位跨挂起点的异常来源。
性能：热路径减少挂起点；复用 CoroutineScope；用 Dispatchers 正确选择线程；注意 UNLIMITED 缓冲导致内存抖动。

JDK Loom 虚拟线程 、部分字节码插桩的 fiber 库、或 Go 的 goroutine（可增长用户态栈）更接近 stackful：
- 你写的同步阻塞代码可以"随处挂起"，但需要运行时强力配合。
Kotlin/JS/C# 选择 stackless ，是因为它在现有平台上更可移植、可控、成本低，且能用编译期把"回调地狱"自动化为状态机。