Rust 无栈协程如何暂停和恢复？从 Future 与 poll 走完一次 HTTP 请求

2026-10-07T22:15:22+08:00

调用一个 async 函数，为什么 HTTP 请求还没发出去？函数等网络时，线程去了哪里？调用栈都退出了，变量又怎样留到下一次执行？

Rust 的无栈协程要解决的就是这组问题：开发者按顺序写代码，编译器把跨暂停的计算变成 Future 状态机；执行器或父 Future 调用 poll，让它获得执行机会。暂时不能继续时返回 Pending，之后按保存的状态推进。

“无栈”不代表不使用线程栈。每次执行 poll 仍有普通函数调用栈，只是不为每份等待中的计算保留一份专属协程栈。还要区分三件事：无栈 Future 描述状态如何保存；异步 I/O 决定等待时能否让出线程；执行器决定何时再次调用 poll。下面沿一次 HTTP 请求，把调用者、状态保存、通知与恢复分别讲清，不要求你先了解 Go 或 Tokio 源码。

为什么 Rust 的无栈协程是异步 I/O 的技术最优解？

2026-10-07T15:48:15+08:00

Go 可以在普通调用链深处挂起 goroutine，让线程去处理其他工作。Rust 为什么没有采用同样的方式，却要求开发者显式写出 async/await，还要面对 Future、Pin 和执行器？

本文要论证的是：在大量任务都等待网络的异步 I/O 场景中，Rust 的无栈协程可以称为技术最优解。 这里的“最优”不是跑分意义上的全面胜出，而是指它同时解决了三个核心问题：等待中的任务不必各自占用一份可挂起的协程栈，异步操作可以组合，执行路径又能由编译器直接生成状态机。

这里的“技术最优解”有明确范围：比较的是等待任务的内存占用、可组合性、执行效率、运行时耦合和资源边界。无栈协程省掉的是每个等待任务的专属协程栈，不是 Future 状态、连接和缓冲区本身；它也不是宣称所有负载下都最快。CPU 密集计算、长时间阻塞调用和需要透明暂停的场景，仍然可能适合线程或有栈协程。后文会先解释这些方案分别保存什么，再说明为什么这组取舍在异步 I/O 中占优。

bigfish的网络博客 - 协程

Rust 无栈协程如何暂停和恢复？从 Future 与 poll 走完一次 HTTP 请求

为什么 Rust 的无栈协程是异步 I/O 的技术最优解？