这篇文章是对 Understanding Rust futures by going way too deep 的整理与翻译，专为想从入门快速到精通 Rust Futures 的读者设计。

内容结构概览

一、项目搭建：async 环境的工具链准备
二、第一个教训：Future 不调用就什么都不做
三、手写一个最简 Future
四、async fn 的两种理解方式
五、证明 Future 不被 poll 就不做任何事
六、串行 vs 并发：两次 await 的问题
七、tokio::join!宏：单线程并发
八、tokio::select!其实，宏：取第一个完成的
九、tokio::spawn：真正的并行
十、FuturesUnordered：动态数量的并发
十一、深入底层：Waker 机制
十二、顺序 vs 并发 vs 并行：三个概念的精确定义
十三、小结：关键结论提炼

一、项目搭建：async 环境的工具链准备

作者从一个全新的项目开始。把所有准备工作都做一遍，这样后续任何一个例子都可以直接运行。

$ cargo new waytoodeep
$ cargo add tokio@ --features full
$ cargo add color-eyre@
$ cargo add tracing@ tracing-subscriber@
$ cargo add reqwest@ --no-default-features --features rustls-tls

下面展示 # 宏如何把 async fn main 包装成同步函数，并启动 tokio 运行时：

use color_eyre::Report;use tracing::info;use tracing_subscriber::EnvFilter;#
async fn main -> Result<, Report> {
setup?，info!，Ok)
}
fn setup -> Result<, Report> {
if std::env::var.is_err {
std:这方面，env::set_var;}
color_eyre::install?，if std::env::var.is_err {
std:的观点是，env::set_var;}
tracing_subscriber::fmt
.with_env_filter)
.init;Ok)
}

痛点提醒：如果忘记设置 RUST_LOG 或没有调用 .await你会发现日志里根本没有任何输出。确保在调试时开启详细日志。

tracing 结构化日志语法值得一提：

info!.get,"Got a response!")，

这样可以直接发送到 Datadog 或 Honeycomb 等 APM 网站，比纯文本日志更强大。

二、第一个教训：Future 不调用就什么都不做

常见错误是忘记对 async 函数返回值使用 .await导致请求根本不会发起。编译器会给出警告，但很多人忽略它。

async fn fetch_thing -> Result<, Report> {
let res = client.get.send.await?.error_for_status?，info!按理说，.get,"Got a response!")，Ok)
}
#
async fn main -> Result<, Report> {
setup?，let client = Client::new;// ❌ 没有 .await
fetch_thing;fetch_thing，Ok)
}

警告信息：

warning: unused implementer of `Future` that must be used
--> src/main.rs::
| | fetch_thing;| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
再看note，futures do nothing unless you `.await` or poll m

使用 .await 后才正常工作

fetch_thing.await?，不过，fetch_thing.await?，怎么说呢，

三、手写一个最简 Future

为了真正理解 Future。作者手写了最小可运行示例：

// src/dumb.rs
use std::{future::Future,pin::Pin,task::{Context,Poll}};use tracing::info;pub struct DumbFuture {}
impl Future for DumbFuture {
type Output =;fn poll -> Poll {
info!，Poll::Ready)
}
}

Panic backtrace 揭示 Tokio 调用栈

Mimicking panic to see full call stack:

panic!: ，in DumbFuture::poll. Caused by:: …

• dumb::DumbFuture as core's future's future's Future>::poll>
• main::{closure} as core's future's future's Generator>::poll>
• park::thread::CachedParkThread as tokio's runtime's thread_pool::ThreadPool>::block_on>

User Pain Point:

• No runtime magic – just normal function calls.
• If you think async is hidden behind a black box and rely on “magic” to work without polling,you'll hit deadlocks.

四、async fn 的两种理解方式

语法糖视角

async fn fetch_thing->Result<,Report>{…}

本质实现

rust fn fetch_thing<'a>( client这方面，&说起来，'a Client,url:&'a str,) -> impl Future+ 'a{ async move{ …} } 这里返回的是编译器生成的匿名类型，需要借助 std:any::_type_name 查看实际名称。例如：

text type_name="core·future·from_generator·GenFuture…"

这就是为什么我们无法显式声明此类型——它是 impl Trait 的主要原因之一。

五、证明 Future 不被 poll 就不做任何事

• `reqwest` debug 日志：`debug reqwest connect` 只在 `.await` 后出现。
• `sleep + strace` 证明：`strace -e connect ./target/debug/waytoodeep` 在等待期间没有程序调用。
• `reqwest debug + strace 双重验证`: `sleep` 后才触发连接。

六、串行 vs 并发：两次 await 的问题

rust fut1.await?，// 完整等待 url1 响应完成后再执行接下来 fut2.await?，话说回来，

这会产生完全串行行为——与同步代码无异。使用者常误以为只要写两个 await 就自动并发，但是顺序执行。

