async/await 内部机制

调用 async fn 会构造一个 Future，其函数体在被轮询时推进。Future 描述尚未完成的计算，不自带独立线程；执行器负责决定何时 poll，异步 I/O 等等待源负责在可能继续时通知执行器。

一个 .await 不是固定一次线程切换。如果子 Future 立即 Ready，当前 poll 可以直接继续，甚至在一次 poll 内完成多个 await。

构造 Future 与执行函数体

use std::{cell::Cell, future::Future, task::{Context, Poll, Waker}};
async fn calculate(started: &Cell<u32>) -> u32 {
    started.set(started.get() + 1);
    let left = std::future::ready(20).await;
    let right = std::future::ready(22).await;
    left + right
}
fn main() {
    let started = Cell::new(0);
    let future = calculate(&started);
    assert_eq!(started.get(), 0);
    let mut future = std::pin::pin!(future);
    let mut context = Context::from_waker(Waker::noop());
    assert_eq!(future.as_mut().poll(&mut context), Poll::Ready(42));
    assert_eq!(started.get(), 1);
}

函数体在首次 poll 才运行，两个 ready Future 都立即完成，因此整段函数在一次 poll 内返回 42。这里用 noop Waker 是因为示例不需要等待；它不安排任务运行，不能用来驱动真实异步 I/O。Waker::noop

调用表达式的参数求值仍发生在构造 Future 时。例如 calculate(make_counter()) 中 make_counter 的调用不会自动被推迟；只有 async 函数体的执行受轮询驱动。async move 也会在创建块时取得捕获值的所有权，即使之后一次都没 poll。

编译器保存什么状态

编译器把 async 函数表示成能暂停和恢复的匿名状态机，其中保存当前等待的子 Future，以及在后续还要使用的局部值。等待 read_file 时，通常保存的是读取操作状态，而不是已经得到却实际上还未产生的文件内容。

状态机具体布局属于实现细节，不能把“每个 await 必须有一个恰好同名枚举 variant”当作 ABI。大局部值跨越挂起点可能增大 Future，提前结束其生命周期有时能减少状态大小。

poll 与 Waker 的契约

Future::poll 接收 Pin<&mut Self> 与 Context，返回 Poll

。Pending 表示还没有结果，相关实现需要建立任务可能继续时的唤醒路径；可以把这个工作委托给所轮询的子 Future，不必每层重复保存 Waker。

wake 是调度提示，可以被合并，也可能在 poll 返回 Pending 前发生。实现自己的等待原语时，需要把状态检查与注册通知之间的竞态处理正确，不能“先看没结果，再登记回调”而漏掉中间完成事件。

返回 Ready 后，调用者不应继续任意 poll 已完成 Future。具体类型可能 panic 或出现其接口定义的其他行为，不应把它当作 Iterator 可以继续 next 的协议。Future

Ready 表示完成，不等于业务成功

Future 的 Output 可以是 Result<T, E>。于是 Poll::Ready(Err(error)) 表示计算已经完成并返回错误；Pending 表示尚未得到最终结果。执行器不应把 Err 当作“还没准备好”继续轮询。

use std::{future::Future, task::{Context, Poll, Waker}};
fn main() {
    let mut future = std::pin::pin!(async {
        "bad".parse::<u32>()
    });
    let mut context = Context::from_waker(Waker::noop());
    assert!(matches!(future.as_mut().poll(&mut context), Poll::Ready(Err(_))));
}

为什么只保存第一次 Waker 不够

同一个 Future 在后续 poll 时可能收到不同的任务 Waker，例如被不同的外层组合方式继续驱动。等待原语需要按协议更新当前通知目标，不能假定首次注册后永远不变。wake 本身不携带结果，结果必须存储在正确同步的共享状态中，随后由 poll 读取。Future::poll

一种便于推理的等待原语使用同一把锁保护“结果是否存在”和“当前 Waker”：消费者在锁内检查结果，若未完成则登记 Waker；生产者在锁内写入结果并取走 Waker，解锁后调用 wake。这样可以避免完成事件恰好落在检查和登记之间而无人通知。实际库还要处理关闭、重复完成、取消以及公平性；不要把这个顺序说明当作已经完整实现了 channel。

唤醒并不等于已经执行

把“外部状态就绪”“唤醒任务”和“执行 poll”分开，才不会把 await 想成一个自己在后台运行的函数。先轮询到 Pending，然后只触发 I/O：你会看到任务可被再次调度，但 Future 还没有返回结果。重复 wake 也不是必须执行同样次数 poll 的计数器。

一个无需运行时的手工轮询例子

下面的 Future 第一次请求再次调度，第二次返回结果。例子使用安全的 Wake 接口，不需要手写 RawWaker：

use std::future::Future;
use std::pin::Pin;
use std::sync::{Arc, atomic::{AtomicUsize, Ordering}};
use std::task::{Context, Poll, Wake, Waker};

struct YieldOnce(bool);
impl Future for YieldOnce {
    type Output = u32;
    fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<u32> {
        if self.0 {
            Poll::Ready(42)
        } else {
            self.0 = true;
            cx.waker().wake_by_ref();
            Poll::Pending
        }
    }
}

struct WakeCount(AtomicUsize);
impl Wake for WakeCount {
    fn wake(self: Arc<Self>) { self.0.fetch_add(1, Ordering::Relaxed); }
    fn wake_by_ref(self: &Arc<Self>) { self.0.fetch_add(1, Ordering::Relaxed); }
}

fn main() {
    let count = Arc::new(WakeCount(AtomicUsize::new(0)));
    let waker = Waker::from(count.clone());
    let mut context = Context::from_waker(&waker);
    let mut future = std::pin::pin!(YieldOnce(false));
    assert!(future.as_mut().poll(&mut context).is_pending());
    assert_eq!(count.0.load(Ordering::Relaxed), 1);
    assert_eq!(future.as_mut().poll(&mut context), Poll::Ready(42));
}

这是确定的两次轮询演示，不是通用 executor。真正执行器要维护任务队列和通知竞争，不能把任何 Pending 都简单对应到一次无条件 park。

Pin 固定的是被指向的值

状态机可能包含指向自身内部数据的引用，因此一旦通过相应 pinning 契约建立地址稳定性，就不能再把 !Unpin 的被固定值随意移走，直到其正确析构。

Pin 不是编译器给所有值施加的魔法地址锁，而是安全 API 受限操作与 unsafe 实现义务共同维护的契约。Pin<Box> 这个指针包装本身可移动，只要它指向的 F 保持位置；F: Unpin 时，Pin 也不施加同样的移动限制。Pin

首次固定之前 Future 通常可以移动。并不是每个 async Future 都实际上自引用，也不是只要局部变量有一个 String 就一定因移动 String 对象导致其堆缓冲移动；需区分对象与其指向的存储。

移动包装器，不等于移动被固定的值

先只移动拥有 Future 的句柄：地址敏感的 F 没有离开堆上的 A。再打开反事实选项，观察如果把 F 本身移动，内部保存的地址为什么不会自动随之修正。Pin 不负责自动创建这些内部关系，初始化、投影与析构仍需满足其契约；Unpin 类型则可以退出这种移动限制。

await、spawn、join 分别做什么

await 在当前任务里推进子 Future；spawn 把一个 Future 注册为独立任务；join 类组合器可以在同一任务中推进多个 Future，不必创建 OS 线程。并发是生命周期重叠，是否并行取决于执行环境。

一次 poll 如果执行长时间 CPU 循环或阻塞调用，会占住当前执行器线程。仅把函数标成 async 不会使其中 std::thread::sleep、阻塞 I/O 或重计算自动让出执行权。

Drop 是取消机制的一部分

丢弃未完成 Future 是 Rust async 常见的取消方式，语言允许这样做，不应说 Future “不能随意 drop”。它会析构所持有的状态，停止该对象后续被轮询；但独立任务、已交给设备的请求和远端事务可能继续。

取消安全讨论的是丢弃后是否遗失进度或破坏业务协议，例如 read_exact 已经读走部分字节后取消，重新创建操作可能不再从原位置开始。资源是否释放与业务效果是否撤销是两个问题。

验证取消会析构局部值，但不会执行挂起点后的收尾

use std::{cell::Cell, future::Future, rc::Rc, task::{Context, Waker}};
struct Resource(Rc<Cell<u32>>);
impl Drop for Resource {
    fn drop(&mut self) { self.0.set(self.0.get() + 1); }
}
async fn waiting(drops: Rc<Cell<u32>>, after: Rc<Cell<bool>>) {
    let resource = Resource(drops);
    std::future::pending::<()>().await;
    after.set(true);
    drop(resource);
}
fn main() {
    let drops = Rc::new(Cell::new(0));
    let after = Rc::new(Cell::new(false));
    let mut future = Box::pin(waiting(Rc::clone(&drops), Rc::clone(&after)));
    let mut context = Context::from_waker(Waker::noop());
    assert!(future.as_mut().poll(&mut context).is_pending());
    assert_eq!(drops.get(), 0);
    drop(future);
    assert_eq!(drops.get(), 1);
    assert!(!after.get());
}

pending 永远不会自行就绪，这里故意只 poll 一次再取消，无需等待唤醒。Resource 已构造并跨越挂起点存活，所以取消时调用 Drop；after.set(true) 在 await 之后，从未执行。若把重要清理仅写在函数末尾，就不能保证取消路径会走到那里。

普通 Drop 是同步析构，不会自动 await 远端释放确认。需要协议级关闭时，应显式提供 close/shutdown 等异步步骤，并决定取消、超时或崩溃后的补偿方式。即使本地 guard 已释放，也不能据此推断远端事务已撤销。

丢弃 Pin 引用，与丢弃被拥有的 Future

上例使用 Box::pin，是为了让 drop(future) 明确销毁堆上 Future。若 pin! 得到的是 Pin<&mut F>，丢弃这个引用包装并不等于立即销毁它指向的 F；实际对象仍按其所在作用域的生命周期释放。推理取消时应先找到拥有 Future 的容器，避免把“停止持有一个借用”误当成“已经执行全部析构”。

取消安全要检查进度保存在谁手里

如果 Future 自己保存“已发送多少字节”，取消会丢掉这个进度，而底层流可能已经接收一部分；重新从头发送可能重复数据。若进度保存在外层持久对象中，下一次操作有机会继续，但仍需定义消息边界、幂等性和故障恢复。

因此应同时问：丢弃哪一个对象、它拥有哪段进度、外部动作已推进到哪里，以及重新创建操作会从哪里开始。取消安全是具体操作的契约，不是所有 async fn 都自动具有的性质。

超时、select 与后台任务的具体边界，继续看 Tokio 运行时 和 Tower。