七、tokio join!宏 ：单线程并发

rust tokio:的观点是，join!( fetch_ thing(&client,URL_ 1),fetch_ thing(&client,URL_ 2) );

此宏让两个 Future 在同一线程上交替 poll在 I/O 等待期间 CPU 被利用，这样就能实现并发但不是并行。若要真正平行，需要多线程。

• 同一线程上进行 “交替轮询”。
• 仅适用于 I/O 密集型任务，CPU 密集型则需多线程或专门设计。

八 select!其实，宏 ：取第一个完成的

rust 说到tokio:。select，{ res= fetch_ thing( &client,URL_ 1)=>{info!，res? },res= fetch_ thing( &client,URL_ 2)=>{info!，res?} }

当任意分支返回 Ready 时立即执行对应代码，其余分支被丢弃。可配合循环实现事件驱动模型。

• 适用于 “谁先来就处理谁”的场景。

九 spawn : 真正的并行

rust let handle1 = 至于tokio:。spawn(fetch_ thing,URL_ 1));let handle２ = 再看tokio:。spawn(fetch_ thing,URL_ २));

handle１.await?，;按理说，handle２.await?，;

• 要求 ；若使用引用则需克隆或转为 Arc。
• 真正同时跑在不同线程上，适合 CPU 密集型或需要多核资源。

• Spawn 必须满足 Send+static，否则会报错。

十 FuturesUnordered ：动态数量的并发

while let Some=futs.next .await{ result?，} 测得两请求相差约19ms，说明确实是并发。

痛点提醒

• 对于大量 I/O 请求，用 spawn + join_all 会产生太多子任务；更优雅的是 FuturesUnordered.
• 如果忘记将所有任务推入队列，只能得到部分结果 — 确保 .next 循环覆盖全部任务。

十一 深入底层 Waker

---

什么是 Waker？其实，

当 ::poll 返回 时它需要告诉 runtime 何时 尝试 调用该方法。这由 中提供的 Waker 完成。

手写慢速未来

rust struct SlowFuture {wake_at : Instant }

impl SlowFuture{ pub fn new -> Self{ Self{wake_at : Instant.now+duration} } }

impl Future for SlowFuture{ type Output =;fn poll(self : Pin<&mut Self>,cx : &mut Context<') ) -> Poll{ if Instant.now>self.wakeat{ Poll :: Ready) } else { let waker=cx.waker.clone;// 捕获 waker let target=self.wake_at;thread :: spawn(move ||{ thread :: sleep);waker.wake，// 通知 runtime 可以 poll });Poll :: Pending } } } 每次 poll 都重新创建线程只是为了演示；真实实现使用 epoll/kqueue/io‑uring 自动唤醒，无需额外线程。

若未唤醒会怎样？

rust fn poll )->Poll{ Poll :: Pending // 永远不会唤醒 → 永久阻塞!} 这是违反合约 —— Runtime 无法继续推进此未来程序陷入僵局。

为什么每次 poll 都要设置 Waker？

Waker 是 每一次 poll 调用的一部分，因为它可能随时间改变。必须在每一次调用中传递最新实例，以保证正确性。

---

十二 顺序 / 并发 / 并行 精确定义

概念	定义	示例
*顺序 *	一件事完成后再开始下一件	fut1.await?，fut₂.await?
*并发 *	多件事交替执行，但不必同时进行	join!,select，,FuturesUnordered
*并行 *	多主要/多线程同时执行	tokio.spawn + multi‑threaded runtime

I/O 密集型场景 下并发已足够；只有 CPU 密集型才考虑真正并行。

十三 小结

• 惰性 – 创建 Future 不会立即执行；只有被 或 .await 调用后才会开始工作。
• 状态机 – 编译器把 async 函数转换为 struct，实现了 方法。
• .await == poll – 等价于手动轮询直到 Ready。
• 工具链 – join!,select，,spawn 分别对应单线程并发/最快者/真正多线。话说回来，
• Waker 协议 – 保证 Pending 状态下最终能被唤醒。否则永远卡住，
• 无运行时开销 – 与 Go goroutine 对比。你自己决定何时切换，无额外栈管理成本。

---

常见错误与方法

场景	错误	修正
忘记 .await	请求不发送 → 日志无输出	加 .await?
未实现 Send+static 在 spawn 中	编译错误或运行时崩溃	使用 Arc/Clone 或去掉引用
忘记在所有分支中调用 Waker	程序死锁	确保每个 pending 方法都有 wake

---

更多资源

• - 详细说明 Rust Futures 基础与细节。话说回来，
• - 更异步编程细节。怎么说呢，
• - API 与使用范例。
• - 程序教程。
• - HTTP 客户端实践。
• - 错误处理
• - 高性能结构化日志。老实说，
• - 包含 FuturesUnordered 等工具。

---

---